Re: Python 3 str.format()

[claudep]

Le vendredi 24 août 2012 19:11:49 UTC+2, Ian a écrit :

> Until the Python developers announce an actual timeline for removal 
> (if they ever do), I can't see any reason for Django to be concerned 
> about which formatting approach to use, apart from the immediate 
> concerns of style and efficiency. 
>

One more reason not to adopt too quickly this syntax is missing support 
from gettext.

http://savannah.gnu.org/bugs/?30854

Claude

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/XmKeXpVJkAUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python 3 str.format()

[Alex Ogier]

> Until the Python developers announce an actual timeline for removal
> (if they ever do), I can't see any reason for Django to be concerned
> about which formatting approach to use, apart from the immediate
> concerns of style and efficiency.

I don't think Python will ever remove %-style formatting, even in a
hypothetical "Python 4," because there are a lot of APIs (including
Django's) that expose it. Guido mentions the logging package, but
there are also a lot of third party packages that take %-style
template strings as arguments to formatting functions. As a result,
the %-style syntax will have to stick around until most of these
packages convert over, and if the latest Python 3 documentation has
even stopped recommending str.format() as a better alternative then I
expect it to stick around for good.

Best,
Alex

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python 3 str.format()

[Ian Kelly]

On Fri, Aug 24, 2012 at 10:30 AM, Daniel Swarbrick
 wrote:
> On 24 August 2012 18:12, Carl Meyer  wrote:
>> Can you link to where in the current docs it specifies that %-formatting
>> is deprecated and/or will be removed? I can't even find, on a cursory
>> search, where it says the new .format() style should be preferred.
>
> It's not easy to find - I've only found the mention of the impending
> deprecation in the Python 3.0 "What's New" docs -
> http://docs.python.org/release/3.0/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting
>
> However, I can't find followup references to that in the Python 3.1
> docs. Maybe the decision was rescinded? Personally I didn't really see
> anything majorly wrong with the %-style formatting. Being a C
> developer myself, it was nice to have some common ground and not have
> to go hunting for format string specifications.
>
> This section http://docs.python.org/library/stdtypes.html#str.format
> states "This method of string formatting is the new standard in Python
> 3, and should be preferred to the % formatting described in String
> Formatting Operations in new code."
>
> I just thought that if the %-style formatting is indeed earmarked for
> removal, maybe we should start using the new format sooner rather than
> later.

This post by Guido is informative on the subject, even though it's
nearly three years old now:

http://mail.python.org/pipermail/python-dev/2009-September/092399.html

The 3.2 docs specifically say, "As the new String Formatting syntax is
more flexible and handles tuples and dictionaries naturally, it is
recommended for new code. However, there are no current plans to
deprecate printf-style formatting."  The 3.3 docs no longer have this
quote, but they also indicate nothing about planned deprecation or
removal.

Until the Python developers announce an actual timeline for removal
(if they ever do), I can't see any reason for Django to be concerned
about which formatting approach to use, apart from the immediate
concerns of style and efficiency.

Cheers,
Ian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python 3 str.format()

[Daniel Swarbrick]

On 24 August 2012 18:12, Carl Meyer  wrote:
> Can you link to where in the current docs it specifies that %-formatting
> is deprecated and/or will be removed? I can't even find, on a cursory
> search, where it says the new .format() style should be preferred.

It's not easy to find - I've only found the mention of the impending
deprecation in the Python 3.0 "What's New" docs -
http://docs.python.org/release/3.0/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting

However, I can't find followup references to that in the Python 3.1
docs. Maybe the decision was rescinded? Personally I didn't really see
anything majorly wrong with the %-style formatting. Being a C
developer myself, it was nice to have some common ground and not have
to go hunting for format string specifications.

This section http://docs.python.org/library/stdtypes.html#str.format
states "This method of string formatting is the new standard in Python
3, and should be preferred to the % formatting described in String
Formatting Operations in new code."

I just thought that if the %-style formatting is indeed earmarked for
removal, maybe we should start using the new format sooner rather than
later.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Python 3 str.format()

[Daniel Swarbrick]

Hi folks,

Apologies in advance if this topic has already been raised. I don't believe 
I've seen it on the list since I've been subscribed.

Since Django 1.5 has set the minimum version of Python at 2.6, and in 
conjunction with the push to make Django more Python 3 compatible, should 
we slowly start migrating to the new format string [1] syntax? The Python 
docs state that it is the new standard in Python 3, and should be preferred 
to the old %-style formatting. The %-style was supposed to be deprecated in 
Python 3.1. Whilst I'm a little vague on whether it's been officially 
deprecated yet, it is slated to be removed from Python altogether at some 
point.

The new str.format() method is supported by Python 2.6 onwards.

1: http://docs.python.org/library/string.html#format-string-syntax

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/AL3i6DKvsN0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #16455 PostGIS 2.0 support

[Flavio Curella]

Thanks everyone for the feedback on this patch.

I've added some code that deals with database creation. Specifically, to 
support the template database approach also on PostGIS 2.

I still have some failing test, but they fail on both PostGIS1.5 and 2.0. 
I'm running ``./runtests.py --settings= gis``.

Two of the failures are:

AssertionError: u'{ "type": "Point", "coordinates": [ 100.00, 
0.00 ] }' != '{ "type": "Point", "coordinates": [ 100.0, 0.0 ] }'

