Hi Martin, Just responding to the pertinent bits. I stand corrected on all the rest.
On Mon, 2008-03-24 at 11:10 +0100, Martin v. Löwis wrote: > > Some of the things you've identified as "Django should..." are a little > > problematic since one of the current requirements (at least for 1.0) is > > "Django should work out of the box with Python 2.3". Some of your > > proposed changes don't even work with Python 2.5, so we need to add a > > few more conditionals. > > I think you misunderstood. In these cases, I already changed Django to > do what it should do in the patch. E.g. with the patch, it already > uses io.BytesIO > in 3k, but continues to use cStringIO.StringIO in earlier versions. My apologies. I misread the patch. You're correct. [...] > Ok. Out of curiosity: What was the rationale for clearing Meta.__dict__ when > iterating over it? That's code from the pre-open-source days (so before my involvement), but I presume because it presented an easy way to check that all the parameters were used by the end of processing. It happened to work for whomever wrote that code. I've had to change it in the queryset-refactor branch because Meta can be subclassed, so I rapidly hit all sorts of problems there. This is one of many things in Django that are there because "it was fit for purpose when originally written years ago and has worked up until now." Incremental improvements and all that. :-) > > The AdminLogNode sending strings as slices bit me in queryset-refactor, > > too. I was a bit annoyed that Python allowed it because then I had to > > work around it. I'm strongly tempted to fix that (i.e. fix AdminLogNode > > to not be so slack) at a some point, but it's low-priority at the > > moment, since it breaks indeterminate amounts of code, so I haven't had > > the energy to work out the impact and/or mitigation. > > > > It's kind of cool, though: in Python 2.x, you can write a class that > > accepts fruit['apple':'banana'] and have it do something. Useful for > > symbolic enumerated types, I guess. > > Sure - the slice object is designed to hold arbitrary objects (and continues > to in 3.x); however, isn't this broken already in 2.x, and just not causing > an exception? IIUC, when limit is, say, '10', render will do > > (k.start is None or k.start >= 0) and (k.stop is None or k.stop >= 0) > > which happens to give True, but is actually incorrect. The culprit seems > to be connection.ops.limit_offset_sql, which accepts '10' as a limit; > _QuerySet seems to pass limit through as-is (except for the bogus > check above). Indeed. It's fixed in the queryset-refactor branch (which is a big rewrite of query.py's functionality), where we convert the arguments to integers before trying to use them as things that should have integer properties. > > I'm not going to make a call here; I'll leave that up to Jacob and > > Adrian, but I would hope our plan isn't to leave Python 2.5 (and maybe > > even 2.4) behind too quickly. > > Again, with the patch, that would not at all be necessary. Django could > continue to support any 2.x versions it pleases to. I think I misunderstood some of the reasons you were patching things (e.g. working around the bare except issue and things like that). Thanks for straightening me out. Cheers, Malcolm -- Experience is something you don't get until just after you need it. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
