Re: DB API - the limiting syntax, is it magic?
On 12/3/07, Mike Scott <[EMAIL PROTECTED]> wrote: > James, I'm think what I'm getting at more is not the fact that its > "magical", maybe that is the wrong choice of word. But my opinion is more of > the fact that it doesn't conform to the rest of the django database > commands. I suppose it depends on what you mean by "conforms"; if we wanted to run with that, I'd ask why you can iterate directly over a QuerySet in a for loop instead of doing something like, say queryset = MyModel.objects.all() for obj in queryset.iterate(): print obj After all, iteration is implemented using a special Python feature just the same as slicing, and it's not necessarily obvious that a QuerySet is something you ought to be able to iterate over without calling a special method. > I do think you put it aptly in asking do we want to be more SQL-style or > Python-style. Ultimately it boils down to people understanding the framework > better, and keeping it as is may infact do that. I think it is something > that needs to be considered quite carefully. Promoting slicing as the > recommended way, but still allowing a limit() function in there to conform > with the rest of the db api. Conformity, to a set standard (which in this > case doesn't seem to exist - which is another reason I am +1 on the DEP > idea), is better than doing it just cause you can. I'm very much against maintaining two separate ways to do the same thing. And I'm very strongly in favor of using the "Pythonic" solution as opposed to the "SQL" solution. > What the issue was (and the reason I bought this up) was that it was > understood that the python functionality was executed after the method was, > and therefor there was an understanding that it wouldn't make any > difference: That's the point, though, where it's important to know how Python's slicing syntax is applied to custom classes, and to go look to see how the slicing is implemented. We could do a better job of documenting exactly what slicing does (since it translates into LIMIT/OFFSET in the DB query), but that still doesn't strike me as an argument for killing off what is, essentially, the standard Python syntax for this sort of operation. > Its something that has been solved by marking with a comment, however I'm > firmly a fence sitter at this point, so I'm ready to be swung either way. > But I don't think your comments so far have done so. After I wrote my second reply to Adrian, I decided to really go all-out and just write a blog entry about this; my main beef is with calling things "magic" when really they're just standard Python features, but maybe it'll help shed some light on the larger discussion: http://www.b-list.org/weblog/2007/dec/03/magic/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Wrong length of database columns 'name', 'codename' for 'auth_permission' table.
Thank you. On 3 дек, 11:37, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > On 03-Dec-07, at 10:17 AM, Ivan Markeyev wrote: > > > Have no idea, how to post ticket on djangoproject.com. Server return > > to me "500 Internal Server Error (Submission rejected as potential > > spam)". > > add your name and email address in the 'preferences' page of the > wiki, and you will be allowed in > > -- > > regards > kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/web/ > Foss Conference for the common man:http://registration.fossconf.in/web/ --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: DB API - the limiting syntax, is it magic?
James, I'm think what I'm getting at more is not the fact that its "magical", maybe that is the wrong choice of word. But my opinion is more of the fact that it doesn't conform to the rest of the django database commands. I do think you put it aptly in asking do we want to be more SQL-style or Python-style. Ultimately it boils down to people understanding the framework better, and keeping it as is may infact do that. I think it is something that needs to be considered quite carefully. Promoting slicing as the recommended way, but still allowing a limit() function in there to conform with the rest of the db api. Conformity, to a set standard (which in this case doesn't seem to exist - which is another reason I am +1 on the DEP idea), is better than doing it just cause you can. What the issue was (and the reason I bought this up) was that it was understood that the python functionality was executed after the method was, and therefor there was an understanding that it wouldn't make any difference: Models.objects.filter(date__gt=date_start)[:1] However, it did and it would have been clearer as: Model.objects.filter(date__gt=date_start).limit(1) Its something that has been solved by marking with a comment, however I'm firmly a fence sitter at this point, so I'm ready to be swung either way. But I don't think your comments so far have done so. Mike. On Dec 3, 2007 7:13 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > On 12/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Frankly, I have found the slicing syntax hard to understand and > > error-prone myself. I think one of the reasons it seems magic is that > > it's one of the *rare* cases in which we use a Python > > "magic-syntax-ism" (like operator overloading, for instance) in the > > framework, plus the fact that, what, *every* other piece of QuerySet > > functionality uses a method. It seems bolted on. > > > > I'd be +1 on adding a distinct limit() method, and keeping the legacy > > list method for masochists who actually enjoy coding in that way. > > And.. it's late and I'm possibly not thinking clearly, but I feel like > fleshing out what I've already said, because this is something I have > a strong opinion on. > > Let's step back from the case at hand and consider something else so > it'll be a bit more objective to look at. That means another "magic" > Python method, so I'll pick the __str__()/__unicode__() combo we do on > model classes. > > To someone who's not familiar with Python, the fact that defining > these methods will cause a complex object to -- in certain > circumstances -- "magically" become a string is undoubtedly confusing. > But the solution to that isn't to stop using them, it's to help people > become familiar with the conventions of Python programming; if we > switched to, say, defining 'toUnicodeString()' and 'toByteString()' on > models, a lot more people would be able to immediately pick up Django > and grok what's going on, but we'd be going against the grain of > Python, which provides __unicode__() and __str__() for these purposes > already, and we'd be confusing people who are familiar with Python and > who expect that "convert Object X to a string" is going to call > __unicode__() or __str__(). > > I don't think there's anybody here who'd advocate adding explicit > string-generating methods on models just for the sake of letting > people avoid the need to understand how Python works; we'd be working > against the language in a painful way, and in the long run it'd hurt a > lot more than it helped. > > Getting back to the issue at hand, slicing a QuerySet is the same > situation: a lot of people would undoubtedly grok things more quickly > if there were explicit "limit()", "offset()", etc. methods on > QuerySet, but Python already provides a standard language feature for > objects which want to emulate a sequence and allow users to retrieve > only a portion of the sequence, and defining our own separate set of > methods for this would be working against the language in a big way, > and we'd be doing it, essentially, so that people don't have to learn > how Python works. Which is a disservice to everyone who uses Django: > > 1. Experienced Python programmers would wonder why the hell we're not > just using the features Python provides for this use case. > 2. Inexperienced Python programmers would just get bitten the first > time they tried to slice some other sequence type and be right back in > the same boat they were in originally. > > And, ultimately, referring to a standard language feature as "magic" > does a large disservice both to Python and to people who are trying to > learn Django and Python: the slicing syntax, and the way it's > implemented, is no more or less "magical" than, say, a Java class > which implements standard interfaces out of java.util or java.lang. > > So if it's possible to have a negative vote which involves aleph > numbers or other such suitably infinite quantities, that's how I'd >
Re: Wrong length of database columns 'name', 'codename' for 'auth_permission' table.
On 03-Dec-07, at 10:17 AM, Ivan Markeyev wrote: > Have no idea, how to post ticket on djangoproject.com. Server return > to me "500 Internal Server Error (Submission rejected as potential > spam)". add your name and email address in the 'preferences' page of the wiki, and you will be allowed in -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ Foss Conference for the common man: http://registration.fossconf.in/web/ --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: DB API - the limiting syntax, is it magic?
On 12/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Frankly, I have found the slicing syntax hard to understand and > error-prone myself. I think one of the reasons it seems magic is that > it's one of the *rare* cases in which we use a Python > "magic-syntax-ism" (like operator overloading, for instance) in the > framework, plus the fact that, what, *every* other piece of QuerySet > functionality uses a method. It seems bolted on. > > I'd be +1 on adding a distinct limit() method, and keeping the legacy > list method for masochists who actually enjoy coding in that way. And.. it's late and I'm possibly not thinking clearly, but I feel like fleshing out what I've already said, because this is something I have a strong opinion on. Let's step back from the case at hand and consider something else so it'll be a bit more objective to look at. That means another "magic" Python method, so I'll pick the __str__()/__unicode__() combo we do on model classes. To someone who's not familiar with Python, the fact that defining these methods will cause a complex object to -- in certain circumstances -- "magically" become a string is undoubtedly confusing. But the solution to that isn't to stop using them, it's to help people become familiar with the conventions of Python programming; if we switched to, say, defining 'toUnicodeString()' and 'toByteString()' on models, a lot more people would be able to immediately pick up Django and grok what's going on, but we'd be going against the grain of Python, which provides __unicode__() and __str__() for these purposes already, and we'd be confusing people who are familiar with Python and who expect that "convert Object X to a string" is going to call __unicode__() or __str__(). I don't think there's anybody here who'd advocate adding explicit string-generating methods on models just for the sake of letting people avoid the need to understand how Python works; we'd be working against the language in a painful way, and in the long run it'd hurt a lot more than it helped. Getting back to the issue at hand, slicing a QuerySet is the same situation: a lot of people would undoubtedly grok things more quickly if there were explicit "limit()", "offset()", etc. methods on QuerySet, but Python already provides a standard language feature for objects which want to emulate a sequence and allow users to retrieve only a portion of the sequence, and defining our own separate set of methods for this would be working against the language in a big way, and we'd be doing it, essentially, so that people don't have to learn how Python works. Which is a disservice to everyone who uses Django: 1. Experienced Python programmers would wonder why the hell we're not just using the features Python provides for this use case. 2. Inexperienced Python programmers would just get bitten the first time they tried to slice some other sequence type and be right back in the same boat they were in originally. And, ultimately, referring to a standard language feature as "magic" does a large disservice both to Python and to people who are trying to learn Django and Python: the slicing syntax, and the way it's implemented, is no more or less "magical" than, say, a Java class which implements standard interfaces out of java.util or java.lang. So if it's possible to have a negative vote which involves aleph numbers or other such suitably infinite quantities, that's how I'd vote on this change. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: DB API - the limiting syntax, is it magic?
On 12/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Frankly, I have found the slicing syntax hard to understand and > error-prone myself. I guess I'm curious as to what's difficult or error-prone about it; I've never run into a problem where slicing was the cuplrit, and it feels like a more intuitive and Pythonic syntax than the "limit" and "offset" arguments we used to have in the pre-magic-removal days. > I think one of the reasons it seems magic is that > it's one of the *rare* cases in which we use a Python > "magic-syntax-ism" (like operator overloading, for instance) in the > framework, plus the fact that, what, *every* other piece of QuerySet > functionality uses a method. It seems bolted on. In a way this feels like the same sort of debate as the one over whether to implement __nonzero__() as a way of checking for an empty QuerySet, or to use a dedicated exists() method; going one way is more "Pythonic", going the other way is more "SQL-ish". I'd prefer to stick to one way to do things, and probably it'd be a good idea to have a design discussion about which way Django will lean on these issues. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: DB API - the limiting syntax, is it magic?
On Dec 2, 2007 8:31 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-11-30 at 20:00 -0800, [EMAIL PROTECTED] wrote:
> > To clarify, code such as the following can be a little confusing:
> >
> > p = MyModel.objects.filter(foo__id = self.id).order_by('-timestamp')[:
> > 1]
> > if p:
> > return p[0]
> >
> > To a python developer who is unfamiliar with django's magic limiting
> > syntax, the slice there looks unnecessary.
> >
> > Writing objects.filter(...).order_by(...).limit(1) would be clearer
> > and significantly less error prone.
>
> No it wouldn't. It would be differently error-prone.
Frankly, I have found the slicing syntax hard to understand and
error-prone myself. I think one of the reasons it seems magic is that
it's one of the *rare* cases in which we use a Python
"magic-syntax-ism" (like operator overloading, for instance) in the
framework, plus the fact that, what, *every* other piece of QuerySet
functionality uses a method. It seems bolted on.
I'd be +1 on adding a distinct limit() method, and keeping the legacy
list method for masochists who actually enjoy coding in that way.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
On Sun, 2007-12-02 at 20:44 -0800, SmileyChris wrote: > I tried actually using lazy today for something and couldn't get it to > work. > It seems to me that the current implementation is basically broken. > > For example, I was trying to do lazy(my_function, list) > __proxy__.__init__ tries to setattr(self, k, [promise]), but that > won't actually work for any magic methods, because they need to be > class methods. > > After hacking around with it a bit and moving that code outside > __init__, I got it to work. > > Once it is working, it makes __repr__ work properly on lazy objects > too (which probably is the solution to that problem I was having with > some new tests returning 0x...>)! > > In fact, the only easy way to tell that it isn't actually that object > type is to test is_instance() > > Has anyone else actually tried using this method before? What method? Malcolm --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Wrong length of database columns 'name', 'codename' for 'auth_permission' table.
Have no idea, how to post ticket on djangoproject.com. Server return to me "500 Internal Server Error (Submission rejected as potential spam)". As i understand, 'name' and 'codename' columns for 'auth_permission' table generated automatically from object class name. 'name' are consist 'Can add+[class name]', 'codename' - ''add_+[class name]''. So, they should be the same length or 'name' should be larger then 'codename'. In postgresql they are varchar(50) - 'name' and varchar(100) - 'codename'. Sorry for my english. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
lazy (in utils.functional) is broken
I tried actually using lazy today for something and couldn't get it to work. It seems to me that the current implementation is basically broken. For example, I was trying to do lazy(my_function, list) __proxy__.__init__ tries to setattr(self, k, [promise]), but that won't actually work for any magic methods, because they need to be class methods. After hacking around with it a bit and moving that code outside __init__, I got it to work. Once it is working, it makes __repr__ work properly on lazy objects too (which probably is the solution to that problem I was having with some new tests returning )! In fact, the only easy way to tell that it isn't actually that object type is to test is_instance() Has anyone else actually tried using this method before? --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: AssertionError should not be wrapped in ImproperlyConfigured
On Sun, 2007-12-02 at 12:17 -0800, mezhaka wrote:
> I have an assertion statement in my urls.py. When it throws an
> AssertionError I do not get it. Instead I get the ImproperlyConfigured
> error like this: http://dpaste.com/26524/. I had to dig into the
> django code to understand what's happening. I have checked the svn for
> previous version of urlresolvers.py :
> $ svn diff -r 6584:5681 urlresolvers.py
>
> and it outputs the following:
> --- urlresolvers.py (revision 5681)
> +++ urlresolvers.py (revision 6584)
> @@ -249,8 +249,9 @@
> except AttributeError:
> try:
> self._urlconf_module = __import__(self.urlconf_name,
> {}, {}, [''])
> -except ValueError, e:
> -# Invalid urlconf_name, such as "foo.bar." (note
> trailing period)
> +except Exception, e:
> +# Either an invalid urlconf_name, such as "foo.bar.",
> or some
> +# kind of problem during the actual import.
> raise ImproperlyConfigured, "Error while importing
> URLconf %r: %s" % (self.urlconf_name, e)
> return self._urlconf_module
> urlconf_module = property(_get_urlconf_module)
>
> As from my point of view this is not correct -- the assertion is
> decorated and it is hard to get what's going on. I've svn updated to
> the previous version and now page behaves itself as I expect -- throws
> AssertionError with a line number in urls.py. Shouldn't the new
> version use VaueError as the previous version instead of the generic
> Exception? Should I file a change request, bug or send patch? What
> should I do to influence this behavior?
Let's slow down a bit here. There's no fundamental problem with
converting exceptions from one type to another. It's a not a bug per se
that we're changing the exception to something generically descriptive,
even if it doesn't quite meet your requirements.
We are making the error handling more robust for a reason: there are
lots of exceptions that can be raised that were hard for people to catch
and not really clear why they were occurring.
At the time, I committed that, I did wonder about capturing information
from the original exception. That's not unreasonable. Feel free to
create a patch that stores, say, the original exception type, it's
message and even the full traceback. But we do still want to raise a
single identifiable exception from that point, so we can't change it
back to just raising arbitrary stuff: it's too fragile for downstream
code. I realise where you're coming from here, but both alternatives
involve trade-offs and the current approach seems slightly better to me
when I think about it.
Regards,
Malcolm
> >
>
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
AssertionError should not be wrapped in ImproperlyConfigured
I have an assertion statement in my urls.py. When it throws an
AssertionError I do not get it. Instead I get the ImproperlyConfigured
error like this: http://dpaste.com/26524/. I had to dig into the
django code to understand what's happening. I have checked the svn for
previous version of urlresolvers.py :
$ svn diff -r 6584:5681 urlresolvers.py
and it outputs the following:
--- urlresolvers.py (revision 5681)
+++ urlresolvers.py (revision 6584)
@@ -249,8 +249,9 @@
except AttributeError:
try:
self._urlconf_module = __import__(self.urlconf_name,
{}, {}, [''])
-except ValueError, e:
-# Invalid urlconf_name, such as "foo.bar." (note
trailing period)
+except Exception, e:
+# Either an invalid urlconf_name, such as "foo.bar.",
or some
+# kind of problem during the actual import.
raise ImproperlyConfigured, "Error while importing
URLconf %r: %s" % (self.urlconf_name, e)
return self._urlconf_module
urlconf_module = property(_get_urlconf_module)
As from my point of view this is not correct -- the assertion is
decorated and it is hard to get what's going on. I've svn updated to
the previous version and now page behaves itself as I expect -- throws
AssertionError with a line number in urls.py. Shouldn't the new
version use VaueError as the previous version instead of the generic
Exception? Should I file a change request, bug or send patch? What
should I do to influence this behavior?
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Django 1.0 features -- the definitive list
Le 30 nov. 07 à 07:33, Adrian Holovaty a écrit : > > Let's get a definitive list of features we want in Django 1.0, and > let's release it. Just great. > > Without further ado, here's my list: > > * newforms-admin > * queryset-refactor > * django.newforms becomes django.forms > * Model-level validation > * Change django.templatetags not to use __path__ hacking > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance > * #5361 -- File storage refactoring > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff > > What am I forgetting? Maybe use request.DATA instead of POST as discussed in #5682? It's backward compatible and not a Big Stuff but can require a lot of changes if it becomes the right way to do®. David --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Django 1.0 features -- the definitive list
Simon Willison wrote: > I'd love to have a simpler alternative to the regexp method that is > more friendly for developers who haven't fully grokked regular > expression syntax yet. while i agree that simplifying things is always a good idea, i think that "developers who haven't fully grokked regular expression syntax yet" should learn them as soon as possible :-) gabor --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: MD5 crypt passwords
On Dec 2, 2007 8:04 PM, akaihola <[EMAIL PROTECTED]> wrote:
>
> Changeset 5073 [1] added support for Unix DES crypt passwords (see
> ticket 3316 [2] for discussion).
>
> Many systems use MD5-based crypt shadow passwords (see e.g. man 3
> crypt or its on-line version [3], under heading "GNU Extension"). This
> extension to the crypt library prefixes the encrypted password with
> "$1$$" instead of the 2-character salt.
>
> Django uses dollar signs ($) to delimit the algorithm, salt and
> encrypted password in the contrib.auth.models.User.password string.
> The choice of delimiter collides with glibc2 crypt. Apart from that
> MD5 crypt passwords should just work with the current code.
>
> I added a ticket [4] for this and submitted three different solutions
> as patches.
>
> I bumped into this issue when creating a Django-based web interface
> for a virtual host based e-mail service, and I needed to migrate a
> number of Linux user accounts along with their passwords to Django.
You don't really need to change django to do this.
I've solved this with User class hook:
def my_set_password(user, raw_password):
try:
this = EMailInfo.objects.get(user=user)
except EMailInfo.DoesNotExist:
this = EMailInfo(user=user)
this.username = user.username
import sha
this.password =
'{SHA}'+base64_encode(sha.new(raw_password).digest())[0].strip()
this.email= '[EMAIL PROTECTED]' % (user.username, VIRTUAL_DOMAIN)
user.emailaddress = this
def my_create_user(manager, username, email, password):
user = real_create_user(manager, username, email, password)
# user was saved after this
this = user.emailaddress
this.user = user
this.username = user.username
this.save()
return user
real_set_password = User.set_password
User.set_password = my_set_password
real_create_user = UserManager.create_user
UserManager.create_user = my_create_user
> [1] http://code.djangoproject.com/changeset/5073
> [2] http://code.djangoproject.com/ticket/3316
> [3] http://linux.die.net/man/3/crypt
> [4] http://code.djangoproject.com/ticket/6028
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: [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?hl=en
-~--~~~~--~~--~--~---
Re: Timezone aware datetimes and MySQL (ticket #5304)
On 12/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > I can see two fundamentally different approaches to this problem: > > 1. Deal with it at the ORM level, perhaps by getting MySQL to emulate > timezone aware datetimes by using two dB fields - a naive datetime, > and a varchar containing the timezone info. I'm doing something similar using a custom field, which saves the local and UTC times and the timezone info: http://www.djangosnippets.org/snippets/388/ I have not yet had any problems with it, and I like having bot the local time for display purposes, and the UTC time for sorting. Ludo --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Timezone aware datetimes and MySQL (ticket #5304)
On Sun, 2007-12-02 at 00:19 -0800, [EMAIL PROTECTED] wrote: > This ticket as been stuck in 'design decision needed' for a few months > now. I recently needed to solve this problem for a site I was > building, and came up with a workaround, so perhaps an account of my > approach can serve to get the 'design decision' ball rolling... > > In a nutshell, the problem is that MySQL can't handle timezone aware > datetimes. (Can any tell us if Oracle and SQLite do? I know PostgreSQL > does.) > > I can see two fundamentally different approaches to this problem: > > 1. Deal with it at the ORM level, perhaps by getting MySQL to emulate > timezone aware datetimes by using two dB fields - a naive datetime, > and a varchar containing the timezone info. > > 2. Convert all datetimes into UTC before they hit the dB, where they > are stored as naive datetimes. Storing the datetime along with its related timezone would be my preference (a shame that it would require two fields in MySQL -- 1985 is calling and would like their non-features back). Converting things to UTC loses information. 2007-12-01T12:00-0600 and 2007-12-02T05:00+1100 are not the same pieces of information, even though they represent the same moment in the UTC timezone. Timezones supply extra information that we shouldn't wilfully discard. Whether that's how the default datetime field behaves or whether we need extra fields to handle timezone-aware (i.e. non-broken :-)) datetimes is a secondary issue, but it seems to crop up all over the place. > > While option #1 feels more architecturally elegant to me (since it > solves the problem at its source), the more I thought about it I > decided it wasn't very feasible. It would mean that common operations > like selecting objects by date or sorting objects by time can no > longer be implemented with an SQL command - which to my mind is a > major problem. Creating model fields that are stored in multiple (two or more) database columns is an enhancement we want to implement (Jacob and I have talked about it a couple of times in different contexts this week, so it's not something way out of left field). That would make this sort of thing easier on some databases. I want to hear what other people think to see which way we should go, although if I was a betting man, I'd guess we end up going with "convert to UTC" for the default and make fully aware datetime fields as an extra (whether in core or external is a minor issue). Malcolm --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: queryset-refactor: StopIteration from execute_sql() where result_type != MULTI
On Sun, 2007-12-02 at 00:43 -0600, Jeremy Dunck wrote: > Does it make sense for execute_sql to raise StopIteration even when > it's called with a result_type other than MULTI? No, it doesn't. I noticed that the other day, too, and I'm going to change it. Malcolm --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: DB API - the limiting syntax, is it magic?
On Fri, 2007-11-30 at 20:00 -0800, [EMAIL PROTECTED] wrote:
> To clarify, code such as the following can be a little confusing:
>
> p = MyModel.objects.filter(foo__id = self.id).order_by('-timestamp')[:
> 1]
> if p:
> return p[0]
>
> To a python developer who is unfamiliar with django's magic limiting
> syntax, the slice there looks unnecessary.
>
> Writing objects.filter(...).order_by(...).limit(1) would be clearer
> and significantly less error prone.
No it wouldn't. It would be differently error-prone.
Using Pythonic syntax is nice and it's pretty rare that adding the slice
is really going to affect performance, since it only queries the
database if you haven't *already* run the database query (if you slice a
queryset that is already cached, it pulls the results out of the cache).
I'd be -1 on changing this.
Malcolm
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Timezone aware datetimes and MySQL (ticket #5304)
On 12/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > This ticket as been stuck in 'design decision needed' for a few months > now. I recently needed to solve this problem for a site I was > building, and came up with a workaround, so perhaps an account of my > approach can serve to get the 'design decision' ball rolling... > > In a nutshell, the problem is that MySQL can't handle timezone aware > datetimes. (Can any tell us if Oracle and SQLite do? I know PostgreSQL > does.) > > I can see two fundamentally different approaches to this problem: > > 1. Deal with it at the ORM level, perhaps by getting MySQL to emulate > timezone aware datetimes by using two dB fields - a naive datetime, > and a varchar containing the timezone info. > > 2. Convert all datetimes into UTC before they hit the dB, where they > are stored as naive datetimes. > > While option #1 feels more architecturally elegant to me (since it > solves the problem at its source), the more I thought about it I > decided it wasn't very feasible. It would mean that common operations > like selecting objects by date or sorting objects by time can no > longer be implemented with an SQL command - which to my mind is a > major problem. > > Option #2 feels a bit icky, but is much easier to implement, and it's > actually what I ended up using in the workaround I developed. > > I ended up writing a custom save method which converts timezone aware > datetimes to UTC then strips off the timezone data before storing > them. If the datetime is naive, it assumes it's in the timezone set in > settings.py, and then converts it to UTC. I call these datetimes 'sly' > datetimes - they're neither 'aware' nor completely 'naive', but they > know more than they appear to :-) > > With this approach, since I know that everything in the database is > UTC, I can do reliable ordering via SQL. There's still a bit of > jiggery-pokery needed when I have to do things like select items from > a particular day in a specific timezone (I have to figure out when the > day starts and ends in UTC), but it all works OK. I've also got > template filters that can convert to the viewer's timezone. > > Are there any opinions on this approach? > > If this general approach finds acceptance I could start turning my > workaround code into a more robust and generalised patch. Did you consider using MySQL's TIMESTAMP type ( http://dev.mysql.com/doc/refman/5.0/en/timestamp.html)? Seems it would let you push all of the work of conversion to UTC down into the db backend and the MySQL server. For saving values, the db backend could use the timezone information in the datetime value to set the time zone for the connection, then the MySQL server would convert to UTC for storage. (The per-connection timezone specification does require MySQL 4.1 or higher.) For retrieval, I'm not sure how you'd communicate the desired timezone to the db backend, but I'd think it could be done sensibly somehow with a little thought. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
MD5 crypt passwords
Changeset 5073 [1] added support for Unix DES crypt passwords (see ticket 3316 [2] for discussion). Many systems use MD5-based crypt shadow passwords (see e.g. man 3 crypt or its on-line version [3], under heading "GNU Extension"). This extension to the crypt library prefixes the encrypted password with "$1$$" instead of the 2-character salt. Django uses dollar signs ($) to delimit the algorithm, salt and encrypted password in the contrib.auth.models.User.password string. The choice of delimiter collides with glibc2 crypt. Apart from that MD5 crypt passwords should just work with the current code. I added a ticket [4] for this and submitted three different solutions as patches. I bumped into this issue when creating a Django-based web interface for a virtual host based e-mail service, and I needed to migrate a number of Linux user accounts along with their passwords to Django. [1] http://code.djangoproject.com/changeset/5073 [2] http://code.djangoproject.com/ticket/3316 [3] http://linux.die.net/man/3/crypt [4] http://code.djangoproject.com/ticket/6028 --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Timezone aware datetimes and MySQL (ticket #5304)
This ticket as been stuck in 'design decision needed' for a few months now. I recently needed to solve this problem for a site I was building, and came up with a workaround, so perhaps an account of my approach can serve to get the 'design decision' ball rolling... In a nutshell, the problem is that MySQL can't handle timezone aware datetimes. (Can any tell us if Oracle and SQLite do? I know PostgreSQL does.) I can see two fundamentally different approaches to this problem: 1. Deal with it at the ORM level, perhaps by getting MySQL to emulate timezone aware datetimes by using two dB fields - a naive datetime, and a varchar containing the timezone info. 2. Convert all datetimes into UTC before they hit the dB, where they are stored as naive datetimes. While option #1 feels more architecturally elegant to me (since it solves the problem at its source), the more I thought about it I decided it wasn't very feasible. It would mean that common operations like selecting objects by date or sorting objects by time can no longer be implemented with an SQL command - which to my mind is a major problem. Option #2 feels a bit icky, but is much easier to implement, and it's actually what I ended up using in the workaround I developed. I ended up writing a custom save method which converts timezone aware datetimes to UTC then strips off the timezone data before storing them. If the datetime is naive, it assumes it's in the timezone set in settings.py, and then converts it to UTC. I call these datetimes 'sly' datetimes - they're neither 'aware' nor completely 'naive', but they know more than they appear to :-) With this approach, since I know that everything in the database is UTC, I can do reliable ordering via SQL. There's still a bit of jiggery-pokery needed when I have to do things like select items from a particular day in a specific timezone (I have to figure out when the day starts and ends in UTC), but it all works OK. I've also got template filters that can convert to the viewer's timezone. Are there any opinions on this approach? If this general approach finds acceptance I could start turning my workaround code into a more robust and generalised patch. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