Could be a JSON serialization quirk? I don't have any JSON lib system-wide 
nor in my virtualenv, so I know it's using the one shipped within Django. 
Should we modify the test to unserialize (json.loads) and compare Python 
objects?

The other failure is:

AssertionError: 
'GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]'
 
!= 
'GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_84",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]'

If you compare the two string, the only difference is that the spatial 
reference for the spheroid is "WGS_1984" instead of "WGS_84".
I'm not exactly sure if they are the same ref, or why and when it would 
have changed.

Thank you,
Flavio.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/usfQq-CV3oUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python 3: should we apply unicode_literals everywhere?

[Vinay Sajip]

I would also prefer Option 2, as the places where str('...') are needed are 
not all that many.

Regards,

Vinay Sajip

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WLtnInRyKyAJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: After form validation, need to post and call a perl program to display to a log file

[Pervez Mulla]

Oh ok,

Sorry

On Fri, Aug 24, 2012 at 4:28 PM, Karen Tracey  wrote:

> Please do not crosspost to both django-users and django-developers. -users
> is for discussions centering around using Django, that was the right list
> for this question. -developers is for discussions of the development of
> Django itself.
>
> Karen
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: After form validation, need to post and call a perl program to display to a log file

[Karen Tracey]

Please do not crosspost to both django-users and django-developers. -users
is for discussions centering around using Django, that was the right list
for this question. -developers is for discussions of the development of
Django itself.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Customizable Serialization check-in

[Tom Christie]

Thanks Piotr,

  It's been interesting and helpful watching your progress on this project.
I wouldn't worry too much about not quite meeting all the goals you'd hoped 
for - it's a deceptively difficult task.
In particular it's really difficult trying to maintain full backwards 
comparability with the existing fixture serialization implementation,
whilst also totally redesigning the API to support the requirements of a 
more flexible serialization system.
Like you say, I think the overall direction of your project is right, and 
personally I've found it useful for my own work watching how you've tackled 
various parts of it.

All the best,

  Tom

On Thursday, 23 August 2012 01:14:26 UTC+1, Piotr Grabowski wrote:
>
> Hi, 
>
> Google Sumer of Code is almost ended. I was working on customizable 
> serialization. This project was a lot harder than I expected, and sadly 
> in my opinion I failed to do it right. I want to apologize for that and 
> especially for my poor communication with this group and my mentor. I 
> want to improve it after midterm evaluation but it was only worse. 
>
> I don't think my project is all wrong but there is a lot things that are 
> different from how I planned. How it looks like (I wrote more in 
> documentation) 
> There is Serializer class that is made of two classes: NativeSerializer 
> and FormatSerializer. 
> NativeSerializer is for serialization and deserialization python objects 
> from/to native python datatypes 
> FormatSerializer is for serialization and deserialization python native 
> datatypes to/from some format (xml, json, yaml) 
>
> I want NativeSerializer to be fully independent from FormatSerializer 
> (and vice versa) but this isn't possible. Either NativeSerializer must 
> return some additional data or FormatSerializer must give 
> NativeSerializer some context. For exemple in xml all python native 
> datatypes must be serialized to string before serializing to xml. Some 
> custom model fields can have more sophisticated way to serialize to 
> sting than unicode() so `field.value_to_string` must be called and 
> `field` are only accessible in NativeSerializer object. So either 
> NativeSerializer will return also `field` or FormatSerializer will 
> inform NativeSerializer that it handles only text data. 
>
> Backward compatible dumpdata is almost working. Only few tests are not 
> passed, but I am not sure why. 
>
> Nested serialization of fk and m2m related fields which was main 
> functionality of this project is working but not well tested. There are 
> some issues especially with xml. I must write new xml format because old 
> wont work with nested serialization. 
>
> I didn't do any performance tests. Running full test suite take 40 
> seconds more with my serialization (about 1500s at all) if I remember 
> correctly. 
>
> I will try to complete this project so it will be at least bug free and 
> usable. If someone was interested in using nested serialization there is 
> other great project: https://github.com/tomchristie/django-serializers 
>
> Code: https://github.com/grapo/django/tree/soc2012-serialization 
> Documentation: https://gist.github.com/3085250 
>
> -- 
> Piotr Grabowski 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/a2gBdTn5C6EJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Why is CSRF cookie persistent?

