Re: EmailMessage mangles body text
On Wed, Apr 28, 2010 at 10:00 AM, Rob Hudson wrote: > On Tue, Apr 27, 2010 at 6:38 PM, Leo wrote: > > Digging deep into Python's innards reveals that this is a somewhat > > esoteric protection in case you're writing out Unix mailbox files. The > > specific issue is here: > http://docs.python.org/release/2.6.2/library/email.generator.html#email.generator.Generator > > and involves the mangle_from_ flag. > > > > The hugely more likely case is that if you're using Django's > > EmailMessage class you're sending emails rather than writing Unix > > mailbox files and are running into this bug that way. > > Wouldn't these e-mails end up on other servers that might save the > message in a Unix mailbox format? And if so, wouldn't removing the > ">" from the "From" cause problems? > No, the issue is only for message storage, not transmission -- there's nothing in SMTP that says you need to escape From_ lines. If those servers need to store the message in a Unix mbox, they will escape it on their own. (In fact, if the message contains a line starting with >From, I'm pretty sure they will need to further escape it, storing it as >>From) 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-develop...@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: Allowing models to influence QuerySet.update
On Wed, Jul 28, 2010 at 9:37 AM, Dennis Kaarsemaker wrote: > Is nobody interested? > > I'm using this in production for auditing purposes and works just fine. > If only it were built in, then I wouldn't have to monkeypatch :) > > I've rebased it to trunk again and it still works. > > On wo, 2010-06-16 at 14:38 +0200, Dennis Kaarsemaker wrote: > > I know that queryset.update does not call .save() for each instance and > > I know why. I even agree with it :) > > > > However, I'd like to have a bit more control over what update() does, > > e.g. for auditing purposes. I know that I can simply write a few lines > > of code near every update() call to do what I want, but that violates > > DRY. > > > >From what I've seen, you're probably going to encounter some resistance to any proposal that includes adding new signals to the core, especially if they are never going to be used by the vast majority of developers, and especially if there is any workaround possible. In this specific case, is this not a problem that can be solved by a custom manager on the specific models that need this functionality? That way you don't RY so much: class ControlledUpdateManager(django.db.models.Manager): def update(self, *args, **kwargs): # pre-update code super(ControlledUpdateManager,self).update(*args, **kwargs) # post-update code class MyModel(django.db.models.Model): ... objects = ControlledUpdateManager() You can apply that manager to any models that need the same pre- and post- update code, or subclass from it, or use it as a mixin as necessary. -- Regards, Ian Clelland -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Proposed solution to deleting contents of FileField
On 8/9/06, James Bennett <[EMAIL PROTECTED]> wrote: > This is certainly a long-standing wart in Django, and on first glance > I like this solution a little better than the patch on #22, but we > also have a Summer of Code student working on major enhancements to > the admin's media support[1]; since there are only a couple weeks left > to go in SoC, I'd advise holding off on comitting any solution until > we see his final results. Thanks, James -- I hadn't realised that one of the SoC coders was working around FileField and ImageField. The code that we have now was written as a workaround for the problem, rather than as a patch against django source, for just this reason. We don't want to tread on anyone else's work if we can help it -- it just makes for bigger maintenance headaches for us ;) Unfortunately, (for us, possibly,) with further testing, we've discovered a couple of problems with Django's handling of FileFields and ImageFields -- not strictly limited to admin, but in the way that fields tagged "core=True" are handled by manipulators. Because of this, I've created a ticket (#2534) with a patch that fixes the core field handling, and makes FileFields deletable. http://code.djangoproject.com/ticket/2534 Regards, Ian Clelland <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: has broken something ?
On 4/12/06, Gael Chardon <[EMAIL PROTECTED]> wrote: > After this update, none of my models is "loaded". > > Is there any major change in the db "model" ? Is the problem fixed in 2684? The relevant import line was extended to include the relations as well as the field types. Ian Clelland <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Passing dictionary to SQL queries
It appears that the CursorDebugWrapper class will allow a tuple to be passed in as parameters to a SQL query, but will not allow a dictionary. Since dictionaries are alllowable parameters when the underlying database supports pyformat params, should the DebugWrapper be able to support them as well? I know that psycopg allows these parameters, and I believe that sqlite does as well, and it would be nice to be able to use them in django. I think that removing the explicit tuple() call in CursorDebugWrapper.execute would fix this, although perhaps the DebugWrapper should just be passing the parameters down to the cursor object. (I may be missing the point of the debug object entirely, though) -- Regards, Ian Clelland <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Extending templates programmatically
I've been looking into the django template system, and how to use it
in situations other than html rendering (e.g, building up email
messages from templates in the database)
It would be very useful in these sorts of situations to be able to
extend from a template that does not exist inside of a template
directory on the filesystem; for instance, template source from the
database, or from a string generated in python code.
(This issue was also mentioned a couple of days ago on the users list,
here:
http://groups.google.com/group/django-users/browse_thread/thread/aea7d78cebbfe2d/ef0c805c653c4f70
)
The solution I've come up with is a 2-line patch to get_parent in
/templates/loader_tags.py which checks whether the parent variable
pulled from context is already a Template object, and if it is, just
return that, rather than trying to load it.
Now I can do things like this:
from django.template import Context, Template, loader
a = Template("{% extends templateone %}{% block one %}Hello {{ name
}}{% endblock %}")
b = Template("{% block one %}Stuff{% endblock %}")
a.render(Context({'name': 'world', 'templateone': b}))
which returns "Hello world"
Is this patch worth submitting an enhancement ticket? Or have I
managed to miss a simpler way of doing this?
Regards,
Ian Clelland
<[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Extending templates programmatically
On 4/16/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Sure, I'd say that's worth submitting as an enhancement ticket. I can > definitely see use for that! Done -- it's at http://code.djangoproject.com/ticket/1650 (It's a bit more than two lines, but only because I threw in a couple of unit tests and a line of documentation.) Ian Clelland <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Ideas for /examples/ directory
On 4/18/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Seems like a pretty good idea to me -- especially since Python 2.5 > will ship with the sqlite driver in the standard library. Is Python 2.5 going to be a dependency of 0.92, by the time m-r gets merged back into it? ;) More seriously, though, I've been seeing more Python 2.4-isms showing up in the documentation (and occasionally into code) recently -- are there plans to make the next release dependent on anything greater than 2.3? Ian Clelland <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Deprecate change pk + save behavior for 1.4
On Wed, Nov 30, 2011 at 4:26 AM, Kääriäinen Anssi wrote: > """ > > The reason for doing the deprecation now is that it would be nice that > > this behavior is already removed when multicolumn primary keys are > > introduced into Django. > > > > There is a ticket related to this: #2259. > > Here is another that could be helped by this change, depending on > implementation - #14615 > The decisions on that ticket basically boils down to the question of how > we detect a new object (which is waiting for PK from the DB). The > current solution of comparing with None (used in various places) fails > for nullable primary keys. > """ > > I can think of two basic approaches to this: define a __setattr__ for > Models, > and check if the pk is set after fetch from DB. This has at least three > problems: > 1. It is likely that users have custom __setattr__ methods that do not use > super().__setattr__ but change the dict directly. > 2. This way it is somewhat hard to detect if the PK has actually changed > or not. You can (and many users likely currently do) set the value to the > same > value it is already. > 3. This will make model __init__ slower (although there are tricks to > mitigate > this effect). > > The other way is storing old_pk in model._state, and compare the PK to > that when saving. If changed, error. This would work best if there was a > NoneMarker object for the cases where there is no PK from DB, so you could > solve #14615 easily, too. > Is this referring exclusively to natural, or user-specified primary key columns? Despite Luke's reference to nullable primary keys (are these even allowed by SQL?), a common idiom for copying objects is this: obj.pk = None obj.save() I have used use this pattern in more instances than I can remember; whether for duplicating objects, or for making new variants of existing objects. I would hate to see the behaviour deprecated, or worse, for the old object to simply get reassigned a new (or null) id. For changing natural primary key fields, I would prefer to see a pattern like this: class User: firstname = models.CharField lastname = models.CharField pk = (firstname, lastname) u = User.objects.get(firstname='Anssi', lastname='Kääriäinen') u.firstname='Matti' u.save(force_update=True) (specifically, with the force_update parameter being required for a PK change). Then, as long as we store the original PK values, the object can be updated in place. A bare save() would work just as currently changing the id field does -- create a new row if possible, otherwise, update the row whose PK matches the new values. -- Regards, Ian Clelland -- 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: Deprecate change pk + save behavior for 1.4
" > > IMHO forbidding creation of a new object while leaving the old object in > place when calling save() is needed. Current behavior is unintuitive. One > clear indication of this being unintuitive is that even Django's admin does > not get it right. If bare save() will be deprecated, then an upgrade path > for current uses is needed. A new kwarg for save (old_pk=None would be a > possibility) or obj.clone() would be needed. > I'm not sure that I agree -- I don't know if there needs to be a fundamental distinction between a new model instance and one that was retrieved from the database. I do agree that there should be a way to specify "change the primary key on this object" vs "save a new object with this primary key". (And I'm waiting for someone to come in and say "The current behaviour is documented, leave it alone. Use filter(pk=old_value).update(pk=new_value) if you want to change a primary key. It's all in code anyway, and you should know which fields are PK fields before you go messing with them." :) ) Solving all these problems before 1.4 seems hard. > Agreed. > > - Anssi > > -- > 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. > > -- Regards, Ian Clelland -- 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: Deprecate change pk + save behavior for 1.4
On Wed, Nov 30, 2011 at 1:15 PM, Ian Clelland wrote: > On Wed, Nov 30, 2011 at 12:40 PM, Kääriäinen Anssi < > anssi.kaariai...@thl.fi> wrote: > >> """ >> Is this referring exclusively to natural, or user-specified primary key >> columns? Despite Luke's reference to nullable primary keys (are these even >> allowed by SQL?), a common idiom for copying objects is this: >> """ >> >> Not allowed by SQL specification, but many databases do allow them >> (source wikipedia). >> > > /me runs off to go correct Wikipedia ;) > > I checked the Wikipedia article on Primary Key first, and didn't see that, > but I did note this: > > A table can have at most one *primary key*, but more than one unique key. >> A primary key is a combination of columns which uniquely specify a row. It >> is a special case of unique keys. One difference is that primary keys have >> an implicit NOT NULL constraint while unique keys do not. > > > Also, this, from http://dev.mysql.com/doc/refman/5.5/en/create-table.html: > > A PRIMARY KEY is a unique index where all key columns must be defined as >> NOT NULL. If they are not explicitly declared as NOT NULL, MySQL declares >> them so implicitly (and silently). > > > And from > http://www.postgresql.org/docs/8.4/static/ddl-constraints.html#AEN2338: > > Technically, a primary key constraint is simply a combination of a unique >> constraint and a not-null constraint. > > > Oracle: > http://docs.oracle.com/cd/B19306_01/server.102/b14200/clauses002.htm: > > A primary key constraint combines a NOT NULL constraint and a unique >> constraint in a single declaration. That is, it prohibits multiple rows >> from having the same value in the same column or combination of columns and >> prohibits values from being null. > > > SQLite, of course, is special (http://www.sqlite.org/lang_createtable.html): According to the SQL standard, PRIMARY KEY should always imply NOT NULL. > Unfortunately, due to a long-standing coding oversight, this is not the > case in SQLite. Unless the column is an INTEGER PRIMARY KEY SQLite allows > NULL values in a PRIMARY KEY column. We could change SQLite to conform to > the standard (and we might do so in the future), but by the time the > oversight was discovered, SQLite was in such wide use that we feared > breaking legacy code if we fixed the problem. So for now we have chosen to > continue allowing NULLs in PRIMARY KEY columns. But, > Developers should be aware, however, that we may change SQLite to conform > to the SQL standard in future and should design new programs accordingly. I would consider Django 1.4+ to fall under the "new programs" umbrella :) -- Regards, Ian Clelland -- 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: PUT and post data
On Thu, Dec 1, 2011 at 10:14 AM, Thibault Jouannic wrote:
> Hi django devs,
>
> I'm looking for some news about the ticket #12635.
>
> https://code.djangoproject.com/ticket/12635
>
> Today, it's still impossible to easily access post data when sending a
> PUT request. Since I'm trying to build a restful web service using
> django, this is quite a problem.
>
> It's been told in another thread to use the `request.raw_post_data`
> attribute, however I cannot think of a valid reason for why put data
> could'nt be has easily accessible as post data.
>
> I see in the ticket that the 1.4 milestone was deleted. Was the ticket
> abandoned?
>
> I've seen a lot of discussions and tickets about rest, and I know it's
> a complex issue, but since I'm kinda new here, it's hard to know what
> is the current state of the problem.
>
>
"GET data" and "POST data" are just the terms that are used for data that
appears in the URL query string, and the HTTP request body, respectively.
They don't actually have anything to do with the request method used*
If you receive a POST (or a PUT, or DELETE) at
http://www.example.com/web_service?param=value, for example, then
request.GET will be populated with {'param': 'value'}, no matter what the
method is.
Similarly, if you attach a body to a PUT request, then it will be available
just as in a POST.
request.POST is designed to work with HTML form submissions; data in either
x/www-form-urlencoded or multipart/form-data, and it contains any key/value
pairs parsed out of that sort of data. That's usually not what you attach
to a PUT request, though (and occasionally, it's not what you attach to a
POST, either). In that case, request.raw_post_data is the way to get at the
unprocessed request body.
What you are after is just the body of the HTTP request, and it happens to
be called 'raw_post_data' in django. It's a bit of an unfortunate name,
since there is no difference between the payload of a POST request and that
of a PUT request, but that's what it is.
Ian
* RFC-2616 prohibits a body on certain kinds of requests, so in practice,
you won't see "POST data" on a GET or DELETE request, but you could see
"GET data" on pretty much anything.
--
Regards,
Ian Clelland
--
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: Deprecate change pk + save behavior for 1.4
On Thu, Dec 1, 2011 at 6:38 PM, Anssi Kääriäinen wrote: > On Nov 30, 2:26 pm, Kääriäinen Anssi wrote: > \> The other way is storing old_pk in model._state, and compare the PK to > > that when saving. If changed, error. This would work best if there was a > > NoneMarker object for the cases where there is no PK from DB, so you > could > > solve #14615 easily, too. > > I tried the second approach, and the mutable object based fields makes > it basically unworkable. The problematic case turned out to be > FileField. Now, that could be hacked around, but other inplace-mutable > fields do exist, at least in user code. > That's really too bad; I was hoping that that approach would work. (Also, I really hope nobody is using a FileField for a primary key ;) ) Is the problem here that we can't reliably tell whether the data that is going out to the DB layer has changed? I would think that no matter how the data is modified (in-place vs. setattr), that the one thing we could rely on, and the one thing that actually matters in this situation, is the serialised representation of the data. For a FileField, that would be the filesystem path (editing the file in place without changing the path wouldn't give you the duplication problems that you are having); for an IntegerField, it's just the number itself. It should be the case that, no matter what sort of python magic a particular developer has added, it is equivalence at the SQL level that is causing problems. Maybe it's because I haven't tried to hack at this myself, but I can't see why storing a copy of the PK fields DB-representation on load, and checking them on save, isn't sufficient. There is a memory cost, but it should be small, unless you have very large fields for primary keys in your database, in which case you are already suffering from them, certainly :) -- Regards, Ian Clelland -- 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 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase
After a lot of troubleshooting, and fun installing Python3.2 under
virtualenv (Vinay, I think I ran into the same issue as you here:
https://github.com/pypa/virtualenv/issues/194), I almost have the complete
test suite running under MacPorts Python 3.2.2.
The one unexpected error I am getting is this one:
==
ERROR: test_existing (regressiontests.templates.loaders.EggLoaderTest)
A template can be loaded from an egg
--
Traceback (most recent call last):
File
"/Users/ian/Code/Frameworks/py3k_django/build/tests/regressiontests/templates/loaders.py",
line 88, in test_existing
contents, template_name = egg_loader.load_template_source("y.html")
File
"/Users/ian/Code/Frameworks/py3k_django/3k/django/template/loaders/eggs.py",
line 28, in load_template_source
raise TemplateDoesNotExist(template_name)
django.template.base.TemplateDoesNotExist: y.html
--
I'm going to look further into that later tonight.
While installing Vinay's port (cloned freshly this morning from Bitbucket),
I had to edit four files, in order to get them to run under Python 3:
3k/django/contrib/gis/forms/fields.py: One multi-line split string was
being transformed incorrectly
Was:
'transform_error' : _(u('An error occurred when transforming the geometry
')
'to the SRID of the geometry form field.'),
Should have been:
'transform_error' : _(u('An error occurred when transforming the geometry '
'to the SRID of the geometry form field.')),
3k/django/contrib/gis/geoip/tests.py: Two unicode strings had their 'u'
prefix left on
3k/django/db/backends/oracle/creation.py
3k/django/utils/dictconfig.py: Both of these files were using the 'except
, ' syntax, without the 'as' keyword.
Once I fixed those, (and manually copied the tests directory into build/)
then the pre-compiler would work, and the test suite would run.
Did I miss a step here, or not see an error which should have been
corrected earlier? Nobody else has commented about Python3 syntax errors,
so I'm thinking it's my process.
--
Regards,
Ian Clelland
--
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 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase
On Mon, Dec 5, 2011 at 5:08 PM, Vinay Sajip wrote:
> On Dec 6, 12:45 am, Ian Clelland wrote:
> > After a lot of troubleshooting, and fun installing Python3.2 under
> > virtualenv (Vinay, I think I ran into the same issue as you here:
> https://github.com/pypa/virtualenv/issues/194), I almost have the complete
> > test suite running under MacPorts Python 3.2.2.
>
> That's good news about the state of the tests on MacPorts 3.2.2. I
> hope Carl reads your mail about the virtualenv issue :-)
>
> > While installing Vinay's port (cloned freshly this morning from
> Bitbucket),
> > I had to edit four files, in order to get them to run under Python 3:
> [snip]
> > Did I miss a step here, or not see an error which should have been
> > corrected earlier? Nobody else has commented about Python3 syntax errors,
> > so I'm thinking it's my process.
>
> No, I got those today, too - but not on earlier days, for many days. I
> suspect that it's something to do with merging upstream changes into
> my port, but I haven't pinned it down. I pushed my changes this
> afternoon, so you could try pulling my changes and re-testing.
>
Those definitely work better -- I can go from download to testing, with
only having to copy over the build directory. The only test failure I still
get is this one:
==
ERROR: test_existing (regressiontests.templates.loaders.EggLoaderTest)
A template can be loaded from an egg
--
Traceback (most recent call last):
File
"/Users/ian/Code/Frameworks/py3k_django/build/tests/regressiontests/templates/loaders.py",
line 88, in test_existing
contents, template_name = egg_loader.load_template_source("y.html")
File
"/Users/ian/Code/Frameworks/py3k_django/3k/django/template/loaders/eggs.py",
line 28, in load_template_source
raise TemplateDoesNotExist(template_name)
django.template.base.TemplateDoesNotExist: y.html
--
It appears that an error is being returned earlier, in line 25 of
template/loaders/eggs.py.
return (resource_string(app, pkg_name).decode(settings.FILE_CHARSET),
'egg:%s:%s' % (app, pkg_name))
pkg_resources.resource_string is returning a Py3k <'str'>, which has an
'encode' method, but no 'decode'. The AttributeError is getting swallowed
and re-raised as a TemplateDoesNotExist.
pkg_resouces comes from distribute, which I just installed this morning for
the virtualenv
(Pdb) import pkg_resources
(Pdb) pkg_resources.__file__
'/Users/ian/.virtualenvs/py3k_django/lib/python3.2/site-packages/distribute-0.6.21-py3.2.egg/pkg_resources.py'
If I replace line 25 with this block:
resource_name = resource_string(app, pkg_name)
if hasattr(resource_name, 'decode'):
resource_name = resource_name.decode(settings.FILE_CHARSET)
return (resource_name, 'egg:%s:%s' % (app, pkg_name))
then all (expected) tests pass.
--
Regards,
Ian Clelland
--
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: Small problem with HttpResponseRedirect
On Mon, Dec 5, 2011 at 2:00 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:
> Not sure if this should have a bug ticket raised or not.. wanted to get
> core devs thoughts.
>
>
> _redir = "//your/path/with/an/extra/slash/for/whatever/reason"
> HttpResponseRedirect(_redir)
> returns "Location:
> http://your/path/with/an/extra/slash/for/whatever/reason";
>
> _redir = "/your/path/with/no/extra/slash"
> HttpResponseRedirect(_redir)
> returns "Location: /your/path/with/no/extra/slash"
>
> It seems that if the URL has an extra slash on the start of it,
> redirection doesn't work properly.
>
> Should this be classed as bad user sanity checking, or
> HttpResponseRedirect() not being flexible enough?
>
> I personally feel it's not being flexible enough, but would be good to
> hear your thoughts.
>
> Cal
>
Not a core dev, but I can offer my thoughts anyway :)
First, your server should not ever be sending:
Location: /your/path/with/no/scheme
According to RFC2616, and to the comments in django/http/__init__.py, the
Location header *must* contain an absolute URL.
django.http.utils.fix_location_header is supposed to be called on every
response, by the base WSGI handler, and should fix up any URLs that don't
already start with 'http://' or 'https://'. If it doesn't include a host
part (after a //), then Django should insert the name of the currently
active host.[1]
Second, a URL starting with a // is perfectly valid, and is supposed to
represent a "scheme-relative" URL. ie., it includes the hostname, path, and
query string; everything but the actual scheme (http: or https:) They're
useful for constructing links to resources where you have to preserve
https, if the current page is secure, (to prevent browser warnings, privacy
leaks, security holes).
There was some discussion on stack overflow last week on this[2]; it mostly
relates to using // urls in markup, not in a header, though.
I think the existing code is correct; my tests show that
HttpResponseRedirect("//host/path/to/resource/")
yields
Location: http://host/path/to/resource/
and
HttpResponseRedirect("/path/to/resource/")
yields
Location: http://127.0.0.1/path/to/resource/
In both cases, the response fixes have constructed the correct absolute
url, based on what I used to construct the redirect.
I think that if you're occasionally getting a double slash in front of your
redirect urls, you should probably fix the code that is generating them, or
create a new subclass of HttpResponseRedirect that eliminates the redundant
character before adding the header.
> --
> 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.
>
[1] This used to be the value from the Host: request header, but I think
recent security patches have changed that.
[2]
http://stackoverflow.com/questions/8343942/what-is-the-effect-of-starting-a-url-with-and-leaving-out-http
(also referenced:
http://stackoverflow.com/questions/4978235/absolute-urls-omitting-the-protocol-scheme-in-order-to-preserve-the-one-of-the
and
four or five other related questions)
--
Regards,
Ian Clelland
--
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 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase
On Tue, Dec 6, 2011 at 2:33 AM, Vinay Sajip wrote: > > On Dec 6, 4:18 am, Ian Clelland wrote: > > > If I replace line 25 with this block: > > > > resource_name = resource_string(app, pkg_name) > > if hasattr(resource_name, 'decode'): > > resource_name = resource_name.decode(settings.FILE_CHARSET) > > return (resource_name, 'egg:%s:%s' % (app, pkg_name)) > > > > then all (expected) tests pass. > > Thanks very much for this fix, I have applied it and tested in a venv, > and can confirm your findings. I have pushed this to BitBucket. I have > installed a PIL Python 3 port and bugs in that are causing 1 failure > and 1 error; everything else passes. > > Regards, > > Vinay Sajip > > -- > 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. > > Without doing anything else, I installed pymysql, and made a few minimal modifications to use that module in the mysql backend, and fixed one Python3 incompatibility issue in db/backends/mysql/compiler.py. First initial test run indicates that there's still some work to do :) Ran 4429 tests in 18128.079s FAILED (failures=11, errors=375, skipped=114, expected failures=2, unexpected successes=1) (yeah, that's 18k seconds, just a bit over 5 hours, but mysql has never been fast on OS X; something about the way it rolls back the database between tests) My earlier tests took 439s, as a point of reference. Almost all of those errors appear to be of the same form: == ERROR: testApprovePost (regressiontests.comment_tests.tests.moderation_view_tests.ApproveViewTests) POSTing the delete view should mark the comment as removed -- Traceback (most recent call last): File "/Users/ian/Code/Frameworks/py3k_django/build/tests/regressiontests/comment_tests/tests/moderation_view_tests.py", line 142, in testApprovePost self.client.login(username="normaluser", password="normaluser") File "/Users/ian/Code/Frameworks/py3k_django/3k/django/test/client.py", line 514, in login login(request, user) File "/Users/ian/Code/Frameworks/py3k_django/3k/django/contrib/auth/__init__.py", line 73, in login request.session.cycle_key() File "/Users/ian/Code/Frameworks/py3k_django/3k/django/contrib/sessions/backends/base.py", line 253, in cycle_key self.delete(key) File "/Users/ian/Code/Frameworks/py3k_django/3k/django/contrib/sessions/backends/db.py", line 75, in delete Session.objects.get(session_key=session_key).delete() File "/Users/ian/Code/Frameworks/py3k_django/3k/django/db/models/base.py", line 583, in delete collector.delete() File "/Users/ian/Code/Frameworks/py3k_django/3k/django/db/models/deletion.py", line 61, in decorated func(self, *args, **kwargs) File "/Users/ian/Code/Frameworks/py3k_django/3k/django/db/models/deletion.py", line 228, in delete sender=model, instance=obj, using=self.using File "/Users/ian/Code/Frameworks/py3k_django/3k/django/dispatch/dispatcher.py", line 174, in send response = receiver(signal=self, sender=sender, **named) File "/Users/ian/Code/Frameworks/py3k_django/build/tests/modeltests/signals/tests.py", line 57, in pre_delete_test (instance, instance.id is None) AttributeError: 'Session' object has no attribute 'id' Now, on to tweaking MySQL and fixing a couple of those errors -- Regards, Ian Clelland -- 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 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase
On Tue, Dec 6, 2011 at 5:05 PM, Vinay Sajip wrote: > > On Dec 6, 11:29 pm, Ian Clelland wrote: > > > > Without doing anything else, I installed pymysql, and made a few minimal > > modifications to use that module in the mysql backend, and fixed one > > Python3 incompatibility issue in db/backends/mysql/compiler.py. > > which was? > > > First initial test run indicates that there's still some work to do :) > > > > Ran 4429 tests in 18128.079s > > FAILED (failures=11, errors=375, skipped=114, expected failures=2, > > unexpected successes=1) > > > > (yeah, that's 18k seconds, just a bit over 5 hours, but mysql has never > > been fast on OS X; something about the way it rolls back the database > > between tests) > > I presume you've tried the advice given here: > > http://www.stereoplex.com/blog/speeding-up-django-unit-test-runs-with-mysql > > I haven't yet, but that's where I remember reading why MySQL tests are always slow on the mac. Thanks for the pointer again, though -- hopefully it speeds up testing tonight. I have had to fix a couple of bugs in pymysql, but I think I am eliminating most of the errors. Once I can plug my laptop in to run a full test suite, I'll post the results. -- Regards, Ian Clelland -- 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 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase
> * compiler.py still had a map(None) call, that I replaced with izip_longest. > > The biggest change was just adding izip_longest to utils.py3 and > utils.itercompat. I had the same issue with MySQL -- I used a block like this: try: from itertools import zip_longest except ImportError: # python 2.x from itertools import izip_longest as zip_longest The code doesn't really seem to mind; iterator or generator, so I didn't think it was worth making an exact compatibility function > 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. > > -- Regards, Ian Clelland -- 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 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase
wrote: >> > >> > Without doing anything else, I installed pymysql, and made a few minimal >> > modifications to use that module in the mysql backend, and fixed one >> > Python3 incompatibility issue in db/backends/mysql/compiler.py. >> >> which was? (missed that earlier) It was the use of None as the first argument to map(), which Python 2 accepts, and happily zips its remaining arguments, but Python 3 throws a TypeError (sensibly, as None is not a callable) >> >> > First initial test run indicates that there's still some work to do :) >> > >> > Ran 4429 tests in 18128.079s >> > FAILED (failures=11, errors=375, skipped=114, expected failures=2, >> > unexpected successes=1) >> > >> > (yeah, that's 18k seconds, just a bit over 5 hours, but mysql has never >> > been fast on OS X; something about the way it rolls back the database >> > between tests) >> >> I presume you've tried the advice given here: >> >> http://www.stereoplex.com/blog/speeding-up-django-unit-test-runs-with-mysql >> > > I haven't yet, but that's where I remember reading why MySQL tests are always slow on the mac. Thanks for the pointer again, though -- hopefully it speeds up testing tonight. Actually, it turns out that I had applied that to my my.cnf -- everything but the default storage engine. I added that anyway, but the tests are still just as slow. They've been going for almost 4 hours again now; I'll be able to report back once they're done. > I have had to fix a couple of bugs in pymysql, but I think I am eliminating most of the errors. Once I can plug my laptop in to run a full test suite, I'll post the results. > > -- > Regards, > Ian Clelland > > -- Regards, Ian Clelland -- 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 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase
On Tuesday, December 6, 2011, Ian Kelly wrote: > itertools.izip_longest was added in Python 2.6, though, so a > compatibility function is needed for Python 2.5. Ahh, that's a good catch. I'll have to make use of your solution, then. Ian -- Regards, Ian Clelland -- 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 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase
On Wed, Dec 7, 2011 at 4:14 AM, Vinay Sajip wrote:
> On Dec 7, 5:53 am, Ian Clelland wrote:
> > On Tuesday, December 6, 2011, Ian Kelly wrote:
> > > itertools.izip_longest was added in Python 2.6, though, so a
> > > compatibility function is needed for Python 2.5.
> >
> > Ahh, that's a good catch. I'll have to make use of your solution, then.
> >
>
> I've already pulled Ian Kelly's changes from his BitBucket repo. Which
> MySQL driver are you using for Python 3? I started looking at
>
> git://github.com/davispuh/MySQL-for-Python-3.git
>
> but it appears to expect queries formatted with {} rather than %s, so
> it doesn't seem that I can use it.
>
I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a
drop-in replacement for MySQLdb. The biggest change is in the data
converters -- they have a different function signature from MySQLdb's.
I have had to make a couple of patches to the library, which I hope to get
applied upstream, otherwise it's working pretty well, so far.
I'm down to four failures and one error now -- I'll post back once those
are done, with a set of patches, hopefully.
Ian
>
> Regards,
>
> Vinay Sajip
>
> --
> 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.
>
>
--
Regards,
Ian Clelland
--
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 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase
On Wed, Dec 7, 2011 at 7:55 AM, Vinay Sajip wrote: > > On Dec 7, 3:50 pm, Ian Clelland wrote: > > I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a > > drop-in replacement for MySQLdb. The biggest change is in the data > > converters -- they have a different function signature from MySQLdb's. > > > > I have had to make a couple of patches to the library, which I hope to > get > > applied upstream, otherwise it's working pretty well, so far. > > By "library" I assume you're referring to PyMySQL. Is there a repo I > can clone, so I can start testing with MySQL? > There is now :) https://clell...@github.com/clelland/PyMySQL.git It needs some supporting code in backends/mysql/base.py -- I'll start another discussion thread for those issues. (i.e. Do we support pymysql in the mysql backend, or do we create a mysql_pymysql, akin to postgres_psycopg2?) > > > I'm down to four failures and one error now -- I'll post back once those > > are done, with a set of patches, hopefully. > > Great - thanks! > > Regards, > > Vinay Sajip > > -- > 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. > > -- Regards, Ian Clelland -- 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.
Adding Support for PyMySQL (for Python 3)
Hi, all --- This is a proposal to add support in Django for PyMySQL[1] as an optional replacement for MySQLdb. I've been working with Vinay Sajip's Python 3-compatible branch; trying to get MySQL support working, and I have had a great deal of success, using PyMySQL as a back end, rather than MySQLdb. MySQLdb does not support Python3, and I haven't seen any indication online that it will be supporting Python3 any time soon. PyMySQL is a pure python implementation of PEP 249 for MySQL, and supports Python 2.4 - 3.2, and MySQL 4.1 and higher. It is nearly a plug-in-replacement for MySQLdb (although there are a few compatibility issues that I have tried to take care of in Django backend code) My approach so far has been to patch django/db/backends/mysql: - Try to import MySQLdb, and then MySQLdb.converters and MySQLdb.constants. - If that fails, try to import pymysql, and pymysql.converters and pymysql.constants - Whichever succeeds, set a module-level variable 'backend' to indicate the backend that we are using. - Patch the data-type conversions appropriately, depending on the backend that was used. So far, that's it -- and I'm down to just a couple of unit test failures, but those may even be Python3 issues; I haven't tracked them all down yet. My questions, then: 1. Is PyMySQL appropriate for django-core, in the opinion of the core devs? There isn't another stable Python 3-compatible mysql adapter, as far as I know, and I don't think Django could move to Python 3 support without at least the currently-supported databases. 2. Is this the right approach? I know that in the past, we have had multiple backends for PostgreSQL, in different modules under django.db.backends, but in this case, the modules are almost 100% compatible, except for the module names themselves, and the calling conventions for the data conversions. It feels more like the situation with JSON libraries, where we just load whichever one is available, and present the same outward api to the developer. 3. Code speaks, I know -- what's the best way to share this? I've sent Vinay a patch, but that's for his Py3k branch, and might not get the audience that something like this needs. I'm doing it for Py3k support, but ideally it would work just as well under Python 2.x. Should I set up a public repository somewhere, or just open a ticket and attach patches? Thoughts? Flames? Regards, Ian Clelland [1] Original at https://github.com/petehunt/PyMySQL, my patches for better Python 3 support at https://github.com/clelland/PyMySQL -- 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: Adding Support for PyMySQL (for Python 3)
On Wed, Dec 7, 2011 at 12:48 PM, Alex Gaynor wrote: > It's a fine goal, though I'm not convinced this should necessarily ship > with Django given PyMySQL has relatively few users. Agreed; I just don't know of another way to support Python 3 and MySQL, without pushing the MySQLdb developers to add support. (This is the Python 3 upgrade catch-22, and I'm looking for a way out of it). > However, the approach is the wrong one, django database backends should > be really split up between the parts that are database specific, and the > parts that are driver specific, Do you mean to say that putting support for two drivers in django.db.backends.mysql is wrong, or that the django backends need to be refactored? I had started off by writing a new backend, mysql_pymysql (in the spirit of postgres_psycopg2), but there is so much overlap that it didn't make sense to me to have to duplicate all of the code in a separate module, when most of what I was doing was just changing the imports at the top of base.py and introspection.py. I would be happy putting this out as a separate backend, which just imported all of its functionality (and future bug fixes) from django.db.backends.mysql, but I can't even import the django backend modules in an environment which doesn't have MySQLdb installed -- say, any Python 3 environment. I'll think some more on it, but if you have any architectural suggestions, I'm very open to them. > that way someone can write an external driver that uses, say, the > postgresql spcific stuff but make it run on the 500 other postgresql > drivers. > > Alex > > Ian -- Regards, Ian Clelland -- 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: Adding Support for PyMySQL (for Python 3)
ll under Python 2.x. Should I set up a > public repository somewhere, or just open a ticket and attach patches? > > I asked Martin von Löwis who maintains the Py3K branch in Django official > SVN repo to review Vinay's changes and merge them, as long as you manage to > get patches in line with their work I think we're fine. > Jannis > > -- > 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. > > -- Regards, Ian Clelland -- 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: Adding Support for PyMySQL (for Python 3)
On Wed, Dec 7, 2011 at 1:07 PM, Alex Gaynor wrote: > I'm saying database backends need badly to me refactored to split up these > two seperate concerns. > Agreed, then. Is there a ticket for this already? (I don't see anything in the DB component, looking for 'backend' anywhere in the summary/keywords/description, but I will allow that my trac-fu may be weak) I'm looking into what it would take to separate these concerns. -- Regards, Ian Clelland -- 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 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase
Just finished a full suite test, with the PyMySQL adapter, and I'm down to 5 failures and 2 errors: Gory details: http://dpaste.com/hold/667992/ -- Regards, Ian Clelland -- 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: Adding Support for PyMySQL (for Python 3)
On Wed, Dec 7, 2011 at 9:59 PM, Vinay Sajip wrote: > On Dec 7, 8:38 pm, Ian Clelland wrote: > > > Thoughts? > > A further update: of my 24 failures, 17 are in multiple_database, as > are 3 failures. But I get the same errors with unpatched Django 2.x > running with the standard 2.x MySQLdb adapter, so it might be > something to do with my MySQL configuration. > > There also seem to be a number of unicode-related errors there (mixed collations; unrecognized characters) -- Could that be related to the lines in your patched mysql/base.py: if not PY3: kwargs['use_unicode'] = True use_unicode used to be unconditional on the database connection; now you've removed it, but just for Python 3. -- Regards, Ian Clelland -- 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: Adding Support for PyMySQL (for Python 3)
On Wed, Dec 7, 2011 at 11:40 PM, Vinay Sajip wrote: > > On Dec 8, 6:46 am, Ian Clelland wrote: > > > > There also seem to be a number of unicode-related errors there (mixed > > collations; unrecognized characters) -- Could that be related to the > lines > > I'm also getting the same errors on 2.x with the 2.x adapter on > unpatched Django - so it might well be to do with my MySQL > installation (stock 5.1.58 for Ubuntu 64-bit). > > Could certainly be. The swedish collation you are seeing ought to be the compiled-in default, if nothing else has been specified for the database or the table. It might be worth trying with my latest Django repo and my patched > MySQLdb on your installation, if you have the time and inclination... > > I'll see what I can do about that, if I can get it to compile > BTW are you on IRC? If so, what nickname do you go by? > Not all the time; I just fired it up, though. You can find me as 'clelland' on freenode -- Regards, Ian Clelland -- 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: Adding Support for PyMySQL (for Python 3)
On Thursday, December 8, 2011, Jens Diemer wrote: > Am 07.12.2011 21:38, schrieb Ian Clelland: >> >> PyMySQL is a pure python implementation of PEP 249 for MySQL, and supports >> Python 2.4 - 3.2, and MySQL 4.1 and higher. > > Another goal of PyMySQL would be to use Django + MySQL with PyPy, isn't it? > You know, I hadnt thought of it, but that would definitely go a long way towards making that possible! Ill see if I can polish up a proposal for splitting up the backend code into SQL and driver code, but I'll try to get a separate pymysql backend up in a repository somewhere for people to try out as well. Ian > See also: https://groups.google.com/group/django-users/browse_thread/thread/cbef429d014c1ad9/ > > -- > > Mfg. > > Jens Diemer > > > > http://www.jensdiemer.de > > -- > 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. > > -- Regards, Ian Clelland -- 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 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase
Update: As of last night, between Vinay's patches, some of my own, and some MySQL configuration tweaks, I think I have all (expected) tests passing with the PyMySQL adapter. I still need to run one more complete pass through the test suite to be sure that I haven't introduced any regressions, but it's looking pretty good. I also managed to compile Vinay's clone of the MySQLdb driver for python 3, and with just one extra patch, it looks like all tests are passing with that code as well! On Wednesday, December 7, 2011, Ian Clelland wrote: > Just finished a full suite test, with the PyMySQL adapter, and I'm down to 5 failures and 2 errors: > Gory details: > http://dpaste.com/hold/667992/ > > -- > Regards, > Ian Clelland > > -- Regards, Ian Clelland -- 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 port - all MySQL tests now pass on 2.6.7 and 3.2.2 with the same codebase
I now have Django passing its entire unit test suite with the MySQL and SQLite backends, on Python 2.6.7 and Python 3.2.2 Details: Common environment: OS X 10.6.8 MacPorts 2.0.3 MySQL 5.1.60 from MacPorts SQLite 3.7.9 from MacPorts Django from https://bitbucket.org/vinay.sajip/django/ hash 6b1413a9901a<https://bitbucket.org/vinay.sajip/django/changeset/6b1413a9901a> Python 2: Python 2.6.7 from MacPorts MySQLdb 1.2.3 from MacPorts Python 3: Python 3.2.2 from MacPorts MySQLdb-for-Python-3 from https://github.com/clelland/MySQL-for-Python-3 commit 5b7130f (should be the same as https://github.com/vsajip/MySQL-for-Python-3) Results: Python 2, MySQL: Ran 4478 tests in 2935.590s OK (skipped=83, expected failures=3) Python 3, MySQL: Ran 4432 tests in 3000.029s OK (skipped=88, expected failures=2, unexpected successes=1) Python 2, SQLite: Ran 4478 tests in 449.281s OK (skipped=91, expected failures=3) Python 3, MySQL: Ran 4432 tests in 446.825s OK (skipped=96, expected failures=2, unexpected successes=1) Thanks a lot to Vinay for his amazing work pulling this all together! -- Regards, Ian Clelland -- 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 port - all MySQL tests now pass on 2.6.7 and 3.2.2 with the same codebase
On Thu, Dec 8, 2011 at 5:56 PM, Vinay Sajip wrote: > > On Dec 8, 11:39 pm, Ian Clelland wrote: > > I now have Django passing its entire unit test suite with the MySQL and > > SQLite backends, on Python 2.6.7 and Python 3.2.2 > > Ian, > > Thanks for the comprehensive summary and eliminating those last few > issues on the MySQL backend. One more thing which might be useful to > have for comparison purposes is the test results when run on 2.x with > an unmodified Django (from the mirror at > https://bitbucket.org/django/django/), > so that people can see what the potential performance penalty is for > calling u() and b() all over the place. I realise that it's not going > to be a scientific comparison, but it will probably show up if there > is appreciable overhead (I haven't found that to be the case, but it > might vary based on platforms and backends). > > I posted these from the tests (for the sqlite backend) run on my > Ubuntu VM, in response to a question from Armin Ronacher: > > Django on 2.x unported: 4482 tests in 368.972s, skipped = 90 > Django on 2.x, with u(), b(), sys.exc_info() etc: 4478 tests in > 367.635s, skipped = 90 > Django on 3.x, with u(), b(), sys.exc_info() etc: 4423 tests in > 372.946s, skipped = 96 > > It would be interesting to see if a similar pattern emerges on OSX. > > I upgraded to the latest trunk head, and re-ran the tests with the same Python 2.6 virtualenv Totally unscientific results: SQLite: Ran 4482 tests in 442.362s OK (skipped=91, expected failures=3) MySQL: Ran 4482 tests in 2917.268s OK (skipped=83, expected failures=3) Unscientifically, trunk without the Python 3 patches runs 1.5% faster w/ SQLite, 0.6% faster w/ MySQL. (based on a sample size of 1 :) ) -- Regards, Ian Clelland -- 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 port - all MySQL tests now pass on 2.6.7 and 3.2.2 with the same codebase
On Fri, Dec 9, 2011 at 8:36 AM, Tom Evans wrote: > On Fri, Dec 9, 2011 at 4:17 PM, Ian Clelland wrote: > > Unscientifically, trunk without the Python 3 patches runs 1.5% faster w/ > > SQLite, 0.6% faster w/ MySQL. (based on a sample size of 1 :) ) > > > > I know you put the word 'unscientifically' in there, but you can draw > no conclusions from doing one run of each like that. See my reply > earlier in the week on how to simply and easily do valid statistical > testing. > > http://osdir.com/ml/django-developers/2011-12/msg00162.html > > I posted the results to have at least a single data point, as a "things don't appear to be wildly different" reassurance. Agreed, that the confidence interval is probably big enough to drive a bus through, and that any claims of "faster" or "slower" are completely unjustified statistically*. I'm just scripting my test runner to switch directories to do the a/b testing that you were suggesting earlier; perhaps I'll have some numbers to post in a couple of hours. * Except of course, if I had phrased it as the true fact that my two test runs with Python 2.6 completed more quickly than my test runs with Python 3.2, which, perhaps, is what I should have done. -- Regards, Ian Clelland -- 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 port - all MySQL tests now pass on 2.6.7 and 3.2.2 with the same codebase
On Fri, Dec 9, 2011 at 11:43 AM, Joe & Anne Tennies wrote: > The thing is, we aren't trying to "scientifically correct" statistics. > What we're aiming to say is, "This is not so wildly different as to be of > any concern." We aren't looking for minor difference, but orders of > magnitude difference. > > Agreed. But in the name of science (science!) I've run the a/b test that Tom suggested (with the abababaaabbb pattern, even), and these were the results: Trunk Patches Run #1 443.093448.851 Run #2 440.845445.338 Run #3 439.795445.746 Run #4 437.751462.278 Run #5 439.482460.737 Run #6 436.606461.509 Mean 439.595454.077 Std Dev2.288 8.245 (I won't speak as to whether all of these decimal places are warranted, but unittest reports milliseconds, so I'm sticking with three places all around) All times are in seconds. This was tested on Python 2.6.7, and SQLite, against Django trunk from this morning (a), and Vinay's 3k-compatible branch from yesterday (b). -- Regards, Ian Clelland -- 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 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase
On Fri, Dec 9, 2011 at 4:32 PM, Paul Egges wrote: > I was thinking the same thing. Make absolutely sure it works under 2.5-2.7 > and even if there are a couple of issues or items not fully tested under > 3.2.2 at least we will be moving in the right direction. > > My laptop just finished a run of tests overnight -- The branch passes the complete test suite now for me, under Python 2.5.6, 2.6.7, 2.7.2, and 3.2.2, with the sqlite, MySQLdb, and psycopg2 backends. (Sorry, no Oracle here.) -- Regards, Ian Clelland -- 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: Adding Support for PyMySQL (for Python 3)
On Thu, Dec 8, 2011 at 7:46 AM, Ian Clelland wrote: > > > On Thursday, December 8, 2011, Jens Diemer > wrote: > > Am 07.12.2011 21:38, schrieb Ian Clelland: > >> > >> PyMySQL is a pure python implementation of PEP 249 for MySQL, and > supports > >> Python 2.4 - 3.2, and MySQL 4.1 and higher. > > > > Another goal of PyMySQL would be to use Django + MySQL with PyPy, isn't > it? > > > > You know, I hadnt thought of it, but that would definitely go a long way > towards making that possible! > > Ill see if I can polish up a proposal for splitting up the backend code > into SQL and driver code, but I'll try to get a separate pymysql backend up > in a repository somewhere for people to try out as well. There is now a PyMySQL backend available on Github -- https://github.com/clelland/django-mysql-pymysql It leverages a lot of the code in django.db.backends.mysql; importing it where it can, and duplicating it where it has to. I hope to have a proposal by the weekend for splitting out the database adapter code from the backends, and then this project can get a lot lighter :) If you use my patches to PyMySQL, at https://github.com/clelland/PyMySQL, then the full django unit test suite (from trunk) will pass under Python 2.6.7. There are some character set handling issues with the upstream version at the moment. (And at this point, I'm veering dangerously close to django-users territory; If needed, I'll continue this thread with an announcement there) -- Regards, Ian Clelland -- 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: Django 1.4 alpha on December 22nd
On Fri, Dec 16, 2011 at 8:59 AM, Vinay Sajip wrote: > > On Dec 16, 12:45 am, Ian Kelly wrote: > > > The problem with merging it and labeling the support as "experimental" > > is that the changes are of such a fundamental nature that they could > > easily break things in 2.x, not just in Python 3. > > Agreed, it's too risky to merge in 1.4 this late in the day. As well > as passing the full suite, it would need to be tested in more real- > world scenarios (including with third-party apps) to be sure there > were no regressions in 2.x. > Seconded; although, like Joseph above, I have also thought that it would be helpful for module writers to have access to django.utils.py3, to be able to start writing code that will work on both Django 1.4 and 1.5+. I don't know if it's completely warranted; it would mean putting a piece of code into core that is untested, and isn't used by any part of core, but it would be handy to have. For my pymysql backend, I've just included my own minimal version of the file, just declaring the definitions that are needed for that piece, but I'n not sure how I'll ever be able to remove that, and still keep support for Django 1.4. It's looking right now like I'll have to release a Django 1.5 version of the backend in order to use django.utils.py3, or else just maintain my copy independently forever. > On the bright side, it does allow time for simplifying to allow > "except X as e:", and removal of u() and b() from the port, as well as > more extensive testing on both 2.x and 3.x. > > Regards, > > Vinay Sajip > > -- > 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. > > -- Regards, Ian Clelland -- 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: Don't assume that missing fields from POST data are equal to an empty string value.
On Thu, Jan 12, 2012 at 1:02 AM, Tai Lee wrote: > Donald, > > Thanks for sharing your feedback with everyone. > > I do believe that there should be some kind of validation error or at > least a loud warning to the console or logs when a form is bound to > incomplete data. The only time when this should occur is for > "unsuccessful controls" such as unchecked radio buttons and > checkboxes. These shouldn't be a problem for Django, which already > normalises no value for a checkbox to False and any value for it to > True. > > I'm not sure that there is a widespread practice of submitting partial > forms with JS and still expecting the entire form to validate and save > is widespread, or even valid according to the RFC and HTML4 specs > which expect every successful control to be included in the form data. > You are using the word 'form' in two different contexts here -- There is the HTML , on the web page that a user can interact with -- this is simply a (mostly) formalized way for a user to submit data to a web service. (I say 'mostly' because, as we are discovering, there are edge cases where the handling of missing data is not completely specified.) Secondly, there is the Form object that exists with a Django application. This is the only form that we have complete control over, and it is the only place that we get to say that data is or is not 'valid'. There is definitely not a one-to-one correspondence between these two forms, and on the web, we can't assume that we have complete control over both of them. On the one hand, the HTML form is not the only way for a GET or POST request to be submitted. We need to consider, at least: - Modern, mainstream, buggy web browsers, like Chrome or Firefox - Older, mainstream, buggy web browsers - Non-mainstream web browsers - Other HTML-based User-Agents - Other REST-based applications - JavaScript submitting AJAX requests with data serialized from an object (not a form.submit() call), from any number of frameworks - curl / wget command-line interfaces - Python urllib / httplib requests (and other languages' equivalents) - URL query parameters Many of these would never even see or parse an HTML element, but they can all still provide data which will be used to construct a Django Form. We absolutely cannot claim to have the same level of confidence in the behaviour of these that we do by a reading of the RFC and an examination of the output from recent versions of Firefox and Chrome. And then, on the other side, data that comes into a view may be handled by multiple Form objects -- it's not uncommon to render fields in an HTML form that are going to be handled (or not) by several Django Forms. Even in the simplest case -- one HTML form, in a browser window, and one Django Form in a view -- it may even be the case that several fields were left off of the HTML form deliberately, because the same Django view and Form are also used by different pages on the site. In this case, I *want* to declare the fields to be optional, and then choose how to handle it after determining that the presented form fields are valid. With this proposal, I won't be able to, without subclassing the form or providing different views to handle each subset of data that I need to be able to accept. > Sure, I can see that forms could be fully or even partially submitted > via JS to perform AJAX validation in real time, but I don't see how > the form as a whole being invalid and validation errors on the missing > fields would impact that. > The problem is that AJAX (or any number of other methods) could be assembling data that should validate (ie, not for ajax validation, but with the intention of actually submitting data), and it may not be easy (or possible) to match the handling of null / blank / undefined values to what a browser would do. Not having the ability to get past a Django-mandated ValidationError would certainly impact the user experience in this case ;) -- Regards, Ian Clelland -- 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: Caching back-refernces on one-to-one fields
On Thu, Jan 19, 2012 at 1:27 PM, Adrian Holovaty wrote: > On Thu, Jan 19, 2012 at 12:15 PM, Carl Meyer wrote: > > I don't think Adrian is proposing anything as extensive as #17. What > > he's proposing (IIUC) wouldn't change the semantics of your sample code > > at all. All it would do is prepopulate the FK field on the results of a > > reverse-FK query, so the innermost "book.author" here doesn't need to do > > a query: > > > > for author in Author.objects.all(): > >for book in author.books.all(): > >book.author > > > > There wouldn't be any action-at-a-distance with other Book instances. > > Right, what Carl said -- no action-at-a-distance, just mere cache > population on each related object. I don't think there would be a risk > of backwards-incompatible side effects. > > It would certainly be worth at least a note in the release notes, as it is a change. The only situation where I can imagine someone relying on the current behaviour is in regression tests. I can see code like this being in place inside a test suite: def setUp(self): # We need a foo for every test in this test case self.foo = Foo.objects.get(id=1) def test_that_munges_are_really_saved(self): # Munge the bar. This should also set foo.baz to 12 bar = self.foo.bar munge_bar(bar) # check that the Foo really got updated. Before Yestermas, the Foo got updated # in memory, but the changes weren't being saved to the db self.assertEqual(bar.foo.baz, 12) This code would have been written with the current behaviour in place, and then completely forgotten about, buried in a suite of tests. It's easy to argue that the test code is incorrect, and should be using a different method to check the state of the database, but a test like this could continue to pass even in the event of an actual regression, and the developers wouldn't even know that their test was wrong. At least with a mention in the release notes, [diligent] developers would have been warned, and could check their code for these sorts of assumptions. -- Regards, Ian Clelland -- 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: Django participation in Google Summer of Code 2012
On Thursday, March 8, 2012, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > PEP 414 was accepted a few days ago. It's designed to make it easier to support 2.6, 2.7, 3.3+ on the same codebase. (finishes reading) Ugh. I'm starting to expect "PEP 499: In a last-ditch effort to encourage developers to adopt Python 3, it is declared that Python 3.9 will be exactly identical, in syntax and semantics, to Python 2.6.7" > I hope we'll take advantage of this new feature in Django; however, that means a large update (if not a reboot) of the py3k branch. Sarcasm aside, the only thing that this PEP does is force us to consider the minimum "starting version" of Python 3 that we want to support. If we declare that Django 1.5 will run on Python 3.2+, then we can ignore this PEP, and continue to use the u() and b() functions in the py3k branch, until 3.2 support is one day deprecated. On the other hand, if we can say that Django 1.5 will only support Python 3.3+, then there will never be a version of Django that needs to run on 3.2, and we can remove those functions from the py3k branch. Not really a reboot, just one transformation that can now be removed. (probably giving us a few % speed improvement) I don't think we should base the decision on this PEP, though. More important factors are probably the release schedule for 3.3 (August?) and how that meshes with the 1.5 development cycle, as well as vendor support for, and availability of, Python 3.3. Right now, there are a lot of people with access to long-term vendor-supported Python 3 environments, but nobody has 3.3. If we say that you can't upgrade to Python 3 until you can get a full 3.3 environment, how will that affect the usefulness of support in Django 1.5? 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: Django participation in Google Summer of Code 2012
On Thu, Mar 8, 2012 at 8:48 AM, Carl Meyer wrote:
> Hi Ian,
>
> On 03/08/2012 08:40 AM, Ian Clelland wrote:
> > On Thursday, March 8, 2012, Aymeric Augustin
> > > <mailto:aymeric.augus...@polytechnique.org>> wrote:
> >> PEP 414 was accepted a few days ago. It's designed to make it easier
> > to support 2.6, 2.7, 3.3+ on the same codebase.
> >
> > (finishes reading)
> > Ugh. I'm starting to expect "PEP 499: In a last-ditch effort to
> > encourage developers to adopt Python 3, it is declared that Python 3.9
> > will be exactly identical, in syntax and semantics, to Python 2.6.7"
>
> Let's please not rehash this discussion here, it was already beaten to
> death on the python-dev mailing list.
I have no doubt that it was; I'm afraid I haven't been following that list
very closely recently.
(And you're right, it's way-OT for django-dev)
> >> I hope we'll take advantage of this new feature in Django; however,
> > that means a large update (if not a reboot) of the py3k branch.
> >
> > Sarcasm aside, the only thing that this PEP does is force us to consider
> > the minimum "starting version" of Python 3 that we want to support. If
> > we declare that Django 1.5 will run on Python 3.2+, then we can ignore
> > this PEP, and continue to use the u() and b() functions in the py3k
> > branch, until 3.2 support is one day deprecated.
>
> Note that the current version of Vinay's port (since it was updated to
> account for dropping Python 2.5 support post-1.4) does not use u() and
> b() functions, it uses "from __future__ import unicode_literals". This
> means that the only place string wrappers are needed is in the few
> places where a "native string" is needed ("str" on both Python 2 and 3).
> Vinay posted numbers to python-dev indicating that there is no
> measurable performance overhead in the current port.
That's great -- That was from the post that came in over the holidays; I'll
definitely have to get back on testing that.
--
Regards,
Ian Clelland
--
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: Recommending a Python 3-compatible MySQL connector
> So, unless someone has a better idea, or Ian objects, I'm going to link to > his fork <https://github.com/clelland/MySQL-for-Python-3>. I don't object at all -- as long as the code it still passing tests, that is :) It was originally developed as a proof of concept when python 3 support was bring added for Django 1.5, and I haven't touched the code since that was released. I'll take a look and see if any work is going to be required to bring it in line with 1.6. Ian > > Trac ticket: https://code.djangoproject.com/ticket/20025 > Pull request: https://github.com/django/django/pull/1044 > > Any objections? > > -- > Aymeric. > > -- Regards, Ian Clelland -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: HMAC and timing based attacks - ticket #14445
On Mon, Oct 11, 2010 at 7:27 PM, Nick Phillips wrote: > First of all I should say that I'm no crypto expert, but I'm worried > about the key. Inclusion of fixed strings in a key for this type of use > rings alarm bells, as does the use of an ASCII key (albeit 50 chars > rather than the 20 recommended for use with SHA1 in HMAC), and the fact > that in reality, it's never going to get refreshed. > > On the key strength, I notice that RFC2104 recommends the hashing of the > key using the underlying hash function if the supplied key length is > greater than the hash output length. It would appear that this will > usually be the case, so Python's hmac module will probably be doing this > for us. However, there's rather a lot of "implicit" and "probably" in > that. I think that's more than just a recommendation -- the key for the underlying hash function needs to be of a certain size; there's not really an option to just let it remain longer. The text from the RFC reads Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC. And Python's hmac.py definitely does that; if the key is longer than the block size, it hashes it, and if it is shorter, then it pads it with zeroes. (That bit of code hasn't changed since at least Python 2.4) > And it would be perfectly possible that someone would update the > hash function used at some later date without realising the assumptions > that are being made. Might it not at least be a better idea to > explicitly ensure that the combination of fixed string and SECRET_KEY is > longer than the hash output length, and to hash the resulting string > before calling hmac.new? > That's a different issue -- if the key is *shorter* than the block size, then it has to be padded, which is what hmac.py does (again, mandated by RFC). Even if we pre-hashed the key to get it to exactly the block size in this case, we wouldn't actually be gaining any entropy. As I can tell, given the HMAC algorithm, if you were to swap, say, a 128-bit hash function with a 256-bit hash function, but kept the same 128-bit key, then the resulting MAC wouldn't be any less secure than the original. You could certainly improve it by going to a longer key at that point, but you don't have to. Perhaps the best thing for Django to do would be to issue a warning in that case that the key is shorter than it could be. -- Regards, Ian Clelland -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: ForeignKey with null=True
I've been bitten by this behaviour before, with code that looked like an_object.related_object_set.delete() where the foreign key could be null. On Thu, Dec 16, 2010 at 11:14 AM, Luke Plant wrote: > On Thu, 2010-12-16 at 10:10 -0800, tonnzor wrote: >> My idea was to fix this in a very straight way - change ForeignKey >> behavior (the piece of code that generates many_set method) - so it >> doesn't take into account null. >> >> Let me explain a bit more. If foreign key is null - then there's no >> link between Many and One object. So it many_set should return empty >> set disregarding DB state. > > This isn't true if the field pointed to (i.e. primary key by default) > allows NULL values - in that case a ForeignKey field with a NULL value > can and should return a non-empty set of values when the related objects > lookup is done. Why is this necessarily true? NULL is explicitly defined as the absence of a meaningful value. NULL values are not supposed to compare as equal to each other (this is why you need to test for "IS NULL" in SQL, rather than "= NULL") As well, in SQL, a foreign key join like select * from A join B on (A.fk = B.pk) will not join rows where A.fk and B.pk are both NULL. I would expect to be able to safely perform a query like delete from A where A.fk = NULL knowing that no rows would be deleted, and I expected (before I discovered this behaviour) the Django ORM to do the same. -- Regards, Ian Clelland -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Using asserts in test code
On Thu, Dec 23, 2010 at 5:44 AM, Luke Plant wrote: > Hi all, > > This is a question of test code style. > > In tests in my own projects, I use both the Python 'assert' statement > and the unittest TestCase.assert* methods, with the following > distinction: > > * The 'assert' statement is used to make assertions about the > assumptions built in to *this* bit of code (i.e. the test itself). > > * The TestCase.assert* methods are used to make assertions about the > outcome of the bit of code that is being tested. I like this pattern, at least as a notational style -- it is helpful to know when your tests are failing because they are making incorrect assumptions, rather than your application code being incorrect. The danger, of course, is that a failing 'assert' in your test setup could still be a bug in your code, rather than in the tests, and if you blindly fix the "bug" in the tests, then you end up solidifying a real bug in the code. (If your unit tests are factored properly, though, then the assertions you make about your test should themselves be tested in another location, so you should be able to rely on them.) > Looking at Django's test suite, I can find a few instances where this > pattern is followed (e.g. [1], [2]). Sometimes the assert statement is > also used where it is impractical to call TestCase methods (e.g. [3]). > There are a few instances where the 'assert' statement is called when it > should be a TestCase method (e.g. [4]). And there are many instances > where TestCase asserts are called, when IMO it should be an assert > statement. (e.g. [5]). >From a technical standpoint, I don't know if I see a real difference -- using "self.assert_(expr)" in a TestCase should never be impractical -- at least not more than calling "assert" directly. unittest.TestCase.assert_ just does the test manually, and raises AssertionError if it is passed anything false. The only difference between the two should be the fact that the raw "assert" can be optimized away. You'd have to call 'python -O manage.py test' deliberately for that, and I don't know why you'd ever want to optimize away parts of your test code. > So, the question is, going forward do we: > > 1) Use the pattern I outlined above? > 2) Use a different pattern (e.g. always use TestCase assert methods > where it is possible)? > 3) Simply not care about any of this? I'm +1 for #1, for consistency and clarity, but not for any technical reasons. -- Regards, Ian Clelland -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Using asserts in test code
On Thu, Dec 23, 2010 at 8:46 AM, Karen Tracey wrote:
> On Thu, Dec 23, 2010 at 8:44 AM, Luke Plant wrote:
> Perhaps it is not a problem when using bare asserts for this purpose, but I
> have grown to dislike asserts in testcases because they give so little
> information. For example, I am working with test code that uses bare asserts
> all over the place instead of the TestCase methods and when these tests fail
> I get errors like this:
>
> Traceback (most recent call last):
> File [snipped]
> assert res.status_code == 200
> AssertionError
>
> Well, great, status wasn't 200 but what was it? That's information I'd
> really rather get by default, so I much prefer assertEquals, which tells me:
>
> Traceback (most recent call last):
> File [snipped]
> self.assertEqual(res.status_code, 202)
> AssertionError: 302 != 200
>
> That actually gives me enough information that I might be able to fix the
> problem straight off.
>
> Do you not find the paucity of information provided by bare assert to be
> annoying?
Test cases should probably be using the two-argument form of assert:
assert (res.status_code == 200), "The status code returned was incorrect"
or even
assert (res.status_code == 200), ("%s != 200" % res.status_code)
At least some of the examples that Luke pointed to are using that
style, and it definitely makes more sense than just asserting a bare
fact, with no explanation.
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: RFC: Composite fields API
On Thu, May 12, 2011 at 5:16 PM, Carl Meyer wrote: > > On 05/12/2011 06:41 AM, Michal Petrucha wrote: > > On Thu, May 12, 2011 at 02:49:03PM +0100, Tom Evans wrote: > The value of a CompositeField will be represented by an instance of a > > CompositeValue class. This will be a descendant of tuple and will > > resemble namedtuple present in Python >= 2.5. It will support > > iteration, numbered indexing and access to individual field values > > using attributes corresponding to underlying field names. The order of > > values will be the same as the order of fields specified in the model > > definition. > > Yes, Tom is right of course - now that Python 2.5 is minimal version, we > can just use namedtuple. > As far as I can tell, namedtuple was added in Python 2.6, not 2.5, so a compatibility class may still be necessary. http://docs.python.org/library/collections.html#collections.namedtuple -- Regards, Ian Clelland -- 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: "c" date formating and Internet usage
On Sun, Jun 26, 2011 at 12:27 AM, Stephen Burrows <
stephen.r.burr...@gmail.com> wrote:
> This is related to the recent discussion about timezone-aware datetime
> storage [1] and how django doesn't do it. Since the date filter's "c"
> argument is handled with python's datetime.isoformat() [2] timezone-
> naive datetimes will not display a UTC offset.
>
> [1]
> http://groups.google.com/group/django-developers/browse_thread/thread/76e2b486d561ab79/0a46b72da6e9fb03
>
> [2]
> http://docs.python.org/library/datetime.html#datetime.datetime.isoformat
>
>
This isn't the same issue at all -- It may be related, but that discussion
thread was about storing timezone-aware timestamps in the database, not
about handling them in templates.
We can't simply say that "Django doesn't support
timezone-aware datetimes" -- besides being a ridiculous restriction, it's
not true: even in django.utils.dateformat there are several formatting codes
that take the input's timezone into account (see I, o, T, U).
Even the "r" formatting code, for RFC 822 formatting, takes the timezone, if
present, into account.
While I would use the documented claim of PHP compatibility as an argument
for this, it's not really a strong argument (and I wouldn't support just
removing the claim as a simple solution). A better argument is that the ISO
standard allows the timezone, various Internet standards and drafts
recommend or require it, and in many cases, it is available to Django, and
so we should include it when we can.
I generally find myself having to introduce a "proper" ISO-8601 formatting
string into every project, or supplement the time rendering with a
hard-coded timezone, when I can know it for sure (e.g., {{
timestamp|date:"c" }}+00:00 ). I would absolutely support adding a "real"
ISO-8601 formatter to the standard filter library.
--
Regards,
Ian Clelland
--
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: Timezone-aware storage of DateTime
On Thu, Jun 30, 2011 at 5:14 AM, Daniel Swarbrick < daniel.swarbr...@gmail.com> wrote: > On Jun 30, 11:06 am, Tom Evans wrote: > > > That is a domain specific assertion, I don't believe that is true in > > all cases. Typically, when we put things into the ORM, we expect to > > get the same things out again. If you consider viewing a timeline of a > > users activities, we might want to display the datetime of an event in > > both the viewing users timezone and the viewees timezone. If that > > information is discarded as irrelevant, then we could not do so. > > I personally find it relatively useless to know what the wall clock > time was when something happened in another timezone. I find it more > relevant to know what time it was for me, when said event occurred. In > most such cases, if the local time of the event was of importance, > then the *location* of the event would also be important, and probably > stored in the same DB model. If pytz is utilized, then we have a full > database of timezones at our disposal, and can derive from a location > what the local TZ was in that location at that particular moment in > time. More accurately, we can ascertain what the UTC offset was, and > whether DST was in effect - since those rules have changed through > history, and will continue to change. > While I agree with most of your points regarding database-storage of timestamps, the argument that wall clock time is 'relatively useless' certainly does not reflect my experience. As a counterexample, I have needed to store wall-clock time as well as time zones for future events, in scheduling applications. It is exactly because of the unpredictability of future DST changes (and, in very rare cases, wholesale time zone changes) that a one-time UTC conversion simply does not work for timestamps in the future. When an event is scheduled for a specific time, on a specific date in the future, then users expect that the web service will react at the appropriate wall clock time. An unforseen change in daylight saving time legislation should not have the effect of making the time in the database incorrect. Storing the time zone and wall clock time in the database allows the system to update the UTC timestamp appropriately whenever the Olson DB is updated. > > Western Samoa for example, will move to the other side of the > international date line on December 29th this year, effectively > jumping from a UTC-11 offset to a UTC+11 offset (skipping an entire > day in the process). Whilst such events are rare, it illustrates that > it is more useful to store the location of an event, plus have access > to the Olson tzdata DB, than to simply store a -11 or +11 offset > (which does not indicate whether DST was in effect). "Pacific/Samoa" > on the other hand can be looked up in tzdata, which will have an entry > stating that from 4 July 1892 until 29 December 2011, Samoa's UTC > offset was -11, at which point it changes to +11. > > For correct chronological sorting of events (which may occur in > multiple different timezones), or calculating deltas between > timestamps, life is a lot easier if you normalize to a common TZ, eg. > UTC, and only apply a local TZ offset when rendering the output to the > user. > Absolutely -- UTC is the only way to go in that situation, but it might be that the UTC timestamps are just a cache, generated from the local-time/TZ combination when needed. -- Regards, Ian Clelland -- 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: Timezone-aware storage of DateTime
On Thu, Jun 30, 2011 at 2:10 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 30 juin 2011, at 19:06, Daniel Swarbrick wrote: > > > On Jun 30, 6:31 pm, Ian Clelland wrote: > > > >> As a counterexample, I have needed to store wall-clock time as well as > time > >> zones for future events, in scheduling applications. It is exactly > because > >> of the unpredictability of future DST changes (and, in very rare cases, > >> wholesale time zone changes) that a one-time UTC conversion simply does > not > >> work for timestamps in the future. > >> > >> When an event is scheduled for a specific time, on a specific date in > the > >> future, then users expect that the web service will react at the > appropriate > >> wall clock time. An unforseen change in daylight saving time legislation > >> should not have the effect of making the time in the database incorrect. > > > > That is a good example, which I agree with. Although it sounds like > > more of a case for storing the date and time as separate fields (which > > is already feasible), since Python dates and times on their own have > > no tzinfo struct... only the combined datetime does (whether or not it > > includes hours/mins/secs components). > > Strictly speaking, converting a naive datetime + a time zone to a "point in > time" (eg. UTC timestamp) isn't possible, because of DST: one hour doesn't > exist, and another one happens twice. By the same standards, arithmetic division isn't possible, because the quotient is undefined when the denominator is zero. :) Converting local time + time zone to UTC is absolutely possible, except for roughly one hour out of every 4000 or so, and those hours are probably chosen to be the least-likely to affect anyone working in that particular time zone. The fact that there can be non-existent wall-clock times, or ambiguous wall-clock times, is why we have exception handling (and why pytz raises exceptions in all the right circumstances). It's not a reason to throw one's hands up and claim "this isn't possible; computers can't deal with this". UTC is brilliant, almost a requirement, for doing any sort of sane calculations involving actual times. The fact remains, though, that users think in local time, events get scheduled in local time, and when a user's government steps in and declares "daylight savings time is going to begin a week early this year," the user's 9:00AM meeting still happens at 9:00AM, wall clock time, and not at the UTC 'point in time' that the web service computed two months ago when the meeting was first scheduled. > In my opinion, the primary goal of the DateTime field is to store a "point > in time" and it should do so unambiguously. Of course, we could store a > naive datetime plus a time zone plus a DST flag, but that's cumbersome, I'd > even say developer-hostile. > This would be exactly equivalent to storing a naive datetime and a UTC offset, which isn't much different than storing a UTC timestamp, except that, as you say, it's more cumbersome. The point, for scheduling applications, of storing a semantic time zone, is that you can't necessarily predict the UTC 'point in time' that an event needs to occur at a certain time in that time zone. Perhaps this does run contrary to the purpose of a DateTIme field; perhaps DateTime fields are only supposed to be used for events in the past :) My point, in bringing up the use case initially, was that different applications have different uses for time zones, and that simply declaring that timezone data was an irrelevant detail, able to be discarded on storage and relegated to a presentation-layer transformation at rendering time, represents a limited view of real-world problems. > > I think there's a consensus on the fact that the best representation for > DateTime fields is UTC. I'm willing to trust the pytz guys on this topic: > > The preferred way of dealing with times is to always work in UTC, > converting to localtime only when generating output to be read by humans. > > Thus, Django should always use UTC internally and on the connection with > the database, and convert to local time in the forms widgets and > localization functions. However, this is massively backwards incompatible in > all databases that store DateTime as naive objects in local time (all but > PostgreSQL). As a consequence, it won't be considered (or maybe in Django > 2.0 ?) > This isn't necessarily a backwards incompatibility. Django could deal with UTC internally, and an optional argument to the models.DateTimeField could provide a hint as to what time zone the data i
Race condition in get_or_create
I'm seeing errors which I believe are due to a race condition in django.db.models.query.get_or_create, on a fairly high traffic site. Our production servers are running Django 1.2.5, but I don't see any changes in the code in trunk that would affect this. (I'm totally willing to construct a test case against trunk, but I'm posting this here in case it's already a recognized bug, or an error on my part) If two requests make the same call to get_or_create(), at roughly the same time, with a database server in REPEATABLE_READ isolation level, then I believe that it's possible for the following sequence of events to occur: 1. Process 1 enters into a transaction as part of the default view middleware. 2. Process 1 calls QuerySet.get(**lookup), no result is returned. (DoesNotExist is raised) 3. Process 2 enters into a transaction as part of the default view middleware. 4. Process 2 calls QuerySet.get(**lookup), no result is returned. (DoesNotExist is raised) 5. Process 2 calls transaction.savepoint 6. Process 2 saves a new object 7. Process 2 commits and returns the object 8. Process 1 calls transaction.savepoint 9. Process 1 tries to save a new object; this locks before #7, above, and fails after #7, with an IntegrityError 10. Process 1 rolls back to the savepoint, *but does not leave the outer transaction* 11. Process 1 calls QuerySet.get(**lookup), again, *but because we're still in the outer transaction, this returns nothing* 12. Process 1 Raises an integrity error, rather than getting the new object. Process 1 fails, because it performed the initial read inside of a transaction, but before the save point. In fact, inside of the same transaction, I believe it is impossible for the initial self.get() and the self.get() in the exception handler to return different results. Some SQL-shell testing shows that it's possible for this to work, as long as we set the savepoint before the initial read. That way, when we catch an IntegrityError and roll back to the savepoint, the lock is released, and Process 1 can actually see the object committed by Process 2. I expect to open up a ticket for this, unless someone can tell me "you're doing it wrong", or point me to another ticket (I've scanned the trac database, but didn't see anything identical. 15507 touches this, but won't actually do anything to solve it.) -- Regards, Ian Clelland -- 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: Race condition in get_or_create
And, of course, immediately after posting this, I find http://code.djangoproject.com/ticket/13906, which seems to cover much of the same area. Ian On Fri, Sep 2, 2011 at 11:04 AM, Ian Clelland wrote: > I'm seeing errors which I believe are due to a race condition in > django.db.models.query.get_or_create, on a fairly high traffic site. Our > production servers are running Django 1.2.5, but I don't see any changes in > the code in trunk that would affect this. (I'm totally willing to construct > a test case against trunk, but I'm posting this here in case it's already a > recognized bug, or an error on my part) > > If two requests make the same call to get_or_create(), at roughly the same > time, with a database server in REPEATABLE_READ isolation level, then I > believe that it's possible for the following sequence of events to occur: > > 1. Process 1 enters into a transaction as part of the default view > middleware. > 2. Process 1 calls QuerySet.get(**lookup), no result is returned. > (DoesNotExist is raised) > > 3. Process 2 enters into a transaction as part of the default view > middleware. > 4. Process 2 calls QuerySet.get(**lookup), no result is > returned. (DoesNotExist is raised) > 5. Process 2 calls transaction.savepoint > 6. Process 2 saves a new object > 7. Process 2 commits and returns the object > > 8. Process 1 calls transaction.savepoint > 9. Process 1 tries to save a new object; this locks before #7, above, and > fails after #7, with an IntegrityError > 10. Process 1 rolls back to the savepoint, *but does not leave the outer > transaction* > 11. Process 1 calls QuerySet.get(**lookup), again, *but because we're still > in the outer transaction, this returns nothing* > 12. Process 1 Raises an integrity error, rather than getting the new > object. > > Process 1 fails, because it performed the initial read inside of a > transaction, but before the save point. In fact, inside of the same > transaction, I believe it is impossible for the initial self.get() and the > self.get() in the exception handler to return different results. > > Some SQL-shell testing shows that it's possible for this to work, as long > as we set the savepoint before the initial read. That way, when we catch an > IntegrityError and roll back to the savepoint, the lock is released, and > Process 1 can actually see the object committed by Process 2. > > I expect to open up a ticket for this, unless someone can tell me "you're > doing it wrong", or point me to another ticket (I've scanned the trac > database, but didn't see anything identical. 15507 touches this, but won't > actually do anything to solve it.) > > -- > Regards, > Ian Clelland > > -- Regards, Ian Clelland -- 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: Race condition in get_or_create
On Fri, Sep 2, 2011 at 11:22 AM, Jeremy Dunck wrote: > On Fri, Sep 2, 2011 at 11:04 AM, Ian Clelland wrote: > > I'm seeing errors which I believe are due to a race condition in > > django.db.models.query.get_or_create, on a fairly high traffic site. Our > > production servers are running Django 1.2.5, but I don't see any changes > in > > the code in trunk that would affect this. (I'm totally willing to > construct > > a test case against trunk, but I'm posting this here in case it's already > a > > recognized bug, or an error on my part) > > If two requests make the same call to get_or_create(), at roughly the > same > > time, with a database server in REPEATABLE_READ isolation level, then I > > believe that it's possible for the following sequence of events to occur: > > I suspect you're using MySQL. Am I right? We just switched a mysql > site from repeatable read (the default) to read committed (postgres's > default, hence a better-tested path in django) for this very reason. > We are. 5.0.51a, I believe. READ COMMITTED would definitely solve this -- that seems to be the main point behind #13906, but there seems to be some resistance there. Have you encountered any other issues from making that switch? Regards, Ian Clelland -- 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: Date parsing in DateField
On Tue, Jun 16, 2009 at 1:52 AM, Michael Anckaert wrote: > > Currently the code is messy to say the least, currently supported > DATE_FORMAT: > %d-%m-%Y 16-06-2009 > %Y-%m-%d 2009-06-16 > And all variants where there are one or two day/month digits and/or the - > delimiter is a / > > I intend to make it compatible with all possible DATE_FORMAT options. > With Python 2.5, the code for this should be as simple as: def parse_date(value): try: return datetime.datetime.strptime(value, settings.DATE_FORMAT) except ValueError: return False If we can hold off until that is a dependency of Django, then the code will be quite pleasant to implement. Before then, it will likely end up as an ugly hack, probably involving building and compiliing regexes at run-time to match whatever is in DATE_FORMAT. -- Regards, Ian Clelland --~--~-~--~~~---~--~~ 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: Date parsing in DateField
> > If we can hold off until that is a dependency of Django, then the code will > be quite pleasant to implement. Before then, it will likely end up as an > ugly hack, probably involving building and compiliing regexes at run-time to > match whatever is in DATE_FORMAT. > Never mind that; in 2.3, the code is almost as simple -- and forwards compatible, too: import datetime import time def parse_date(value): try: return datetime.date(*time.strptime(value,settings.DATE_FORMAT)[:3]) except ValueError: return False It is probably worth discussing, though, whether the output and input date formats should always be the same, or if there is value in letting them differ (especially if someone has set DATE_FORMAT to something like '%b %d, %Y AD'). There may even be output formats that are not usable as input formats at all. Perhaps a DATE_INPUT_FORMAT setting, which defaults if unset to DATE_FORMAT, would be more appropriate. -- Regards, Ian Clelland --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
