Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Chapter03 #12

merged 21 commits into from Nov 20, 2012


None yet
3 participants

mpdaugherty commented Nov 2, 2012

Most of what I changed here had to do with the examples of URLConfs - in Django 1.4, the auto-generated urls.py file no longer directly uses tuples to map URLs. Therefore, a contradictory example in the book could confuse new developers and they'll probably almost always use the url() function instead, so I figured we should just start with that.

mpdaugherty added some commits Oct 25, 2012

@jacobian jacobian and 1 other commented on an outdated diff Nov 5, 2012

@@ -40,7 +40,7 @@ Python 2.5, so using a later version of Python keeps your options open.
supported it experimentally. Python 3.0 introduced a substantial number of
backwards-incompatible changes to the language itself, and, as a result,
many major Python libraries and frameworks, including Django, had not yet
- caught up. Python 2.6-3.2 will be supported by Django 1.5.
+ caught up. Django 1.5 will support Python 2.6-3.2.

mpdaugherty Nov 13, 2012


Thanks; I updated the note.

@jacobian jacobian commented on the diff Nov 5, 2012

+ :doc:`chapter08`.
+.. note::
+ One more important detail we've introduced here is that ``r`` character in
+ front of the regular expression string. This tells Python that the string is a
+ "raw string" -- its contents should not interpret backslashes. In normal
+ Python strings, backslashes are used for escaping special characters -- such
+ as in the string ``'\n'``, which is a one-character string containing a
+ newline. When you add the ``r`` to make it a raw string, Python does not apply
+ its backslash escaping -- so, ``r'\n'`` is a two-character string containing a
+ literal backslash and a lowercase "n". There's a natural collision between
+ Python's usage of backslashes and the backslashes that are found in regular
+ expressions, so it's strongly suggested that you use raw strings any time
+ you're defining a regular expression in Python. All of the URLpatterns in this
+ book will be raw strings.

jacobian Nov 5, 2012


This note is a distraction; it's not needed here.


jacobian Nov 5, 2012


In fact, I'd probably just not use raw strings at all. Backslashes rarely appear in URLs (and certainly not in well-formed ones) and so the distinction's just extra noise and confusion for new users.


mpdaugherty Nov 13, 2012


I agree that this note is a distraction from the point of the chapter.

On the other hand, I do think our examples should use raw strings, because that's what startproject puts into urls.py by default. Therefore, I feel that the question would naturally occur to new users if they look at our examples vs. their urlconf and think "Why do these strings start with 'r' and the ones in the book don't?"

What do you think about using raw strings, but leaving out the explanation? Or, we could change this inline explanation to be something short like "The r indicates a raw string instead of a normal string. To find out why you would use one instead of the other, read the note at the end of this chapter." and then put the longer explanation at the end of the chapter.


jacobian commented Nov 5, 2012

Thanks! Looks great, I left a few TODOs.

I would recommend keeping it whatever the default urls.py is for a recent version of Django; it's encouraging and less confusing to a new user, such as myself, to see a new installation match the documentation.

For django 1.3.1, settings,py and manage.py are in the same directory. Has it changed since?

I'm all for moving the "One more important detail" paragraph up.

@jacobian jacobian added a commit that referenced this pull request Nov 20, 2012

@jacobian jacobian Merge pull request #12 from mpdaugherty/chapter03
Updates to Chapter 3.

@jacobian jacobian merged commit b587950 into jacobian-archive:master Nov 20, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment