Re: Localizing digits
I'm using http://babel.edgewall.org/ exactly for that purpose. Works extremely well. There are even some Django-specific extensions at http://babel.edgewall.org/wiki/BabelDjango (I don't use them though). On Aug 18, 4:48 pm, Joost Cassee <[EMAIL PROTECTED]> wrote: > Hi all, > > A Farsi-localized Django site I'm working on will need Farsi digits, > so I'm looking for a solution for replacing digits with their > localized counterparts. --~--~-~--~~~---~--~~ 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: autoreload does not reload updated modules for which import is failed
Hi devs, Happily there's ihooks.py that does 99% of work (and a bit more). Please see ticket and applied patch: http://code.djangoproject.com/ticket/8413 Working for me on windows and linux. Also one can use the patch to track wrong imports, and it might be useful to add warn() to tell people they are doing wrong thing and that might have unpleasant consequences for them: # It's recommended to fix django to never reach this place # and remove this except case, see http://bugs.python.org/issue2090 # and related django bugs: #6587 and #6579 # XXX: Turn it on to catch empty-name module imports. # print 'Importing empty module with __import__:', m.__name__ I'm not sure if the patch can be in 1.0: some more testing required, and problem is not very important. But, well, it can be mentioned in release notes :) On Mon, Aug 18, 2008 at 6:28 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > Not only that, but the Python import system is a maze of twisty little > passages, all alike. Overloading __import__ isn't as straightforward as > it might casually appear. -- 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: autoreload does not reload updated modules for which import is failed
On Aug 19, 8:32 pm, "Yuri Baburov" <[EMAIL PROTECTED]> wrote: > Hi devs, > > Happily there's ihooks.py that does 99% of work (and a bit more). > > Please see ticket and applied patch:http://code.djangoproject.com/ticket/8413 > Working for me on windows and linux. Hmmm, I thought one had to be careful using ihooks going forward. I thought: http://www.python.org/dev/peps/pep-0302/ defined proper way of doing things now. The PEP says: Forward Compatibility Existing __import__ hooks will not invoke new-style hooks by magic, unless they call the original __import__ function as a fallback. For example, ihooks.py, iu.py and imputil.py are in this sense not forward compatible with this PEP. I haven't got source code for Python to look at at moment to work it out. Graham > Also one can use the patch to track wrong imports, and it might be > useful to add warn() to tell people they are doing wrong thing and > that might have unpleasant consequences for them: > # It's recommended to fix django to never reach this place > # and remove this except case, seehttp://bugs.python.org/issue2090 > # and related django bugs: #6587 and #6579 > # XXX: Turn it on to catch empty-name module imports. > # print 'Importing empty module with __import__:', m.__name__ > > I'm not sure if the patch can be in 1.0: some more testing required, > and problem is not very important. > But, well, it can be mentioned in release notes :) > > On Mon, Aug 18, 2008 at 6:28 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > > Not only that, but the Python import system is a maze of twisty little > > passages, all alike. Overloading __import__ isn't as straightforward as > > it might casually appear. > > -- > 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: autoreload does not reload updated modules for which import is failed
On Tue, Aug 19, 2008 at 5:55 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > On Aug 19, 8:32 pm, "Yuri Baburov" <[EMAIL PROTECTED]> wrote: >> Hi devs, >> >> Happily there's ihooks.py that does 99% of work (and a bit more). >> >> Please see ticket and applied patch:http://code.djangoproject.com/ticket/8413 >> Working for me on windows and linux. > > Hmmm, I thought one had to be careful using ihooks going forward. I > thought: > > http://www.python.org/dev/peps/pep-0302/ > > defined proper way of doing things now. The PEP says: > > Forward Compatibility >Existing __import__ hooks will not invoke new-style hooks by > magic, >unless they call the original __import__ function as a fallback. >For example, ihooks.py, iu.py and imputil.py are in this sense not >forward compatible with this PEP. > > I haven't got source code for Python to look at at moment to work it > out. Well, I have read this PEP carefully, but there was no any clean example of using it. Now I see I overlooked that there's test/test_importhooks.py in python distribution. Ok, I will change my code to using PEP 302 hooks instead. It's not much work, and the code will look almost the same. -- 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: Multiple weblogs or catecorized news
On Aug 19, 1:39 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > (And you know, I still think we'd be better off with > "django-YES-THIS-ONE" and "django-NO-THE-OTHER-ONE". Or perhaps a tad > more seriously, something like "django-community" and "django-core" — > otherwise we'll be fighting this battle forever.) django-internals sounds good to me, though I've used up all of my capital already as far as renaming things is concerned ;) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Renaming of mailing lists to avoid user confusion
On Wed, Aug 20, 2008 at 12:37 AM, Simon Willison <[EMAIL PROTECTED]>wrote: > > On Aug 19, 1:39 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > > (And you know, I still think we'd be better off with > > "django-YES-THIS-ONE" and "django-NO-THE-OTHER-ONE". Or perhaps a tad > > more seriously, something like "django-community" and "django-core" — > > otherwise we'll be fighting this battle forever.) > > django-internals sounds good to me, though I've used up all of my > capital already as far as renaming things is concerned ;) > > I'm definately +1 on the idea. Also moving this to a seperate thread to raise awareness. --~--~-~--~~~---~--~~ 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: Renaming of mailing lists to avoid user confusion
On Tue, Aug 19, 2008 at 8:10 AM, Mike Scott <[EMAIL PROTECTED]> wrote: > I'm definately +1 on the idea. Also moving this to a seperate thread to > raise awareness. *Sigh* Please don't. Seriously - this comes up every couple of months, and it's just a bikeshed argument. We get about one off-topic post every ten days or so; hardly an onerous task to gently point folks to the right place. There's pretty clear explanations about what each list is for right there on the sign-up pages; we'll just trade folks who ignore that text for folks who ignore another bit. These are the names. Let's do something more interesting with our time. Jacob --~--~-~--~~~---~--~~ 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: Renaming of mailing lists to avoid user confusion
*sigh* Please take this thread to django-users. This list is for the internal development of django and this thread doesn't contribute to that. After all, the last half a dozen times such a thread was started (and I'm sure you carefully did your research before proposing it yet again), it wasn't changed. At some point living with the status quo is reasonable. What will happen is that this thread will generate far more traffic than the infrequent accidental mis-postings and clog up the recent postings in our inboxes, obscuring stuff that gets actual development work done. Thankyou for your consideration, 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: autoreload does not reload updated modules for which import is failed
On Tue, Aug 19, 2008 at 6:12 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > On Tue, Aug 19, 2008 at 5:55 PM, Graham Dumpleton > <[EMAIL PROTECTED]> wrote: >> On Aug 19, 8:32 pm, "Yuri Baburov" <[EMAIL PROTECTED]> wrote: >>> Hi devs, >>> >>> Happily there's ihooks.py that does 99% of work (and a bit more). >>> >>> Please see ticket and applied >>> patch:http://code.djangoproject.com/ticket/8413 >>> Working for me on windows and linux. >> >> Hmmm, I thought one had to be careful using ihooks going forward. I >> thought: >> >> http://www.python.org/dev/peps/pep-0302/ >> >> defined proper way of doing things now. The PEP says: >> >> Forward Compatibility >>Existing __import__ hooks will not invoke new-style hooks by >> magic, >>unless they call the original __import__ function as a fallback. >>For example, ihooks.py, iu.py and imputil.py are in this sense not >>forward compatible with this PEP. >> >> I haven't got source code for Python to look at at moment to work it >> out. > Well, I have read this PEP carefully, but there was no any clean > example of using it. > Now I see I overlooked that there's test/test_importhooks.py in python > distribution. > Ok, I will change my code to using PEP 302 hooks instead. It's not > much work, and the code will look almost the same. I updated path with PEP-302. Now it doesn't change __import__ behavior in any way, and there's no ihooks.py import anymore. Agree that it's post-1.0 (but it's nice feature anyway!). -- 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: Renaming of mailing lists to avoid user confusion
On Tue, Aug 19, 2008 at 8:16 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Please take this thread to django-users. This list is for the internal > development of django and this thread doesn't contribute to that. Done. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
initial data for inlineformset_factory
any reason, why it´s currently impossible to use "initial" with inlineformset_factory. is it planned to integreate this feature? thanks, patrick --~--~-~--~~~---~--~~ 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: initial data for inlineformset_factory
On Tue, Aug 19, 2008 at 12:10 PM, patrickk <[EMAIL PROTECTED]> wrote: > > any reason, why it´s currently impossible to use "initial" with > inlineformset_factory. is it planned to integreate this feature? I guess I am failing to see how this is useful? initial data in an inline model formset is based on the queryset such as it is a subclass of model formset. Could you provide a use case where it might be worth it to also provide initial data for an inline model formset? It would seem that a default value on a model field would be sufficient. Seems a bit overkill for the general case due to the unknown size of the queryset. -- Brian Rosner http://oebfare.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: initial data for inlineformset_factory
usecase: let´s say you have a "booking" (form) with a number of X "booking amounts" (formset). now the user could be able to save a pre-defined template for common bookings. these templates are saved as "template" and "template amounts". so, if the user selects a given template, the template-amounts should be the "initial date" for the booking amounts. maybe this is totally out of scope, I´m not sure. and maybe there´s another way to insert the template ... it just seemed very natural for me to use "initial" with an inline mode formset, till I figured out it ´s not possible. patrick. On Aug 19, 9:22 pm, "Brian Rosner" <[EMAIL PROTECTED]> wrote: > On Tue, Aug 19, 2008 at 12:10 PM, patrickk <[EMAIL PROTECTED]> wrote: > > > any reason, why it´s currently impossible to use "initial" with > > inlineformset_factory. is it planned to integreate this feature? > > I guess I am failing to see how this is useful? initial data in an > inline model formset is based on the queryset such as it is a subclass > of model formset. Could you provide a use case where it might be worth > it to also provide initial data for an inline model formset? It would > seem that a default value on a model field would be sufficient. Seems > a bit overkill for the general case due to the unknown size of the > queryset. > > -- > Brian Rosnerhttp://oebfare.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: initial data for inlineformset_factory
On Tue, Aug 19, 2008 at 12:22 PM, Brian Rosner <[EMAIL PROTECTED]> wrote: >Seems > a bit overkill for the general case due to the unknown size of the > queryset. It is possible to specify both a queryset and initial data with a ModelFormSet or InlineModelFormSet, and initial will override the queryset, but the queryset is still kept around. Looks like that could cause some problems in save_existing_objects(), especially if initial and queryset aren't the same size. -Justin --~--~-~--~~~---~--~~ 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: initial data for inlineformset_factory
Uh.. disregard that. My mistake. I read the code wrong and BaseInlineFormSet does not take **kwargs and pass them to BaseModelFormSet.__init__(), so no you can't specify 'initial'. Which is good. -Justin On Tue, Aug 19, 2008 at 12:54 PM, Justin Fagnani <[EMAIL PROTECTED]> wrote: > On Tue, Aug 19, 2008 at 12:22 PM, Brian Rosner <[EMAIL PROTECTED]> wrote: >>Seems >> a bit overkill for the general case due to the unknown size of the >> queryset. > > It is possible to specify both a queryset and initial data with a > ModelFormSet or InlineModelFormSet, and initial will override the > queryset, but the queryset is still kept around. Looks like that could > cause some problems in save_existing_objects(), especially if initial > and queryset aren't the same size. > > -Justin > --~--~-~--~~~---~--~~ 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: initial data for inlineformset_factory
now this question is probably better posted in django-users, but: is there any way to prepopulate an unbound formset using inlineformset_factory? thanks, patrick On Aug 19, 10:05 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote: > Uh.. disregard that. My mistake. I read the code wrong and > BaseInlineFormSet does not take **kwargs and pass them to > BaseModelFormSet.__init__(), so no you can't specify 'initial'. Which > is good. > > -Justin > > On Tue, Aug 19, 2008 at 12:54 PM, Justin Fagnani > > <[EMAIL PROTECTED]> wrote: > > On Tue, Aug 19, 2008 at 12:22 PM, Brian Rosner <[EMAIL PROTECTED]> wrote: > >>Seems > >> a bit overkill for the general case due to the unknown size of the > >> queryset. > > > It is possible to specify both a queryset and initial data with a > > ModelFormSet or InlineModelFormSet, and initial will override the > > queryset, but the queryset is still kept around. Looks like that could > > cause some problems in save_existing_objects(), especially if initial > > and queryset aren't the same size. > > > -Justin > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Is it time for a django-evangelists group?
Hi all, I've organized the testing sprint in Israel this Sunday and it was a great experience. The idea was to beta test 1.0 - getting new users through the tutorial and some 0.96 users to port their apps to 1.0. Overall we didn't find any serious bugs although porting is going to be painful... Many of the participants were non-django users with different views as to what Django really is. We had a couple of users who didn't know Python and came to learn it just for the power of Django. As I'm sure you've noticed, Django is definitely getting noticed. I could start a whole discussion as to what I learned about users out there and share some ideas on how to improve the tutorial so it will be easier for newcomers. But I know that django-developers is not the place for this. This group is very busy as it is, working on far more important things than minor improvements to the tutorial. I suggest an evangelist group so I'll have a place to share my experience and ideas, help other projects, get help for my projects and ensure work is not been duplicated. What's your vote? Benny. --~--~-~--~~~---~--~~ 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: Is it time for a django-evangelists group?
On Tue, Aug 19, 2008 at 4:16 PM, daonb <[EMAIL PROTECTED]> wrote: > I could start a whole discussion as to what I learned about users out > there and share some ideas on how to improve the tutorial so it will > be easier for newcomers. But I know that django-developers is not the > place for this. This group is very busy as it is, working on far more > important things than minor improvements to the tutorial. > I suggest an evangelist group so I'll have a place to share my > experience and ideas, help other projects, get help for my projects > and ensure work is not been duplicated. > > What's your vote? Personally, I'd prefer to keep such a discussion here -- it's as good a place as any for discussion of this nature, and I, for one, won't be joining any more django-* lists (too many to read already!) Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Should file storage implicitly close original uploaded files after saving?
Hi,
The `FileSystemStorage._save()` method seems to implicitly close the
uploaded file after it's been saved, preventing the following from
working:
storage.save('/images/image.gif', uploaded_image) # Store the original
thumbnail = Image.open(uploaded_image) # Doesn't work because
uploaded_image was closed or not reset.
Should that 'close-original-after-storing' behaviour be enforced
across all file storage systems, or should that be left to the
individual systems (like currently with `FileSystemStorage`) to
decide?
Instead, another possibility would be to leave it to the developer to
decide what she wants to do with the original uploaded file instance.
For example:
storage.save('/images/image.gif', uploaded_image) # Store the
original, and leave it open.
thumbnail = Image.open(uploaded_image)
# Manipulate thumbnail
storage.save('/images/thumbnail.gif', thumbnail) # Store thumbnail
uploaded_image.close()
thumbnail.close()
To be clear, here `uploaded_image` and `thumbnail` do not directly
refer to the stored versions (which might be somewhere on S3 or
wherever), but to the "temporary" versions that are either in memory
or in temporary files.
In my opinion, the above example would be more explicit and feel more
logical from the developer's point of view. See also #8222, which I'm
starting to question the validity, for a related question.
Thanks for your thoughts on this.
Regards,
Julien
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Call for testing: new docs
Hi folks -- The docs refactor work is pretty much done; now I need a bunch more eyes to look things over. There's still a bunch of TODOs (see below), but it's better than the current docs and maintaining branched docs is a major pain, so I plan to have this merged into trunk this week. The best way to help out right now is to grab the "docs-refactor" branch from my git repo at git://djangoproject.com/django (browse at http://code.djangoproject.com/git/?p=django;a=shortlog;h=refs/heads/docs-refactor). I've also put a built version of the docs online at http://docs.djangoproject.com/dev/. There are some problems with the version online right now; no need for bug reports since I'll be changing the online version to better fit into the django site over the next few days. To get started helping out, see ``internals/documentation.txt`` or http://docs.djangoproject.com/dev/internals/documentation.html. There's a TODO at the end of that file. The best way to send me code is by letting me know about your remote git repo. Or use git-format-patch and send me patches. I can't really spare time to help with git, but someone in #django-dev probably can if you need it. A big thanks to all those who've helped, and especially Scott Newman who merged a crapton of doc changes by hand into the new system. Jacob --~--~-~--~~~---~--~~ 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: You've broken Oracle
Thanks very much for the pointer, Ramiro. It was indeed changes to the "extra_select" QS param that caused Oracle problems, and I've taken a similar approach to yours in fixing it. Rather than flag "row_number()" as an extra_select parameter (and then try to clean up after it later), Oracle now just uses the default set_limits and clear_limits methods and does all extra query munging in its as_sql() method. And instead of doing an outer SELECT *, we SELECT specific columns (or aliases) by name and ignore our row_number() column, which is only used in the WHERE clause. This seems to fix most of the failures. I'll check it in soon when I'm sure it's not causing any new problems. On Aug 18, 2:20 pm, "Ramiro Morales" <[EMAIL PROTECTED]> wrote: > Matt, > > On Mon, Aug 18, 2008 at 4:04 PM, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > Here is Leo Soto's buildbot, so you can see what I'm talking about: > >http://certenium.ingenium.cl:8080/hudson/job/django-trunk/ > > > I'll do my best to fix some of these as time permits, but I'm hoping > > others will pull together to rectify this quickly. Thanks! > > Some of these failures might be related to the changes in the `extra_select` > (and `extra_select_params` that got deleted) Query class attributes introduced > in r8426 because, as you know, the Oracle backend (and the MS SQL Server > backends) uses `extra_select` to insert a synthetic placeholder needed to use > the ORDER_BY function to emulate LIMIT+OFFSET. > > FWIW, in my work on a MS SQL Server backed I circumvented the bulk of the > problem by accident (actually, because this is one of the things that allowed > me to get a whole bunch of the Django test suite to start passing on SQL > Server 2005 whose SQL dialect also has the ORDER_BY function) some time ago by > migrating away from using `extra_select` to using the `ordering_aliases` > attribute to handle the placeholder by appending to it: > > http://code.google.com/p/django-pyodbc/source/browse/branches/ramiro/... > > Later on during the lifetime of the query, the `execute_sql()` Query method > will take care of ignoring that alias. > > This also allowed me to do away with the `set_limits()` and `clear_limit()` > custom Query class methods. > > I don't know if this is also possible for the Oracle backend, hopefully it is. > > HTH, > > -- > Ramiro Morales --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Help needed: Django 1.0 release notes and porting guide
Hi folks -- With Django 1.0 fast approaching, we need to get a few longish documents written before 1.0: a set of release notes, and a detailed porting guide covering all the changes up to 1.0. Typically James or one of the committers writes these, but we're all crazy swamped, so we need some help getting these started. If someone can help use get started, James or I can proofread and finish em. I know we've got quite a few authors on here... anyone interested? Some more details. The two documents will need to cover similar territory, but for different audiences. The release notes format is pretty well-defined; look at the existing release notes and go from there. They'll need to cover everything new/changed between 0.96 and 1.0 -- a big list, yes. The porting guide needs to basically cover everything in BackwardsIncompatibleChanges, with before/after code samples for each item and detailed upgrade info. The idea should be that someone can start with an 0.96 site and read through the checklist in order, making changes, and finish with a 1.0 site. So... who's interested? Jacob PS: If anyone's going to be at the Portland sprint this weekend, I'll be there and we can work on this in person. --~--~-~--~~~---~--~~ 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: Proposed change to permissions list in Model._meta
On Sat, Aug 16, 2008 at 12:01 PM, Mike Scott <[EMAIL PROTECTED]> wrote: > I'm -1. the permissions stuff is part of the auth app. It should dilute the > models stuff. I'm sure theres a way using the generic relationship stuff to > do a reverse relationship variable on whatever models you wish. But adding > this to _meta is IMO not the way to go. To be fair, lots of things are added into _meta as part of the class construction phase. Meta.permissions exists as an extension point for custom permissions, but models have these odd _meta.get_add_permission() methods hanging off of them. It seems to me that it'd be useful to have one place where all permissions existed. Right now, the stock permissions are hard-coded in several places, most notably in auth._get_all_permissions and Options.get_*_permissions. I understand this is a backwards-incompatible change, but the _meta.permissions as-is seems odd. Not the end of the world either way; we were just hoping not to make another copy (or reach from db.models into contrib.auth) to fix a bug (specifically #8060). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
recent MultiValueDict.iteritems change (changeset 8399)
I've been trying to stay up to date when testing locally and just noticed 8399 seems to be the source of a break in my code where MultiValueDict's iteritems was used. I see that this relates to http://code.djangoproject.com/ticket/7331 and I understand a decision had to be made. iteritems used to return lists for the items but was changed to match items, which only returns the last value for each key It seems that changing my code to use lists will give almost the same result, but would it be possible to get an "iterlists" method to replace the iteritems which was changed? This would be a trivial patch and I'd be happy to open a ticket and submit it, but figured I'd bring it up here as I'd imagine a design decision is needed on this. Also because of this should 8399, trivial as it is, go up on BackwardsIncompatibleChanges? --~--~-~--~~~---~--~~ 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: Help needed: Django 1.0 release notes and porting guide
I'll take the porting guide - ticket #8438. Although I'm not going to be in Portland, I'll do my best to have a draft ready by the weekend. --~--~-~--~~~---~--~~ 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: Call for testing: new docs
Jacob Kaplan-Moss wrote: > I've also put a built version of the docs online at > http://docs.djangoproject.com/dev/. There are some problems with the > version online right now; no need for bug reports since I'll be > changing the online version to better fit into the django site over > the next few days. Hi, Jacob! Does "no need for bug reports" apply only to presentation or to content as well? I'm asking because I've found an old-style `class Admin` your request declaration in an example in "Django at a glance" and I'm not sure if such bugs are known. --~--~-~--~~~---~--~~ 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: BaseModelFormSet and ModelForm.instance
I attached a patch to #8160 that fixes this issue (and probably #8071).
I'm not sure what parts of BaseModelFormSet are considered official
API. In the patch ModelForm.save() is now called by
ModelFormSet.save(), and I think the methods save_new, save_existing,
save_existing_objects, and save_new_objects are no longer needed. I
don't think get_queryset is needed either.
I know it's a rough patch, so any advice on how to improve it, or what
tests to add?
-Justin
ps. The *_factory methods seem odd to me. I wonder why metaclasses
weren't used here, but I understand that it's to close to 1.0 change
anything.
On Sun, Aug 17, 2008 at 7:57 PM, Justin Fagnani
<[EMAIL PROTECTED]> wrote:
> I just noticed that BaseModelFormSet takes a queryset and populates
> its forms initial data from the queryset, but doesn't set its forms
> instance attributes. Was this does by design?
>
> If not, it seem like the bottleneck is that BaseModelFormSet is
> completely relying on BaseFormSet to construct the forms, which
> obviously doesn't know about ModelForms and instances, but if
> BaseModelFormSet overrides _construct_form() is can set the instance.
> I worked around it by subclassing BaseModelFormSet:
>
> class InstanceFormSet(BaseModelFormSet):
>def _construct_form(self, i, **kwargs):
>if i < self._initial_form_count:
>defaults = {'instance': self.queryset[i]}
>else:
>defaults = {}
>defaults.update(kwargs)
>return super(BaseModelFormSet, self)._construct_form(i, **defaults)
>
> but this is how I would have expected BaseModelFormSet to behave.
> Should I open a ticket?
>
> -Justin
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