[Gruffudd Williams]

Many thanks for the reply. This is perfect and I can get back to the 
pen-testers now that I fully understand the issue.

Regards,

Gruff

On Thursday, 23 August 2012 02:04:56 UTC+1, Paul McMillan wrote:
>
> Hi Gruffudd, 
>
> If the cookie were set to expire at browser close, it would cause CSRF 
> errors for users who closed a browser (or bookmarked a page with a 
> form on it) and then loaded that page from a browser cache and 
> submitted the form. I'm ambivalent about whether this use case is 
> worth supporting (it may be important on mobile devices, for example), 
> but I don't believe that setting the cookie to expire on browser close 
> provides much security benefit to an otherwise properly configured 
> site (HTTPS, HSTS, etc.). 
>
> Django's CSRF implementation differs[1] from many others which store 
> CSRF information alongside session information on the server. The CSRF 
> mechanism functions by matching a token provided in a form with a 
> token provided as a cookie in the browser. If you set the cookie to 
> 'zzz', it will still function perfectly well. The security comes from 
> the fact that an attacker cannot set the cookie, not that it happens 
> to contain any specific cryptographic value. 
>
> If the concern is that an attacker could access a user's physical 
> computer between sessions and steal a CSRF token, setting it to expire 
> at browser close would not prevent an attacker from inserting a cookie 
> of known value that would be used during the next session. I'm not 
> convinced we can secure the tokens of a user whose computer has been 
> physically accessed by an attacker. 
>
> Still, if it can be convincingly demonstrated that setting the cookie 
> to expire at browser close would not break existing use cases (mobile 
> browsers are my chief concern) I'd be open to changing the default 
> behavior. We generally consider it a bug if any non-malicious user 
> can, through innocent behavior, trigger the CSRF warning. 
>
> -Paul 
>
> [1] Django's CSRF implementation usually sets off all kinds of false 
> alarms in most pen-tester's tools, since it doesn't work exactly the 
> same way other implementations do, and isn't tied to the session 
> cookie. 
>
> On Tue, Aug 21, 2012 at 3:53 PM, Gruffudd Williams 
>  
> wrote: 
> > The results of a recent penetration test brought up the issue of the use 
> of persistent cookies, specifically the CSRF cookie which has an expiry 
> date one year in the future. 
> > 
> > The rationale given was that since the cookie is stored on the hard 
> drive then it is theoretically possible to get hold of it between a user's 
> sessions. 
> > 
> > The question is, does the csrf cookie really need to be persistent at 
> all? I can't see that setting an expiry adds to the security model. 
> > If it was made non-persistent then the only difference is that the 
> cookie would be re generated for each new browser session, which means it 
> would be generated more often than if the cookie was persistent, but is 
> this an issue? 
> > 
> > Perhaps I'm missing something, but I'd be interested to learn the 
> reasons why it was implemented with a persistent cookie. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers" group. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-developers/-/N4a1LKzUIYoJ. 
> > To post to this group, send email to 
> > django-d...@googlegroups.com. 
>
> > To unsubscribe from this group, send email to 
> django-develop...@googlegroups.com . 
> > For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en. 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/iCTp7O2WqN4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

[Ryan Hiebert]

> I don't think what you are suggesting would be necessary. Stream-capable 
> middleware could avoid having to handle both cases by simply wrapping 
> response.content with a new iterator in all cases, if they want to. 
> Non-streaming responses can still be iterated. They just have fewer 
> iterations (as few as one).
> 
> The only reason for a stream-capable middleware to access response.content 
> explicitly in this case is for improved efficiency when the user doesn't care 
> about streaming the response. I think GZipping the whole content is probably 
> more efficient than GZipping chunks of it.

Tai, thanks for your response.

I was more than a bit confused on how the response object is normally consumed, 
which caused me to write a message that made me look more than a bit silly.

I see that a single-string iterator is a perfectly good way to do things, thank 
you for helping me see it. It seems obvious in hindsight.

Ryan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.