Clarification on what is getting into v1 & Ticket 3148
So our team is very fond of Ticket 3148 "Add getters and setters to model fields" which is in the "ready for checkin" stage. Does that mean it will be merged to the trunk soon (and thus become part of v1 release)? If not, what is the designation for tickets that will be part of v1? thanx, -- Ben Scherrey --~--~-~--~~~---~--~~ 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: Clarification on what is getting into v1 & Ticket 3148
El mar, 08-07-2008 a las 01:24 -0700, [EMAIL PROTECTED] escribió: > So our team is very fond of Ticket 3148 "Add getters and setters to > model fields" which is in the "ready for checkin" stage. Does that > mean it will be merged to the trunk soon (and thus become part of v1 > release)? Not exactly, "Ready for checkin" means that the ticket has everything it needs to be checked in. But does not say in what time. As it does not do something fancy it can get in either before v1 or later, it depends on if somebody has time to commit it. > If not, what is the designation for tickets that will be part of v1? Look here: http://code.djangoproject.com/wiki/VersionOneFeatures Those are the ones that *must* or *may* be for 1.0 Regards, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: newforms-admin and urls (reverse/etc)
I have begun work on the suggestion I made, the current diff is here: http://dpaste.com/61309/, right now the main issue I have is that currently AdminSite.root() sets self.root_path which I believe is no longer necessary(although I could be wrong), but I'm not 100% sure what it is used for(if it is used for relative URL redirects it should be possible since reverse should work with this), however hopefully someone more familar with NFA can assist. Within the diff any time I have removed a URL pattern from it's current location it means that it is reimplemented in the _get_urls method. Any assistance or ideas would(as always) be welcome. On Jul 8, 12:23 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > My suggestion is that we make AdminSite have an attr that is actually > a getter that dynamically generates a module like object that just has > a urlpatterns attr so it's basically a dynamically generated URLConf > and have each ModelAdmin cobble together it's portion and the > AdminSite can put it all together. If there is any interest in this > at all I can put together a prototype. > > On Jul 7, 11:24 pm, Collin Grady <[EMAIL PROTECTED]> wrote: > > > I know it's kind of late to bring this up, but I haven't been using the > > branch, > > so it hasn't been at the front of my mind at all :) > > > newforms-admin currently uses a url match of ^admin/(.*) which sort of kills > > reversing - you can't just pass the parts in, you have to manually build the > > string for the rest of the URL. > > > Would it be feasible to change that back to separate url matches like the > > current admin, or would that take too long at this close date? > > > Or perhaps another method would be to give newforms-admin its own helper to > > generate URLs? It's nice to be able to link back to admin for staff > > members, so > > you can quickly go and edit a page, so I think any fix along these lines > > would > > be very useful :) > > > -- > > Collin Grady > > > "I only touch base with reality on an as-needed basis!" > > -- Royal Floyd Mengot (Klaus) > > --~--~-~--~~~---~--~~ 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.contrib.sessions problems
On Tue, 2008-07-08 at 10:30 +0400, Ivan Sagalaev wrote: > Malcolm Tredinnick wrote: > > The rest of the conversation should > > proceed on the assumption that the bug about creating unique database > > entries will be fixed first. > > Now I think that the problem is only exists if one uses > non-transactional DB setup. In this case > due to race conditions one of the two simultaneous get_or_create calls > will "get" instead of "create". In a transactional setup one of the > transactions will fail to commit eventually since both get_or_create > will try to do INSERT not seeing each other. Not quite. The root problem is that get_or_create() is simply not designed at the moment to enforce the "create" side. It assumes that if another process creates the object during the call, then it's fine to get the result and carry on. The idea is that after you call it, the object exists in the database and you have a reference to the copy, not that *only* get or *only* create will be called. This is why two people can end up retrieving the same session object. There needs to be a path that says "this must create if it isn't already there". That's a bug that will be fixed. > May be the fix then will be > to always use explicit INSERT instead of get_or_create and let it fail > on unique constraint? That is the fix. It was discussed in the thread a couple of months ago. When I've done my high priority tasks, I'll get around to adding the ability to force insert or update at the model save level and the rest falls out naturally. It's easy and I have a patch that mostly works. But I need to review it again and it's in the queue. It's almost like we need some kind of ticket tracking system so that these things don't get lost and people won't start threads saying "look at mine! look at mine!" Oh, wait ... we do have one of those. :-( > P.S. Did I miss it in the thread or nobody talks about non-DB session > storages? It's more or less a side-issue that we'll work out as we go along. If non-db storages have a way of enforcing uniqueness, we'll use it (and that does require some effort to do -- I'm not dismissing them). However, the storage is the only reliable place to enforce uniqueness, so if the storage cannot guarantee it, Django can only work with what it's given. So, for example, file storage might have problems on some filesystems that don't have good locking semantics. Then it's a case of "go buy yourself a real filesystem". 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: Clarification on what is getting into v1 & Ticket 3148
On Tue, 2008-07-08 at 01:24 -0700, [EMAIL PROTECTED] wrote: > So our team is very fond of Ticket 3148 "Add getters and setters to > model fields" which is in the "ready for checkin" stage. Does that > mean it will be merged to the trunk soon (and thus become part of v1 > release)? > > If not, what is the designation for tickets that will be part of v1? One question to ask yourself (apart from "is it on the master list") when thinking about 1.0 features is whether something can be introduced later without breaking existing code. 1.0 is our "it will be stable" guarantee. Something like #3148 looks like it could pretty easily be added afterwards without affecting existing code. I'll also note that that ticket has sort of weaved it's way up to "ready for checkin" without too much participation from core developers and it's a bit of a change. It's sort of got there via "nobody's complained". Since Adrian seems to be the one most interested in it, it's likely to be him who will eventually address it, but whoever does it eventually, I wouldn't be too surprised to see it bounced back for better design or technical reasons (just playing the odds -- I haven't read the ticket after a very early patch some time back). 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: Clarification on what is getting into v1 & Ticket 3148
El mar, 08-07-2008 a las 19:34 +1000, Malcolm Tredinnick escribió: > I'll also note that that ticket has sort of weaved it's way up to "ready > for checkin" without too much participation from core developers and > it's a bit of a change. Dunno who the anonymous user was, not me ;) I didn't move it back to accepted as all concerns raised for the ticket were solved (including you comment #13). > Since Adrian seems to be the one most interested in it, it's likely to be > him who will eventually address it, but whoever does it eventually, I'm not sure on that point, that interest was showed 1 year and a half ago (comment #1) and was more like a design decission. The last core dev to show up was.. you! ;) > I wouldn't be too surprised to see it bounced back for better design or > technical reasons (just playing the odds -- I haven't > read the ticket after a very early patch some time back). I assume the patch you talk about is the one you commented, the parameter name was changed accordingly. Also Adrian's comment about doing it a bit more pythonic was also addressed. The patch is there, waitting for comments, please raise any technical/design concerns you have so I can address them. Regards, Marc PS: I also don't expect that one to get in for 1.0, I keep it near #689 and #6735 ;) PS: Thanks for the comments on the ticket¡! -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: django.contrib.sessions problems
On Tue, 2008-07-08 at 19:27 +1000, Malcolm Tredinnick wrote: [...] > It's almost like we need some kind of ticket tracking system so that > these things don't get lost and people won't start threads saying "look > at mine! look at mine!" Oh, wait ... we do have one of those. :-( Sorry. That was uncalled for on my part. I'm feeling buried under too many active threads, but I didn't need to take it out on the people in this one. 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: Reminder: "Must-have" feature freeze in two weeks
Jacob Kaplan-Moss wrote: > Hi folks -- > > This is your friendly reminder the three "must-have" features on the > roadmap are due on two weeks -- Django 1.0 alpha is due for release on > July 20th. > > We've got two sprints between then and now (see > http://code.djangoproject.com/wiki/Sprints) so I think we're in good > shape to get those things done. However, we need to focus on those > "big three" for the next few weeks. > > Can I get a status report on how everyone feels about this date and > the features on the alpha list? Since you're about to do #2 and Malcolm says #3 is essentialy done this leaves us with newforms-admin only. My call for local sprinters in Moscow resulted in 20+ participants so I'm optimistic that we'll have enough eyeballs and hands to work on it. I even think that bugs may come to an end sooner than the sprint :-). --~--~-~--~~~---~--~~ 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: fixture loading broken with django tagging
On Tue, Jul 8, 2008 at 5:10 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, > i just updated to the lastest newforms-admin django, and my fixtures > won't load anymore. ... > to me this looks like get_or_create is broken in some way. First off, unless you've actually confirmed that this is a bug in Django, this message would be better suited to the django-users mailing list. That said, I'd love to be able to help out here, but we really need a bit more detail than this to isolate the problem. A stack trace doesn't tell us much by itself - we need to know what you did to cause this problem. The first step would be a reproducable test case - other than saying that you are using django-tagging and newforms-admin, you haven't provided any details to help us reproduce your problem. Try to reduce your problem to a minimal application and test data set. This will also allow you to use trunk; given that the problem appears to have arisen during an upmerge from trunk to newforms-admin, the real problem will be one of the merged changesets. Working off trunk will allow you to establish the exact cause. It is also worth remembering that django-tagging uses contenttypes, which means that it will always be prone to the serialization problems identified in #7052. Without more details, its difficult to say exactly if this is the problem, but its not outside the realms of possibility; having a simple, repeatable test case will help a great deal in identifying if this is actually the problem. 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: django.contrib.sessions problems
On Jul 8, 5:27 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Increasing > some value from 32 bits to 64 bits is only changing some probabilities; > it's not actually solving the problem, just moving the goalposts to make > it harder to score an own goal. The rest of the conversation should > proceed on the assumption that the bug about creating unique database > entries will be fixed first. Agreed that the uniqueness bug takes precedence. But the uniform 63- bit randomness patch is also important. Once collisions happen, their handling is quite expensive, so they should be better avoided in the first place. Moreover, 63 bits are already used on 64-bit machines and I don't see any reason not to use it on 32-bit machines as well. --- I would like to get some feedback on the reliable session clearing problem next, http://code.djangoproject.com/ticket/7515 . Clearing session data in one step is a trivial addition: def clear(self): self._session.clear() self.modified = True Though better than manually erasing all session keys in a loop, this is not robust enough. Consider this scenario: * session with key X is created for user A * A "logs out" and session data is cleared, session key X will not be reset * session db backend tries remove the empty session, but database connection fails, exception is raised * cookie with old session key X remains in browser * user B accesses the site using the same browser, cookie with key X will be sent to the site * database has come online, session exists and A's sensitive information will be happily served to B Thus, reliable session clearing should assure that the session cookie is removed or updated with a different session key even when exceptions occur in the session storage backend. No hurry in replying, but discussing this is important in my humble opinion. Best, Mart Sõmermaa --~--~-~--~~~---~--~~ 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 408
Naruto 408 Naruto 408, One Piece 507, 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: Multiple database support
Hi guys, I've been heavily swamped with work for college, so I missed this thead and the few others on multiple databases. Sorry. I have implemented a proof-of-concept database scaling solution for Django. It tackles all kind of scaling issues I have seen in Django. It's purpose is mainly to find out if we could scale up Django at all. I didn't worry too much about syntax and the way it's supposed to integrate into Django - I just hacked away in Django code to make it work the fastest possible way I could think of. The solution covers the largest part of Simon's #2 problem. I added a few attributes and config parameters to the ORM so you can decide which models are hosted on which server. One model can be hosted on 20 servers with the actual location depending on a foreign key value. We're using it to store data for different groups on different servers for a more horizontal scaling. For example if a photo got a ForeignKey to group A it will be routed to server 15 because of some logic. You can also route objects 1-1000 to server 1 and 1001-2000 to server 2. I have also added database denormalization, caching foreign key querysets to the DB, bulk prefetching, in-model privacy checks and a few other things. A large percentage of the stuff probably isn't suitable for Django- trunk. Most of it tackles quite specific and hard scaling issues, but I guess there's a way to build it more modular and make it work for more people. After all I'm new to Django-developers and also to opening up my work. If some of you are interested in the code and would benefit from it I would be more than happy to share. Just posting a big pile of code probably won't help you too much, so I thought I'd write a few lines documentation about each part and post them here. Does that sound reasonable? Jan On May 22, 4:59 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > I have to admit I'm slightly worried about the multi-database > proposal, because at the moment it doesn't seem to solve either of the > multi-db problems I'm concerned about. > > The proposal at the moment deals with having different models live in > different databases - for example, the Forum application lives on DB1 > while the Blog application lives on DB2. > > I can see how this could be useful, but the two database problems that > keep me up at night are the following: > > 1. Replication - being able to send all of my writes to one master > machine but spread all of my reads over several slave machines. > Thankfully Ivan Sagalaev's confusingly named mysql_cluster covers this > problem neatly without modification to Django core - it's just an > alternative DB backend which demonstrates that doing this isn't > particularly hard:http://softwaremaniacs.org/soft/mysql_cluster/en/ > > 2. Sharding - being able to put User entries 1-1000 on DB1, whereas > User entries 1001-2000 live on DB2 and so on. > > I'd love Django to have built-in abilities to solve #1 - it's a really > important first-step onscalingup to multiple databases, and it's > also massively easier than any other part of the multi-db problem. > > I wouldn't expect a magic solution to #2 because it's so highly > dependent on the application that is being built, but at the same time > it would be nice to see a multi-db solution at least take this in to > account (maybe just by providing an easy tool to direct an ORM request > to a specific server based on some arbitrary logic). > > I may have misunderstood the proposal, but I think it's vital that the > above two use cases are considered. Even if they can't be solved > outright, providing tools that custom solutions to these cases can be > built with should be a priority for multi-db support. > > Cheers, > > Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
django serializers are not thread safe?
HI All! I have to deserialize, serialize objects in multiple threads with django serializers. But when I run Deserializer = serializers.get_deserializer(SERIALIZATION_FORMAT) in my threads (more then one, with _one_ thread all works great) I get KeyError in get_serializer function at `return _serializers[format].Deserializer` line because _load_serializers does not load all data at _serializers dict before another tread run get_deserializer at this another thread and completely populate serializers dictionary with all, builtin and user-defined serializers! That is why I think that get_(de)?serializers and/or _load_serializers must be thread safe like _populate function at AppCache! What do u think about that? Thanks! --~--~-~--~~~---~--~~ 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 serializers are not thread safe?
On Tue, 2008-07-08 at 05:49 -0700, sector119 wrote: > HI All! > > I have to deserialize, serialize objects in multiple threads with > django serializers. > > But when I run Deserializer = > serializers.get_deserializer(SERIALIZATION_FORMAT) in my threads (more > then one, with _one_ thread all works great) I get KeyError in > get_serializer function at `return _serializers[format].Deserializer` > line because _load_serializers does not load all data at _serializers > dict before another tread run get_deserializer at this another thread > and completely populate serializers dictionary with all, builtin and > user-defined serializers! Sounds like a possible explanation. Please open a ticket for it so this doesn't get forgotten. 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: django serializers are not thread safe?
I reviewed threading in Django and found a few problems, one of which is serialization. See http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading#Problems . Fix was contributed to the most eminent one in #6950, but I never got to fixing serialization. The fix is easy though, just use a temporary as demonstrated in "BETTER" at http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading#Errorsduetoincompleteinitialization On Jul 8, 3:56 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Tue, 2008-07-08 at 05:49 -0700, sector119 wrote: > > HI All! > > > I have to deserialize, serialize objects in multiple threads with > > django serializers. > > > But when I run Deserializer = > > serializers.get_deserializer(SERIALIZATION_FORMAT) in my threads (more > > then one, with _one_ thread all works great) I get KeyError in > > get_serializer function at `return _serializers[format].Deserializer` > > line because _load_serializers does not load all data at _serializers > > dict before another tread run get_deserializer at this another thread > > and completely populate serializers dictionary with all, builtin and > > user-defined serializers! > > Sounds like a possible explanation. Please open a ticket for it so this > doesn't get forgotten. > > 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: django serializers are not thread safe?
DONE! http://code.djangoproject.com/ticket/7676 --~--~-~--~~~---~--~~ 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 serializers are not thread safe?
Problems 2. django/core/serializers/__init__.py: _load_serializers() is unsafe, patch attached to #FIXME: Where can I found the patch? Where is "#FIXME:" ? ;) On 8 Лип, 16:07, mrts <[EMAIL PROTECTED]> wrote: > I reviewed threading in Django and found a few problems, one of which > is serialization. > Seehttp://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threadin... > . > > Fix was contributed to the most eminent one in #6950, but I never got > to fixing serialization. > The fix is easy though, just use a temporary as demonstrated in > "BETTER" > athttp://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threadin... > > On Jul 8, 3:56 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > On Tue, 2008-07-08 at 05:49 -0700, sector119 wrote: > > > HI All! > > > > I have to deserialize, serialize objects in multiple threads with > > > django serializers. > > > > But when I run Deserializer = > > > serializers.get_deserializer(SERIALIZATION_FORMAT) in my threads (more > > > then one, with _one_ thread all works great) I get KeyError in > > > get_serializer function at `return _serializers[format].Deserializer` > > > line because _load_serializers does not load all data at _serializers > > > dict before another tread run get_deserializer at this another thread > > > and completely populate serializers dictionary with all, builtin and > > > user-defined serializers! > > > Sounds like a possible explanation. Please open a ticket for it so this > > doesn't get forgotten. > > > 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: django serializers are not thread safe?
Patch uploaded to http://code.djangoproject.com/ticket/7676 , please test. On Jul 8, 4:21 pm, sector119 <[EMAIL PROTECTED]> wrote: > Problems > 2. django/core/serializers/__init__.py: _load_serializers() is > unsafe, patch attached to #FIXME: > > Where can I found the patch? Where is "#FIXME:" ? ;) > > On 8 Лип, 16:07, mrts <[EMAIL PROTECTED]> wrote: > > > I reviewed threading in Django and found a few problems, one of which > > is serialization. > > Seehttp://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threadin... > > . > > > Fix was contributed to the most eminent one in #6950, but I never got > > to fixing serialization. > > The fix is easy though, just use a temporary as demonstrated in > > "BETTER" > > athttp://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threadin... > > > On Jul 8, 3:56 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > > wrote: > > > > On Tue, 2008-07-08 at 05:49 -0700, sector119 wrote: > > > > HI All! > > > > > I have to deserialize, serialize objects in multiple threads with > > > > django serializers. > > > > > But when I run Deserializer = > > > > serializers.get_deserializer(SERIALIZATION_FORMAT) in my threads (more > > > > then one, with _one_ thread all works great) I get KeyError in > > > > get_serializer function at `return _serializers[format].Deserializer` > > > > line because _load_serializers does not load all data at _serializers > > > > dict before another tread run get_deserializer at this another thread > > > > and completely populate serializers dictionary with all, builtin and > > > > user-defined serializers! > > > > Sounds like a possible explanation. Please open a ticket for it so this > > > doesn't get forgotten. > > > > 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: MS SQL pyodbc backend update to trunk
On Tue, Jul 8, 2008 at 8:26 AM, vcc <[EMAIL PROTECTED]> wrote: > I just updated this backend, it's look like everything work fine for me. I > have some projects working with this backend, I'll keep improve it. Please > check the patch in the attachments. As Russ, and the many previous threads have pointed out: the thing to do right now is: 1. Put the code up somewhere public -- somewhere that is *not* djangoproject.com's ticket tracker or a mailing-list thread -- and advertise it to people. 2. Respond to bug reports and suggestions from people who use the code. 3. Repeat. Once there's an established history of good code and willingness to maintain it, then -- and only then -- should it be considered for inclusion in Django itself. Remember: database backends don't have to be distributed as part of Django, and can live anywhere on the Python path, so it's easy to do this. -- "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: MS SQL pyodbc backend update to trunk
On Tue, 2008-07-08 at 21:26 +0800, vcc wrote: > Thanks for Russ Magee, I see. > > I just updated this backend, it's look like everything work fine for me. I > have some projects working with this backend, I'll keep improve it. Please > check the patch in the attachments. So the best thing to do with a patch like this, rather than keep posting it here (since, as Russell mentioned, it's not up for consideration of committing to core at the moment), is to make it a proper external database backend. That means something that people can install anywhere on their Python path and then just put it into the DATABASE_ENGINE setting. It's a bit hard to read the patch you've attached, but it seems like you've made some changes to core pieces of code (e.g. models/fields/__init__.py). You should try to work out is the feature that is really needed there and then open a ticket with a general solution that can be used by all backends (and addition to DatabaseOperations, for example). For example, think about whether it's really necessary to add a tablespace option to the Field class or whether that can be part of the field column name (e.g. as a tuple). Ultimately, there should be no changes required to core for this after a few tickets for missing features are opened and discussed. Remember that we our goal is not to support every single feature of every database backend, so don't go crazy with feature requests. We just support the common stuff. But that's the right way forwards from here. 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: Proposal for dynamic form choices
On Sun, Jul 6, 2008 at 11:39 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Dynamic choices become an argument to the form constructor. The > argument is a dictionary of fieldname, choices pairs where choices is > either the choices structure we currently use, or a queryset. I have to say I'm with Malcolm on this one. I can see what you're trying to do, but an argument to __init__ doesn't seem like the right place to do it. > Now your form *instance* has restricted choices, but your form *class* > is untouched, which is exactly what we want. Is it? I can't say I have any particular form class defining a set of rules for the allowed choices, as long as there is flexibility to define the specific parameters on a per-instance basis. For example, consider the case where a ForeignKey(User) must take a currently active user, and the email address must match a argument provided on a per-instance basis. The is_active filter is constant across the class, as is the email__icontains=XXX; however, the value XXX per form instance. > So that takes care of dynamic choices for forms, but what about > generic views and admin views? For the admin, use the same approach > discussed in #3987 [1]. We can do the same thing for generic views > once they are class based [2]. > >class SomeAdmin(ModelAdmin): >def choices_for_owner(self, request): >return User.objects.filter(is_active=True) This general approach seems much more helpful, although ultimately I don't see it as being that far removed from the original proposal in #2445. Picking a 'choices_for_*' convention for a form method is essentially no different to allowing a callable argument to limit_choices_to that requires a particular prototype; as far as nomenclatures go, both have benefits, but the fact that the choices_for_ syntax can also be used for ModelAdmin (a la #3987) is a particularly good bonus. 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: Testing django-admin and manage.py
On Mon, Jul 7, 2008 at 10:08 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > One thing to watch for: I'm nearly 100% sure this won't work under the > buildbot -- it looks like since the settings file is written in the > same directory as the code you'll get conflicts between simultaneously > running tests. I think you'll need to use a temp dir. Hrm. If this is the case, it would be a right pain. Can anyone with more buildbot experience confirm this? > One thing this brings up: we really need a way to skip certain tests > under certain setups: We already do this in a few places; for example, the fixture modeltest disables some tests if you are using MySQL. This uses settings.DATABASE_ENGINE, but it's not big drama to use os.name instead. Russ %-) --~--~-~--~~~---~--~~ 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 serializers are not thread safe?
Works fine for me! Thanks a lot! On 8 Лип, 16:30, mrts <[EMAIL PROTECTED]> wrote: > Patch uploaded tohttp://code.djangoproject.com/ticket/7676, please > test. > > On Jul 8, 4:21 pm, sector119 <[EMAIL PROTECTED]> wrote: > > > Problems > > 2. django/core/serializers/__init__.py: _load_serializers() is > > unsafe, patch attached to #FIXME: > > > Where can I found the patch? Where is "#FIXME:" ? ;) > > > On 8 Лип, 16:07, mrts <[EMAIL PROTECTED]> wrote: > > > > I reviewed threading in Django and found a few problems, one of which > > > is serialization. > > > Seehttp://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threadin... > > > . > > > > Fix was contributed to the most eminent one in #6950, but I never got > > > to fixing serialization. > > > The fix is easy though, just use a temporary as demonstrated in > > > "BETTER" > > > athttp://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threadin... > > > > On Jul 8, 3:56 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > > > wrote: > > > > > On Tue, 2008-07-08 at 05:49 -0700, sector119 wrote: > > > > > HI All! > > > > > > I have to deserialize, serialize objects in multiple threads with > > > > > django serializers. > > > > > > But when I run Deserializer = > > > > > serializers.get_deserializer(SERIALIZATION_FORMAT) in my threads (more > > > > > then one, with _one_ thread all works great) I get KeyError in > > > > > get_serializer function at `return _serializers[format].Deserializer` > > > > > line because _load_serializers does not load all data at _serializers > > > > > dict before another tread run get_deserializer at this another thread > > > > > and completely populate serializers dictionary with all, builtin and > > > > > user-defined serializers! > > > > > Sounds like a possible explanation. Please open a ticket for it so this > > > > doesn't get forgotten. > > > > > 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: Multiple database support
Hi Jan, It sounds like you've made great progress. We have an informal trac and hg repo set up at trac and hg dot woe-beti.de respectively. you're more than welcome to add your documentation there! Let me know if you want an hg repo tp play with too and I'll sort it out for you. Cheers, Ben 2008/7/8 Jan Oberst <[EMAIL PROTECTED]>: > > Hi guys, > > I've been heavily swamped with work for college, so I missed this > thead and the few others on multiple databases. Sorry. > > I have implemented a proof-of-concept database scaling solution for > Django. It tackles all kind of scaling issues I have seen in Django. > It's purpose is mainly to find out if we could scale up Django at all. > I didn't worry too much about syntax and the way it's supposed to > integrate into Django - I just hacked away in Django code to make it > work the fastest possible way I could think of. > > > The solution covers the largest part of Simon's #2 problem. I added a > few attributes and config parameters to the ORM so you can decide > which models are hosted on which server. One model can be hosted on 20 > servers with the actual location depending on a foreign key value. > > We're using it to store data for different groups on different servers > for a more horizontal scaling. For example if a photo got a ForeignKey > to group A it will be routed to server 15 because of some logic. > > You can also route objects 1-1000 to server 1 and 1001-2000 to server > 2. > > > I have also added database denormalization, caching foreign key > querysets to the DB, bulk prefetching, in-model privacy checks and a > few other things. > > A large percentage of the stuff probably isn't suitable for Django- > trunk. Most of it tackles quite specific and hard scaling issues, but > I guess there's a way to build it more modular and make it work for > more people. After all I'm new to Django-developers and also to > opening up my work. > > If some of you are interested in the code and would benefit from it I > would be more than happy to share. > > Just posting a big pile of code probably won't help you too much, so I > thought I'd write a few lines documentation about each part and post > them here. Does that sound reasonable? > > Jan > > On May 22, 4:59 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > > I have to admit I'm slightly worried about the multi-database > > proposal, because at the moment it doesn't seem to solve either of the > > multi-db problems I'm concerned about. > > > > The proposal at the moment deals with having different models live in > > different databases - for example, the Forum application lives on DB1 > > while the Blog application lives on DB2. > > > > I can see how this could be useful, but the two database problems that > > keep me up at night are the following: > > > > 1. Replication - being able to send all of my writes to one master > > machine but spread all of my reads over several slave machines. > > Thankfully Ivan Sagalaev's confusingly named mysql_cluster covers this > > problem neatly without modification to Django core - it's just an > > alternative DB backend which demonstrates that doing this isn't > > particularly hard:http://softwaremaniacs.org/soft/mysql_cluster/en/ > > > > 2. Sharding - being able to put User entries 1-1000 on DB1, whereas > > User entries 1001-2000 live on DB2 and so on. > > > > I'd love Django to have built-in abilities to solve #1 - it's a really > > important first-step onscalingup to multiple databases, and it's > > also massively easier than any other part of the multi-db problem. > > > > I wouldn't expect a magic solution to #2 because it's so highly > > dependent on the application that is being built, but at the same time > > it would be nice to see a multi-db solution at least take this in to > > account (maybe just by providing an easy tool to direct an ORM request > > to a specific server based on some arbitrary logic). > > > > I may have misunderstood the proposal, but I think it's vital that the > > above two use cases are considered. Even if they can't be solved > > outright, providing tools that custom solutions to these cases can be > > built with should be a priority for multi-db support. > > > > Cheers, > > > > Simon > > > -- Regards, Ben Ford [EMAIL PROTECTED] +447792598685 --~--~-~--~~~---~--~~ 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: Testing django-admin and manage.py
On Mon, Jul 7, 2008 at 10:10 PM, Simon Willison <[EMAIL PROTECTED]> wrote: > > On Jul 7, 3:00 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > The bash script appears to be used purely to set the environment > variables. Is there any reason you can't just directly assign to > os.environ from within Python code to achieve this? Eliminating the > bash script would make it much easier to achieve Windows compatibility. I originally avoided this because of a CLASSPATH mangling hangover resulting from my dim dark days as a Java programmer. However, I've just tested your suggestion, and it appears to work just fine. I've updated the patch on #6017 to use a scriptless approach; I suppose this means that the tests should now work under Windows (although, again, I haven't got the facilities to validate this). Russ %-) --~--~-~--~~~---~--~~ 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: Testing django-admin and manage.py
On Mon, Jul 7, 2008 at 11:06 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > On Mon, Jul 7, 2008 at 10:00 AM, Russell Keith-Magee > I get 17 failures running on Ubuntu (gutsy), but maybe I'm missing something > else needed for the tests to run properly? I just added the > django-admin-tests.diff to a pristine trunk checkout. I had to create an > __init__.py file in the admin-scripts directory and set the execute bit on > the .sh files. Here's the output: > > http://dpaste.com/61132/ > > Of 77 tests that run only 17 report failures so some things are working but > it isn't immediately obvious to me what's going wrong with the rest. To the best of my knowledge, there shouldn't be anything else required to run the tests, other than python in your system path. One possible cause is the __init__.py files; there are 3 required in total - admin_scripts, admin_scripts/management, and admin_scripts/management/commands. The patch contains entries for those files, but they're empty, so there are no patch instructions. Either way, I've made some modifications to the tests so that they are a little bit more meaningful on error - in particular, I've added validation that no errors are received if none are expected. If the problem isn't the __init__.py files, the extra assertions should make it easier to track down the problem. Could I impose upon you to take the new patch for a spin? > Simon's idea of eliminating the bash scripts entirely sounds good to me, > assuming it can be done. Can be, and has. Updated patch available on #6107. I believe this means that the new scripts should run under Windows; If you could take this version for a spin under Windows too, I'd be much obliged. 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 -~--~~~~--~~--~--~---
Future-proofing against circular imports -- sane for post-1.0?
Since bringing up the topic a few months ago (and getting support for the idea) [1], I haven't had time to whip up a patch to move the contents of various modules' __init__ out into "base" or "main". It finally clicked (you know, several weeks *after* 1.0 features were nailed down, ugh) that this may-or-may-not be such a sane thing to do post-1.0 with a stability freeze. Since I'd like to see non-public API pieces no longer imported back into the __init__ modules eventually (following a depreciation period), I'm curious as to whether others think we can still manage this cleanly post-1.0. If we can, great! — I'll just wait until then. If not, is there any chance we can squeeze this in somewhere? [1] http://groups.google.com/group/django-developers/browse_thread/thread/35aae0e8da804bd9 --~--~-~--~~~---~--~~ 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: Testing django-admin and manage.py
On Tue, Jul 8, 2008 at 10:53 AM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > To the best of my knowledge, there shouldn't be anything else required > to run the tests, other than python in your system path. > > One possible cause is the __init__.py files; there are 3 required in > total - admin_scripts, admin_scripts/management, and > admin_scripts/management/commands. The patch contains entries for > those files, but they're empty, so there are no patch instructions. > That was it. Missing the first one generated an error that screamed "missing __init__.py file" but the others not so much. So I only added the first one, not noticing the others were needed as well. With all of them all 77 tests pass on Ubuntu (both new and old patch). > > Simon's idea of eliminating the bash scripts entirely sounds good to me, > > assuming it can be done. > > Can be, and has. Updated patch available on #6107. I believe this > means that the new scripts should run under Windows; If you could take > this version for a spin under Windows too, I'd be much obliged. > Yes, the tests run on Windows now as well. Only problem is two tests with file paths in their output, the forward slashes are backslashes on Windows so the output doesn't match what the tests are looking for: http://dpaste.com/61364/ Not sure if/how you ordinarily get around that in testing? Cheers, 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 -~--~~~~--~~--~--~---
Re: Testing django-admin and manage.py
> Yes, the tests run on Windows now as well. Only problem is two tests with
> file paths in their output, the forward slashes are backslashes on Windows
> so the output doesn't match what the tests are looking for:
>
> http://dpaste.com/61364/
>
> Not sure if/how you ordinarily get around that in testing?
self.assertOutput(out, os.path.join('django', 'contrib', 'auth',
'models.pyc'), ...)
--~--~-~--~~~---~--~~
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: GSOC: More backends for djangosearch
On 8 Jul 2008, at 03:17, Rajeev J Sebastian wrote: > > The latest PG has its own text indexing/search system ... is this what > you are referring to by "tsearch2" ? > Yes, exactly. http://www.sai.msu.su/~megera/wiki/Tsearch2_83_changes There do appear to be naming differences between the 8.2 contrib version and the one built into 8.3. Maybe a legacy option is needed? Ben --~--~-~--~~~---~--~~ 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: Future-proofing against circular imports -- sane for post-1.0?
On Tue, 2008-07-08 at 09:55 -0500, Tom Tobin wrote: [...] > I'm curious as to > whether others think we can still manage this cleanly post-1.0. If we > can, great! — I'll just wait until then. If not, is there any chance > we can squeeze this in somewhere? It depends on what will change. "from django import templates" seems like pretty public API. So if your change will mean that any external code doing that would have to change it's imports at all (i.e. if things that were previously available under the django.templates are no longer there), it must be done pre-1.0, otherwise it's not API stable. So work that out and then we're in a better position to decide. I guess if code that does "from django.template import loaders" was to change, too, that would be an API breakage. The reason I've identified those two paths (templates and templates.loaders) is because they're the import paths mentioned in the public documentation. So we're saying they are public API (it's not an "if an only if" assertion, but if something's in the docs, we're certainly recommending its use) It sounds like you *are* talking about a change that is that intrusive, so it needs to be done beforehand. Just how bad are the import lists going to be? Hopefully you can arrange so it's still basically a one-file import: "from django.templates import main_file" or something. Except you have to think of a better name. 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: Future-proofing against circular imports -- sane for post-1.0?
On Tue, Jul 8, 2008 at 6:08 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-07-08 at 09:55 -0500, Tom Tobin wrote:
> [...]
>> I'm curious as to
>> whether others think we can still manage this cleanly post-1.0. If we
>> can, great! — I'll just wait until then. If not, is there any chance
>> we can squeeze this in somewhere?
>
> It depends on what will change. "from django import templates" seems
> like pretty public API. So if your change will mean that any external
> code doing that would have to change it's imports at all (i.e. if things
> that were previously available under the django.templates are no longer
> there), it must be done pre-1.0, otherwise it's not API stable. So work
> that out and then we're in a better position to decide.
I don't want to change the public APIs. If "from django import
templates" works now, it should work after I'm done. The chief BICs
would be for importing non-public pieces, and even in those cases I
think a period with a DepreciationWarning might be justified (which,
being non-public pieces, could be post-1.0).
What I'm trying to achieve here isn't so much for the public API as
it is for private/internal sanity: when someone sits down and
refactors something (the original case being my hacking on
django.templates), they shouldn't be stuck in circular import hell
because the actual code lives in an __init__ module. By all means, if
a public API is better off having a collapsed namespace inside of the
__init__, I don't want to stop that ("from django.templates.base
import *" inside the __init__ should work).
> It sounds like you *are* talking about a change that is that intrusive,
> so it needs to be done beforehand. Just how bad are the import lists
> going to be? Hopefully you can arrange so it's still basically a
> one-file import: "from django.templates import main_file" or something.
> Except you have to think of a better name.
Maybe I'm making a mountain out of a molehill. If the public-facing
API is the only thing we're guaranteeing, maybe there's not much of a
problem 1.0-wise: I could still yank everything out into "base"
modules at a later point. I'm trying to come up with scenarios where
these changes might break someone else's code once made; does anyone
have an example?
--~--~-~--~~~---~--~~
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: MS SQL pyodbc backend update to trunk
Looks like this backend is going quite well. For what it's worth, I solved the other end of the datetime/date/time problem by patching django.db.models.query.QuerySet.iterator. I expect there's a better solution than this but I thought I'd post this because it at least works. def iterator(self): """ An iterator over the results from applying this QuerySet to the database. """ fill_cache = self.query.select_related if isinstance(fill_cache, dict): requested = fill_cache else: requested = None max_depth = self.query.max_depth extra_select = self.query.extra_select.keys() index_start = len(extra_select) for row in self.query.results_iter(): if fill_cache: obj, _ = get_cached_row(self.model, row, index_start, max_depth, requested=requested) else: obj = self.model(*row[index_start:]) # Fix for databases that only have datetime fields # (rather than date, time and datetime fields) import django import datetime for f in self.model._meta.fields: val = obj.__getattribute__(f.name) if isinstance(f, django.db.models.fields.DateField) and isinstance(val, datetime.datetime): obj.__setattr__(f.name, datetime.date(val.year, val.month, val.day)) elif isinstance(f, django.db.models.fields.TimeField) and isinstance(val, datetime.datetime): obj.__setattr__(f.name, datetime.time(val.hour, val.minute, val.second)) # End datetime/date/time fix for i, k in enumerate(extra_select): setattr(obj, k, row[i]) yield obj --~--~-~--~~~---~--~~ 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: Future-proofing against circular imports -- sane for post-1.0?
On Tue, 2008-07-08 at 19:26 -0500, Tom Tobin wrote:
[...]
> I don't want to change the public APIs. If "from django import
> templates" works now, it should work after I'm done. The chief BICs
> would be for importing non-public pieces, and even in those cases I
> think a period with a DepreciationWarning might be justified (which,
> being non-public pieces, could be post-1.0).
*Deprecation*, dagnabbit! Depreciation is a different word. :-)
> What I'm trying to achieve here isn't so much for the public API as
> it is for private/internal sanity: when someone sits down and
> refactors something (the original case being my hacking on
> django.templates), they shouldn't be stuck in circular import hell
> because the actual code lives in an __init__ module. By all means, if
> a public API is better off having a collapsed namespace inside of the
> __init__, I don't want to stop that ("from django.templates.base
> import *" inside the __init__ should work).
I don't quite see how you're going to pull this off. I believe you when
you say you think it's possible and I'm probably just missing some
things (admittedly, I'm not actually reading the code or trying to do
the refactor in my head, so missing stuff is definitely on the cards).
Still, it might be good to have a proof-of-concept swing at things
before 1.0 just to make sure you haven't missed anything. Since "from
foo import *" completely parses "foo", it means that if that line is in
__init__ it's going to be executed whenever somebody imports anything
from that directory (not using "import *" will save a bunch of those
problems, though. I don't always understand what Guido was smoking when
he allowed that into the language).
Obviously it must be possible to make this work, since the current
situation works. I've done some pretty deep spelunking in that directory
without hitting anything that's impossible, so some permutation of the
current code is always going to be possible.
Anyway, you've got a few weeks. Probably worth whacking together a first
pass to see that there are no hidden shoals.
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: Future-proofing against circular imports -- sane for post-1.0?
On Tue, Jul 8, 2008 at 8:49 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > *Deprecation*, dagnabbit! Depreciation is a different word. :-) Ye grammar gods! I'm usually more on top of things than that. Shame on me! ^_^ [...] > Anyway, you've got a few weeks. Probably worth whacking together a first > pass to see that there are no hidden shoals. Good idea; we'll have a much better idea of where things stand. I've done it before in the limited case of django.template, with all tests passing, but this was a few months back; time to take another crack at it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
watch actress sexy photo from movie clips and watch actress profile http://priyamaniforyou.blogspot.com/
watch actress sexy photo from movie clips and watch actress profile http://priyamaniforyou.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 -~--~~~~--~~--~--~---
