type.__new__ vs. super(..., cls).__new__ in metaclasses
I just created a ticket (http://code.djangoproject.com/ticket/7617) to
allow a subclass of ModelFormMetaclass to inherit from a mixin, too.
One of the changes in my patch is to always use super(...,
cls).__new__ to chain up.
A grep over the django code base finds other metaclasses that directly
call type.__new__, though. For instance::
> class ModelBase(type):
> "Metaclass for all models"
>def __new__(cls, name, bases, attrs):
># If this isn't a subclass of Model, don't do anything special.
>try:
>parents = [b for b in bases if issubclass(b, Model)]
>except NameError:
># 'Model' isn't defined yet, meaning we're looking at Django's own
># Model class, defined below.
>parents = []
>if not parents:
>return super(ModelBase, cls).__new__(cls, name, bases, attrs)
>
># Create the class.
>module = attrs.pop('__module__')
>new_class = type.__new__(cls, name, bases, {'__module__': module})
I'd argue that the call of `type.__new__` should be replaced by a call
of `super(ModelBase, cls).__new__`. Otherwise any derived class using
multiple inheritance will be brittle at best.
Should I send in patches for django.db.models.ModelBase,
django.newforms.DeclarativeFieldsMetaclass, and
django.newforms.MediaDefiningClass?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
TO DOWN THE COOL TRISHA!! IMAGES!!!!!!!
TO DOWN THE COOL TRISHA!! IMAGES!!! TO DOWNLOAD THE KUSALAN AND IMAGES ON RASIYA, MUMTHAJ,STEYA,. TO THE COMEDY IN THE NEW FILM AND THE THEME OF THE STORIES AND TALIORS OF NEW FILM ON HINDI ALSO. SO WANT MORE!!! CLICK MY PROFILE!! ** http://trichysathya.blogspot.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 -~--~~~~--~~--~--~---
Naruto 407
Naruto 407 Naruto 407, One Piece 506, Bleach 329 Hot manga Download The hottest mangas and the latest chapters Manga news, Most popular mangas, Latest mangas, Latest chapters http://english1.isoshu.com/?recommid=1023 http://emanga1.isoshu.com/?recommid=1023 --~--~-~--~~~---~--~~ 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: Ticket #7591: Authenticate By Email Support
On Wednesday 02 July 2008 16:48:53 Paul Kenjora wrote: > I've been using Django for a while and recently started > contributing to the trunk. Previously I ran my own branch but > sooner or later that gets tiresome. So I created a ticket the > other day: > > http://code.djangoproject.com/ticket/7591 I replied on the ticket. Regards, Luke -- "Ineptitude: If you can't learn to do something well, learn to enjoy doing it poorly." (despair.com) Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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: type.__new__ vs. super(..., cls).__new__ in metaclasses
On Thu, 2008-07-03 at 02:06 -0700, Christian wrote: [...] > Should I send in patches for django.db.models.ModelBase, > django.newforms.DeclarativeFieldsMetaclass, and > django.newforms.MediaDefiningClass? Sounds like a reasonable idea. Make patches against the right branches, though, please. DeclarativeFieldsMetaclass and ModelBase should be patched on trunk (and will then be absorbed into newforms-admin when they next merge from trunk). MediaDefiningClass is a newforms-admin only class, so that patch is directly for them. Probably worth, therefore, having two tickets so that one is assigned to version "SVN" and the other is version "newforms-admin". Your analysis is correct, though. Calling super() is the right approach (the fact that we do it in one place and then three lines later screw it up is a little humiliating). 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: GIS: support for Points (markers) in Google Maps
Ticket with patch is open at http://code.djangoproject.com/ticket/7619 2008/7/2 Justin Bronn <[EMAIL PROTECTED]>: > > > I could clean this up as a patch to the GIS branch, but there seems to > > be some confusion as to whether such functionality should be in the > > core product. > > > > What is the right way forward here? > > > > File a ticket with your patch -- I'm +1 because it doesn't make sense > to support GPolygon and GPolyline but not GMarker (I haven't had time > to implement myself yet). > > For the record, I think the confusion is localized to the extent we > should have an OpenLayers API; it has so much functionality it may be > counter-productive to try and box users into an extremely small subset > of its features. > > -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: type.__new__ vs. super(..., cls).__new__ in metaclasses
Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2008-07-03 at 02:06 -0700, Christian wrote: > [...] > > Should I send in patches for django.db.models.ModelBase, > > django.newforms.DeclarativeFieldsMetaclass, and > > django.newforms.MediaDefiningClass? > > Sounds like a reasonable idea. Make patches against the right branches, > though, please. DeclarativeFieldsMetaclass and ModelBase should be > patched on trunk (and will then be absorbed into newforms-admin when > they next merge from trunk). MediaDefiningClass is a newforms-admin only > class, so that patch is directly for them. > > Probably worth, therefore, having two tickets so that one is assigned to > version "SVN" and the other is version "newforms-admin". http://code.djangoproject.com/ticket/7621 "SVN" http://code.djangoproject.com/ticket/7620 "newforms-admin" Looking at ModelBase, another question came up: > class ModelBase(type): > "Metaclass for all models" > def __new__(cls, name, bases, attrs): > # If this isn't a subclass of Model, don't do anything special. > try: > parents = [b for b in bases if issubclass(b, Model)] > except NameError: > # 'Model' isn't defined yet, meaning we're looking at Django's own > # Model class, defined below. > parents = [] > if not parents: > return super(ModelBase, cls).__new__ (cls, name, bases, attrs) > ... If I understand that correctly, the intent here is to `...` only for classes derived from `Model` but not for `Model` itself. I'd propose to write that check as parents = [b for b in bases if isinstance(b, ModelBase)] if parents: return super(ModelBase, cls).__new__ (cls, name, bases, attrs) ... Simpler, and it allows several independent `Model` classes using the same metaclass, if that's ever necessary. -- Christian Tanzerhttp://www.c-tanzer.at/ --~--~-~--~~~---~--~~ 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: type.__new__ vs. super(..., cls).__new__ in metaclasses
On Thu, 2008-07-03 at 14:56 +0200, Christian Tanzer wrote: [...] > I'd propose to write that check as > > parents = [b for b in bases if isinstance(b, ModelBase)] > if parents: > return super(ModelBase, cls).__new__ (cls, name, bases, attrs) > ... > > Simpler, and it allows several independent `Model` classes using the > same metaclass, if that's ever necessary. We need the parents list to be properly constructed later in the function, so the current code saves having to do a second iteration. It's nice that we can also use the "parents" list to do the early bailout. I don't see the significant use-case for the "several independent Model classes". We introduce something like that and we have to support it forever and somebody might actually use it, even though it's a bit insane. The only real reason it's worth having an separate metaclass like we do now (i.e. the reason it's not just a __new__ method on Model) is so that all this construction happens at import time, rather than instance creation time. Allowing the metaclass to be reused isn't a goal. So thanks, but no thanks. 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 -~--~~~~--~~--~--~---
Re: type.__new__ vs. super(..., cls).__new__ in metaclasses
Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2008-07-03 at 14:56 +0200, Christian Tanzer wrote: > [...] > > I'd propose to write that check as > > > > parents = [b for b in bases if isinstance(b, ModelBase)] > > if parents: > > return super(ModelBase, cls).__new__ (cls, name, bases, attrs) > > ... > > > > Simpler, and it allows several independent `Model` classes using the > > same metaclass, if that's ever necessary. > > We need the parents list to be properly constructed later in the > function, so the current code saves having to do a second iteration. > It's nice that we can also use the "parents" list to do the early > bailout. But my proposal doesn't change that: for all classes `c`, `issubclass(c, P)` is equivalent to `isinstance(c, P.__class__)`. You still have exactly the same result in `parents` as with the existing code -- the computation is just simpler and more general because no hardcoded class name is used anymore (and no NameError to deal with). Cheers, -- Christian Tanzerhttp://www.c-tanzer.at/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
tickets and use of the 1.0 milestones
I would like to remind those out there setting milestones on tickets to follow the following guidelines that Jacob put forth: * Must-have feature bugs go in the "1.0 alpha" milestone. These basically should be all nfa-blocker tickets. Bugs in the must-have features are not to be part of this milestone; they can be fixed after the alpha and should be put in the "1.0" milestone. * Any feature tickets related to the maybe list get put in the "1.0 beta" milestone. * Any remaining bugs go in the "1.0" milestone. See the roadmap for a list of the must-have and maybe features: http://code.djangoproject.com/wiki/VersionOneRoadmap I would like to stress the point that features not on the list are not to be put in any 1.0 milestone. For those working on tickets for features or enhancements that are not on the list, please understand that these are lower priority than vetted features and *all* bugs. If you really want to work on features not on the list, then keep track of them with some sort of "1.0dreaming" keyword instead of assigning them to a 1.0 milestone. With 1.0 looming, this isn't the time to see how many features we can try to pack in, but rather time to focus on squashing all bugs. I'm not here to tell you what you can and can't work on, but please keep the end goal in mind and help to focus efforts. This e-mail was sparked by a couple ticket updates I noticed, namely #1061 and #3011. Even if these sorts of features have a patch and are "Ready for checkin," that does not mean they get a 1.0 milestone. They still take core developer time to review and commit, time that also needs to be focused on higher priority tickets. Thanks, Gary --~--~-~--~~~---~--~~ 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: Community representation
random person: "i need help" magus: gives technical answer random person: does understand python magus: points to docs random person: you are rude On Jul 2, 11:38 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > On Wed, Jul 2, 2008 at 7:17 AM, Arien <[EMAIL PROTECTED]> wrote: > > > Can we get back to our regular program now and move personal problems > > to private communication, please? Thank you. > > Insofar as referencing particular individuals goes, I agree. I should > have raised any issues with particular community members in private, > and I ask that others do the same. > > That said — I do think it would be nice to outline just exactly what > is, and isn't, over the line for *anyone*; if we have a yardstick, we > can measure, as opposed to this vague "I know it when I see it" > pornography-like property of rudeness that everyone seems to disagree > on. I honestly don't know if this is the right mailing list for such > a discussion; it's certainly not "development of django", but a case > might be made that it's "development of the community". I *do* want > to have that discussion, however; I'd just like to know where to have > it before continuing. --~--~-~--~~~---~--~~ 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: tickets and use of the 1.0 milestones
> I would like to stress the point that features not on the list are not > to be put in any 1.0 milestone. For those working on tickets for > features or enhancements that are not on the list, please understand > that these are lower priority than vetted features and *all* bugs. If > you really want to work on features not on the list, then keep track of > them with some sort of "1.0dreaming" keyword instead of assigning them > to a 1.0 milestone. Agreed. > Even if these sorts of features have a patch and are "Ready for checkin," > that does not mean they get a 1.0 milestone. They still take core > developer time to review and commit, time that also needs to be > focused on higher priority tickets. Just out of curiosity, could we fix that bottleneck by appointing more developers to be core developers? Best, 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation
On Thu, Jul 3, 2008 at 9:26 AM, phillc <[EMAIL PROTECTED]> wrote: > > random person: "i need help" > magus: gives technical answer > random person: does understand python > magus: points to docs > random person: you are rude 1) Let's stop referring to specific people, mmkay? I made that mistake, had it pointed out that it was a mistake, and want to make good on not repeating that mistake. 2) The sort of interaction you outline is *not at all* what *I'm* talking about when I feel that someone is being rude. But again, this is the sort of thing I want to understand: what *do* people mean? I consider rudeness to encompass behaviors such as yelling, disparaging remarks, and using a condescending tone. Pretty simple, IMHO. Refusing to help someone who doesn't understand the first thing about Python is *not* being rude; it's merely recognizing that the other person is in the wrong place, and that your time could be better spent helping others. --~--~-~--~~~---~--~~ 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: tickets and use of the 1.0 milestones
On Thu, Jul 3, 2008 at 9:26 AM, Jannis Leidel <[EMAIL PROTECTED]> wrote: >> Even if these sorts of features have a patch and are "Ready for checkin," >> that does not mean they get a 1.0 milestone. They still take core >> developer time to review and commit, time that also needs to be >> focused on higher priority tickets. > > Just out of curiosity, could we fix that bottleneck by appointing more > developers to be core developers? I think that Just Happens once someone has been consistently making quality contributions over a long period. (Other than Whiskey-Media-era Jacob, I don't know how any of them do it; I think you need to take the super-Django-soldier serum first.) ^_^ --~--~-~--~~~---~--~~ 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 UploadedFile.chunks() or .chunk() ?
The docs say '.chunks()' , which makes more sense to me, but the code says '.chunk()' (2 * for implementation, 1 * used) It's not too late to fix the code, otherwise the docs need changing. Luke -- "Ineptitude: If you can't learn to do something well, learn to enjoy doing it poorly." (despair.com) Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Client Management / Client Screening system
We have a proprietary Client Screening and management software program created in Django and Python. We are an adult industry service company. Our designer has moved on and we're looking for a young mind to not only continue work but take it in a new direction. It's currently running on slicehost system which is Centos 5.1, system mySql 4, Our client Database is about 1100 clients. This project is open to College students who have a firm grasp of Python - Django or even ruby 1) We need a rebuild of this software 2) Time frame is As soon as possible The Process: Person fill's out the form: Once submitted the process is: a) A thank you form mail using some of the entered data is sent to the applicant. b) A database dup check on several fields is performed. c) data scrapes to several web sites, several of them require login. For now in the admin backend I'll settle for clicking on a link and having it propergate the necessary information to that sites web form and I'll take from there manually. Example of the kinds of sites would be: http://www.zabasearch.com/advanced.php http://www.intelius.com/background-check.html d) A client code of a specific schema is generated e) Once the truth of the information provided is found to be acceptable or not the correct form e-mail (approval or denial) is user selected and information is passed to the form mail by predefined fields and sent by the program. The ability to create different letters for various situations is important. f) User status in the system is then defined -- ie approved..declined etc. >From the backed of course we can do client look ups to verify their status We also want to be able to provide this screening service to other clients so the form has to be brandable to the look and feel of the host site. That's the basic system and we'll need modification from there down the road. Preference to those who live in the USA makes PHONE communication SO much cheaper. In you live in KY,OH,TN a major bonus. We're not married to Django if you think you can accomplish this in another platform make your case all we want is something that WORKS reliably. Budget $500.00 to 800.00 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
UploadedFile API changes (was: Is it UploadedFile.chunks() or .chunk() ?)
On Thu, Jul 3, 2008 at 11:08 AM, Luke Plant <[EMAIL PROTECTED]> wrote: > The docs say '.chunks()' , which makes more sense to me, but the code > says '.chunk()' (2 * for implementation, 1 * used) > > It's not too late to fix the code, otherwise the docs need changing. I just talked about this with Mike on IRC; I think chunk() is non-obvious and we're gonna change it to chunks(). Hopefully nobody's written so much code in the last week to be pissed. Also, we're going to change UploadedFile.file_name to UploadedFile.name to more closely match the built-in file API. Sorry about not thinking this through fully before committing, but it's gonna be better this way. 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: Client Management / Client Screening system
Hi Lee -- This is the wrong place for this kind of post; please take it to django-users -- or, better yet, http://djangogigs.com/ 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: tickets and use of the 1.0 milestones
On Thu, Jul 3, 2008 at 9:26 AM, Jannis Leidel <[EMAIL PROTECTED]> wrote: > Just out of curiosity, could we fix that bottleneck by appointing more > developers to be core developers? As with many things, the process of becoming a committer is documented in our contributing document (http://www.djangoproject.com/documentation/contributing/#commit-access): """ Full committers These are people who have a long history of contributions to Django's codebase, a solid track record of being polite and helpful on the mailing lists, and a proven desire to dedicate serious time to Django's development. The bar is very high for full commit access. It will only be granted by unanimous approval of all existing full committers, and the decision will err on the side of rejection. [...] To request commit access, please contact an existing committer privately. Public requests for commit access are potential flame-war starters, and will be ignored. """ That last bit -- emailing an existing committer asking for commit access -- is there deliberately. It helps with setting a high bar -- asking for commit access is *scary*, so the idea is that only those who deserve it will ask. We'll encourage the "right" people to ask when appropriate, of course, but if anyone reading here thinks they deserve commit access, email me. Hell, even if you just want to know what you'd personally need to do to get commit access, email me. 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: UploadedFile API changes (was: Is it UploadedFile.chunks() or .chunk() ?)
On Thu, Jul 3, 2008 at 12:22 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I just talked about this with Mike on IRC; I think chunk() is > non-obvious and we're gonna change it to chunks(). Hopefully nobody's > written so much code in the last week to be pissed. > > Also, we're going to change UploadedFile.file_name to > UploadedFile.name to more closely match the built-in file API. > > Sorry about not thinking this through fully before committing, but > it's gonna be better this way. Well, as long as the floor's open, I'd like to make sure file storage code is consistent. Currently, it uses filename instead of file_name or just name, and it also uses size instead of file_size. I assume I should go with name instead of filename, but should I use file_size, or should the upload stuff use size? On a related note, when merging #5361 with the new trunk, should the file-related code, such as moving files and whatnot, be moved into django.core.filestorage.filesystem? Also, should the code in django.core.filestorage be moved over to the new django.core.files package instead? So many bikesheds, so little time. -Gul --~--~-~--~~~---~--~~ 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: tickets and use of the 1.0 milestones
> As with many things, the process of becoming a committer is documented > in our contributing document > (http://www.djangoproject.com/documentation/contributing/#commit-access > ): > > [...] > > To request commit access, please contact an existing committer > privately. Public requests for commit access are potential flame-war > starters, and will be ignored. > """ Eeek, sorry, a flame-war wasn't my intent. I better read the manual before, next time :) > That last bit -- emailing an existing committer asking for commit > access -- is there deliberately. It helps with setting a high bar -- > asking for commit access is *scary*, so the idea is that only those > who deserve it will ask. We'll encourage the "right" people to ask > when appropriate, of course, but if anyone reading here thinks they > deserve commit access, email me. Hell, even if you just want to know > what you'd personally need to do to get commit access, email me. Good, let's hope someone is brave enough. Best, 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: UploadedFile API changes (was: Is it UploadedFile.chunks() or .chunk() ?)
On Thu, Jul 3, 2008 at 12:03 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > Well, as long as the floor's open, I'd like to make sure file storage > code is consistent. Currently, it uses filename instead of file_name > or just name, and it also uses size instead of file_size. I assume I > should go with name instead of filename, but should I use file_size, > or should the upload stuff use size? Yeah, let's be consistent and use "size" and "name" everywhere. In retrospect that beginning "file_" was redundant; my bad, sorry to have to change it! > On a related note, when merging #5361 with the new trunk, should the > file-related code, such as moving files and whatnot, be moved into > django.core.filestorage.filesystem? Also, should the code in > django.core.filestorage be moved over to the new django.core.files > package instead? Let's put everything file-related in django.core.files -- no need for both locations. We won't include support for any particular network-based file storage in django.core (that'd go in contrib, maybe) so there's no need to qualify the filesystem part. 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 -~--~~~~--~~--~--~---
you can like this where much hot models hot video hot pictures ********************************************** http://anushkahollywood.blogspot.com/
you can like this where much hot models hot video hot pictures ** http://anushkahollywood.blogspot.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 -~--~~~~--~~--~--~---
#7560: Delegate (most) type conversion to backends
Hi all!, I've posted a patch[1] with a small refactor to some Field's get_db_prep_* methods. Basically, for non-basic field types, the database-prepared values is not computed by the Fields anymore, but delegated to DatabaseOperations functions. As the current default logic was copied to the default methods implementations on DatabaseOperations, this should not break anything (I fully tested it a week ago, with the four official backends and indeed it didn't broke anything). This patch is part of my work of running Django on Jython, and in general helps anybody who maintains an external django database backend. I would appreciate thoughts on the general approach, and some guidance if I missed something. [1] http://code.djangoproject.com/ticket/7560 -- Leo Soto M. http://blog.leosoto.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: Ordered ManyToMany
Thanks for your answer all! I really appreciate it! In the meantime, I have thought of the following ugly but simple solution. A comma (or whatever character) seperated list of primary keys in a CharField can hold the values in the order needed. Now the only thing I need is a widget that generates this list. Somewhat similar to: http://www.nuff-respec.com/external/javascriptgui.html (Except that he above demo does not select, it just orders) I would then need to write my own accessor functions for the related model objects. Any comment on that? Oliver On Jun 27, 11:42 am, Jonas Pfeil <[EMAIL PROTECTED]> wrote: > > I think Django is really wonderful, but I am puzzled that it contains > > so few "ordering features". We often have the case that a user wants > > to select from a list of possible choices (normal select) *plus* wants > > to specify an ordering. Typically in applications this is done using > > up/down arrows next to the box displaying the selected values. > > This is indeed a very common use case and has been requested many > times (e.g. here [1]). The good news is that Django has scheduled the > 1.0 release early September. This means it’s very probably not going > to be addressed right now. But once 1.0 is out the door the ancient > ticket #13 [2] will be (hopefully) revisited :) It has a mock-up of > the admin interface proposed [3] but no patch yet. > > On the JS-lib/flamewar issue. If I recall correctly the admin is not > considered to belong to the core of Django (even though it’s _the_ > killer feature for many). It's merely an application. As such it has > to use the techniques necessary. Unless someone volunteers to rewrite > a JS for Django from scratch this includes using a lib. I don't think > that's that much of an issue though. Let's just come up witch a > sensible list and have people with commit privileges vote on it :) > > But post 1.0 ;) > > Cheers, > > Jonas > > [1]http://code.djangoproject.com/ticket/6118 > [2]http://code.djangoproject.com/ticket/13 > [3]http://media.wilsonminer.com/images/django/related-objects-mock.gif --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
QueryDict.iteritems behaves differently than QueryDict.items
I found the ticket for this strange behaviour of QueryDict, which
meant I wasn't alone having a problem with it -
http://code.djangoproject.com/ticket/7331,
and submited a patch.
It's actually MultiValueDict that is the cause, but let's clarify
things a little, first.
Consider this scenario:
>>> from django.http import QueryDict
>>> qd = QueryDict("a=1&b=2")
>>> qd.items()
[(u'a', u'1'), (u'b', u'2')]
>>> d = {}
>>> d.update(qd)
>>> d.items()
[(u'a', [u'1']), (u'b', [u'2'])]
Updating a dict with QueryDict as input results in having dict's
values converted to lists, which is broken IMO. The issue is with
MultiValueDict.iteritems() behaving differently than
MultiValueDict.items(). One yields lists, while the other returns
normal values.
Could this be fixed in 1.0? It breaks compatibility, I know.
regards,
jure
--~--~-~--~~~---~--~~
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 comments: CommonMiddleware (and others) break streaming HttpResponse objects.
> The only thing that might be worth doing in this are is adding a way to > say "middleware should never be called on this response" and then > somebody can write their own HttpResponse subclass and be in complete > control of their destiny. Would this disable ALL middleware from running? Or only the process_response methods on middleware? Either way, this is not ideal as there are useful middleware that CAN still work with on-demand content (e.g. the updated GZipMiddleware from the 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 -~--~~~~--~~--~--~---
Re: QueryDict.iteritems behaves differently than QueryDict.items
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 4, 2008, at 00:45, Jure Vrscaj wrote: > Could this be fixed in 1.0? It breaks compatibility, I know. Although I'm not in any kind of position of making such a decision, I can make an educated guess: no. The reason is that most developers currently focus on getting a Django 1.0 out the door, and so there'll be little to no time for a core committer to actually look at the patch and commit it, adding tests and that. That said, you should *definitely* file a bug report, and attach a patch that fixes the misbehavior and also add a regression test. Doubt there'll be any docs needed for this. Also, what compatibility does it break? I can't see how this is a common use-case. Regards, Ludvig "toxik" Ericson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkhtZp8ACgkQXnZ94Kd6KaettQCfbC6DfVjwbKj+1kcK4lXbnHs0 ar4AniFUpLSjQpe7PBjFnkluGqkSoJVS =o0QH -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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: #7560: Delegate (most) type conversion to backends
On Fri, Jul 4, 2008 at 4:57 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote: > > Hi all!, > > I've posted a patch[1] with a small refactor to some Field's > get_db_prep_* methods. Basically, for non-basic field types, the > database-prepared values is not computed by the Fields anymore, but Hi Leo, I've had a quick look at this patch. On the surface, it looks like a good idea and a pretty good implementation, but I'll need to spend a bit more time with it before I pass final judgement. > This patch is part of my work of running Django on Jython, and in > general helps anybody who maintains an external django database > backend. Completely aside from that, it may actually fix a few other problems we've been having - for example, MySQL's habit of returning 1/0 from boolean fields. It is also a nice cleanup of the handling of time fields. Thanks for your work on this. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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: #7560: Delegate (most) type conversion to backends
On Thu, Jul 3, 2008 at 8:27 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On Fri, Jul 4, 2008 at 4:57 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote: >> >> Hi all!, >> >> I've posted a patch[1] with a small refactor to some Field's >> get_db_prep_* methods. Basically, for non-basic field types, the >> database-prepared values is not computed by the Fields anymore, but > > Hi Leo, > > I've had a quick look at this patch. On the surface, it looks like a > good idea and a pretty good implementation, but I'll need to spend a > bit more time with it before I pass final judgement. Sure, and thanks for setting a few time aside to do this first review! >> This patch is part of my work of running Django on Jython, and in >> general helps anybody who maintains an external django database >> backend. > > Completely aside from that, it may actually fix a few other problems > we've been having - for example, MySQL's habit of returning 1/0 from > boolean fields. I'm not sure about it. The patch improves the Python -> DB conversion, not the other way around. -- Leo Soto M. http://blog.leosoto.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: #7560: Delegate (most) type conversion to backends
On Thu, 2008-07-03 at 16:57 -0400, Leo Soto M. wrote:
> Hi all!,
>
> I've posted a patch[1] with a small refactor to some Field's
> get_db_prep_* methods. Basically, for non-basic field types, the
> database-prepared values is not computed by the Fields anymore, but
> delegated to DatabaseOperations functions. As the current default
> logic was copied to the default methods implementations on
> DatabaseOperations, this should not break anything (I fully tested it
> a week ago, with the four official backends and indeed it didn't broke
> anything).
I've also read through the patch already and it seems like the right
track. I like the approach, since it helps in a few areas, including
field extensions and extra database backends.
I haven't given it a complete fine-detail review yet to pick things out
of individual lines, but only one thing jumped out on the initial read.
I've been trying very hard to eliminate lines like:
if settings.DATABASE_ENGINE.endswith('zxjdbc'):
from places outside the database backend-specific directories. This is
because it locks in particular backends to the main code, leading to
extensibility problems for other backends. So rather than introduce a
line like that, I'm always going to prefer to remove things like the
section following it that gives SQLite3 special handling.
Plus, if somebody wants to have a real database, the name needs to look
like they didn't just fall on their keyboard and "zxjdbc" doesn't pass
on those grounds. Looking like we threw up in the code is uncool. :-)
Mentally, I've queued it up behind Honza's validation and normalisation
changes, because I want to see how it interacts with that. I've got a
couple of more important bugs to fix immediately, but I'd like to get to
Honza's stuff as soon as possible and this weekend might be when I have
time. So, if Russell gets there first, no skin off my nose, otherwise I
might deal with it in the next few days.
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
-~--~~~~--~~--~--~---
Re: #7560: Delegate (most) type conversion to backends
On Thu, Jul 3, 2008 at 10:36 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> I've also read through the patch already and it seems like the right
> track. I like the approach, since it helps in a few areas, including
> field extensions and extra database backends.
>
> I haven't given it a complete fine-detail review yet to pick things out
> of individual lines, but only one thing jumped out on the initial read.
> I've been trying very hard to eliminate lines like:
>
> if settings.DATABASE_ENGINE.endswith('zxjdbc'):
>
> from places outside the database backend-specific directories. This is
> because it locks in particular backends to the main code, leading to
> extensibility problems for other backends. So rather than introduce a
> line like that, I'm always going to prefer to remove things like the
> section following it that gives SQLite3 special handling.
Yes, as I noted on the ticket description, I didn't really understood
why all that different formats were needed by each backend, so I was a
bit scared to touch that portion of code.
But now that you make me think again, that was just a lame excuse :-).
I just pushed that logic to DatabaseOperations and named it
"year_lookup_bounds".
So the new posted patch[1] is updated to svn trunk, and also fixes a
test that would broke because get_db_prep* now may return different
values for different backends.
[1]
http://code.djangoproject.com/attachment/ticket/7560/get_db_prep_refactor-3.patch
--
Leo Soto M.
http://blog.leosoto.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: QueryDict.iteritems behaves differently than QueryDict.items
On Fri, 2008-07-04 at 01:54 +0200, Ludvig Ericson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Jul 4, 2008, at 00:45, Jure Vrscaj wrote: > > > Could this be fixed in 1.0? It breaks compatibility, I know. > > > Although I'm not in any kind of position of making such a decision, I > can make an educated guess: no. The reason is that most developers > currently focus on getting a Django 1.0 out the door, and so there'll > be little to no time for a core committer to actually look at the > patch and commit it, adding tests and that. We're always going to look at things like this. It's 10 minutes of effort. :-) Certainly file a ticket so that the information doesn't get lost, Jure. The inconsistency looks a little wrong, although I'd have to think a bit about which return type is the "right" one, since there are arguments both ways. 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 -~--~~~~--~~--~--~---
