Enhanced URL Resolver Match
When Django 1.1 was released URLs gained the ability to be nested with namespaces by adding "app_name" and "namespace" attributes to the include(...) functions within urls.py. The reverse(...) function was updated to allow you to specify namespace and current_app when resolving URLs, however, we never brought the resolve(...) function up to speed to include the relevant namespace and app_name data of the resolved URL. I have taken an initial stab with code and tests (minus documentation, until this feature is completed and agreed upon by the community). In order to achieve this I have graduated the result of the resolve(...) method to be a ResolverMatch class as opposed to the old tuple(func, args, kwargs). I have also implemented this feature to provides backwards compatibility for the old "func, args, kwargs = resolve(...)" so this feature should hopefully be completely backwards compatible. The new ResolverMatch class provides access to all attributes of the resolved URL match such as (url_name, app_name, namespace, func, args, kwargs). Please take a look and let me know what you think of the direction and implementation: http://github.com/nowells/django/compare/master...resolver-match Thanks! Nowell Strite -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Calling remote API
Sorry if I post on the wrong forums, as far as I know Django doesn't have a support for calling remote API, which makes me think more of a general python related thing. Thanks and I'll try in Django Forums. On Jul 9, 10:40 am, Russell Keith-Magee wrote: > On Fri, Jul 9, 2010 at 10:36 AM, james_027 wrote: > > hi all, > > > It will be my first time to create django app that requires calling > > remote API. aside from URLLIB2, any good library for this purpose? > > Questions like this should be directed to django-users. > Django-developers is a mailing list for discussing the development of > Django itself. > > 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Calling remote API
Oops. Sorry for replying here. I didn't realize what list this was. Original poster: Please post to the django-users list. This one is for the development of Django itself, not users of Django Shawn -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Calling remote API
On Fri, Jul 9, 2010 at 10:36 AM, james_027 wrote: > hi all, > > It will be my first time to create django app that requires calling > remote API. aside from URLLIB2, any good library for this purpose? Questions like this should be directed to django-users. Django-developers is a mailing list for discussing the development of Django itself. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Calling remote API
What's wrong with urllib2.urlopen()? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Calling remote API
hi all, It will be my first time to create django app that requires calling remote API. aside from URLLIB2, any good library for this purpose? thanks, James -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: New admin feature: Delete and replace with existing object
On Thu, Jul 8, 2010 at 11:19 PM, Ric wrote:
> Hi Russ, nice to talk with u,
>
> i think that we can focus only on substitute feature,
> to archive it we have 2 options:
>
> simply upgrade the current delete_view or make a new view, something
> like
> url(r'^(.+)/substitute/$',
> wrap(self.substitute_view),
> name='%s_%s_substitute' % info),
>
>
> to make it work for every model we need to build form with one
> ModelChoiceField.
> this field will be initialized with a queryset of the model_admin
> (queryset method), and then call the queryset exclude method to remove
> from the field the instance/s that will be deleted.
>
> field = forms.ModelChoiceField(queryset =
> self.queryset(request).exclude(**{"%s__in" %
> self.model._meta.pk.attname: objects_to_delete})
>
> so imagine that we have 10 object
>
> 1 Banana
> 2 Apple
> 3 Tree
> 4 ...
> 10 Stick
>
> we mark for deletion object 1 and 2, in the view the form will make us
> choose objects from 3 to 10, the use choose to substitute with object
> 3 and all Banana and Apple in the database will be replaced with a
> Tree, using the queryset update method.
>
> is it clear?
This much was already clear. My concern is about the edge cases.
Lets say we have an Author model that we are deleting. You're giving
the use case of deleting an author, and modifying all the Blog posts
that reference that author so that they point somewhere else. I have
no problems with the concept or implementation of this as you describe
it.
But:
* What if you have multiple models referring to Author? Do you assume
that every related model will be updated the same way?
* What if you have multiple foreign keys from Blog to Author? Do you
assume that every foreign key on a single model will be updated in the
same way?
* What if there is a model with a m2m relation to Author? Do you
delete the m2m relation, or do you replace it with the substituted
object?
* What if you use admin actions to delete N authors? Do we assume
that every one of the authors will be replaced with the same single
substitute?
These sorts of decisions are all business logic decisions. You may
have a good answer for your site, but I'm not convinced that there is
a universal answer that will always be correct for all users, and I'm
not convinced that it would be possible to define an easily
configurable interface to expose all possible interpretations of this
feature.
This is why I'm suggesting that the best approach here is to make it
*possible*, but not to bake this capability into Django itself. If we
provide the appropriate hooks, you (as an end user) should be able to
add whatever implementation of this feature you want.
If there are hooks on Django's admin that need to be added or
modified, then I'm happy to entertain those changes.
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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: MySQL index hints
On Thu, Jul 8, 2010 at 3:51 PM, Simon Riggs wrote: > On Mon, 2010-07-05 at 00:59 -0700, Simon Litchfield wrote: >> > If you can come up with answers to these points, I might get >> > interested. 1 and 2 are fairly trivial; I can think of some obvious >> > answers for 3, but 4 is the big problem, and will require some >> serious >> > research and consideration. >> >> Well, I'm glad you like the with_hints() approach. Items 1-3 are easy. >> Re 4 though, every db does it differently. In practice, most don't >> need hints like MySQL does , because their query optimisers do a >> much better job. > > The big problem I see is that hints are simply the wrong approach to > handling this issue, which I do see as an important one. > > The SQL optimizer can't work out how you're going to handle the queryset > if all you mention is the filter(). SQL being a set-based language the > optimizer won't know whether you wish to retrieve 0, 1 or 1 million > rows. In many cases it actively avoids using the index for what it > thinks will be larger retrievals. > That's categorically untrue. One of the major functions of an optimizer is too try to figure out the approximate result size so it can better establish index vs. data cost. > The number of rows required from the queryset is an important part of > defining the access path. Hints are only required because we didn't > specify the queryset in sufficient detail for the optimizer to > understand what we wanted. > Uhh, querysets don't really generate SQL that's in any way different from what a normal person would write. > I would say the correct approach here is to use slicing, since this will > add a LIMIT clause and provide full usage information to the SQL > optimizer about the queryset. > > Can I suggest an auto-slice parameter so that we can add LIMIT N onto > the bottom of every query by default, if a slice is not already defined. > That would work for all DBMS. > And auto_slice parameter to what exactly? > -- > Simon Riggs www.2ndQuadrant.com > PostgreSQL Development, 24x7 Support, Training and Services > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: MySQL index hints
On Mon, 2010-07-05 at 00:59 -0700, Simon Litchfield wrote: > > If you can come up with answers to these points, I might get > > interested. 1 and 2 are fairly trivial; I can think of some obvious > > answers for 3, but 4 is the big problem, and will require some > serious > > research and consideration. > > Well, I'm glad you like the with_hints() approach. Items 1-3 are easy. > Re 4 though, every db does it differently. In practice, most don't > need hints like MySQL does , because their query optimisers do a > much better job. The big problem I see is that hints are simply the wrong approach to handling this issue, which I do see as an important one. The SQL optimizer can't work out how you're going to handle the queryset if all you mention is the filter(). SQL being a set-based language the optimizer won't know whether you wish to retrieve 0, 1 or 1 million rows. In many cases it actively avoids using the index for what it thinks will be larger retrievals. The number of rows required from the queryset is an important part of defining the access path. Hints are only required because we didn't specify the queryset in sufficient detail for the optimizer to understand what we wanted. I would say the correct approach here is to use slicing, since this will add a LIMIT clause and provide full usage information to the SQL optimizer about the queryset. Can I suggest an auto-slice parameter so that we can add LIMIT N onto the bottom of every query by default, if a slice is not already defined. That would work for all DBMS. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Problem with randrange in django/middleware/csrf.py
On Thu, Jul 8, 2010 at 4:09 PM, DanEE wrote: > The problems with randrange also occur when I run it directly from a > normal python prompt. > >[...] > So it doesn't seem to be a django problem, but it still is very > annoying. > >> If the host has not enough entropy, Django shouldn't fix it, an >> administrator should. > Are there any suggestions how I could fix it? I don't even know where > to start looking... If you are using Linux, try a: $ find / http://burtonini.com/blog/computers/cups-2006-08-14-18-00 Longer term solutions for production servers might involve implementing a hardware assisted RNG like the Entropy Key already mentioned or randomsound: http://packages.debian.org/search?keywords=randomsound Regards, -- Ramiro Morales | http://rmorales.net -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Problem with randrange in django/middleware/csrf.py
The problems with randrange also occur when I run it directly from a normal python prompt. >>> random.randrange(0, 2<<63) instantly returns me the random numbers. whereas >>> random.SystemRandom().randrange(0, 2<<63) Takes forever to run. I cancelled the execution after about 10 minutes. As an interesting side notice: >>> random.SystemRandom().randrange(0, 2<<51) works fine and returns instantly with a random number >>> random.SystemRandom().randrange(0, 2<<52) however seems to run forever without any result... So it doesn't seem to be a django problem, but it still is very annoying. > If the host has not enough entropy, Django shouldn't fix it, an > administrator should. Are there any suggestions how I could fix it? I don't even know where to start looking... PS: >>> random.SystemRandom().randrange(0, 2<<63) works without any problems on my windows machine and on another hosted linux server where I have access to. Daniel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Problem with randrange in django/middleware/csrf.py
> >> By playing around in a python session it seems that the call to the > >> system randrange with random.SystemRandom().randrange(0, > >> _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30 > >> minutes) whereas a call to the "normal" randrange with randrange(0, > >> _MAX_CSRF_KEY) happily returns the desired random number. This sounds like python is unable to get a secure random number from the OS. The OS can run out of entropy, it may even happen faster on shared systems. http://www.entropykey.co.uk/ says (and they probably know): "Applications that require random data, [...] read from this pool. The problem is that the pool is of fixed size (just 4kB) and as standard has limited entropy input. If an application tries to read from the pool, and there is not enough data to satisfy its request, the application is frozen in limbo until enough entropy has been collected to fill the pool to the point of being able to satisfy the request, leading to delays in the delivery of services." Sounds like what happened to you. > I'm unclear on why we even allow this code to work with the "default" > random implementation, which is based on a Messrne Twister, and > (quoting the Python docs here), "is completely unsuitable for > cryptographic purposes". To my understand that's how we're trying to > use it, and if I'm wrong here I wonder why we give preference to the > system random at all? If DEBUG=False, there shouldn't be a fallback to non-secure random numbers, maybe there shouldn't even be a fallback at all. If the host has not enough entropy, Django shouldn't fix it, an administrator should. Cheers Stefan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: New admin feature: Delete and replace with existing object
i took this idea from wordpress. in wordpress when you delete an user
instead of deleting all related posts you can choose to assign them to
another user.
we can extend this system on every model class, i think.
whatch here, sorry wordpress is in italian (hope u understand a
little)
http://grab.by/5kn6
we can use a radio field to choose the mode (or we can choose the mode
with a GET param, or with two different urls ^delete/ and
^substitute/), and then a combobox to select the instance...
not too difficult, and it would be a fancy feature.
On Jul 7, 3:20 pm, Russell Keith-Magee
wrote:
> On Wed, Jul 7, 2010 at 3:41 PM, Ric wrote:
> > Hello i opened a ticket, but somone suggest me to discuss this new
> > feature here.
>
> >http://code.djangoproject.com/ticket/13900
> >
> > i would like to edit
> > django.contrib.admin.options.ModelAdmin?.delete_view and add a helpful
> > feature.
>
> > Instead of deleting all the nested objects, the delete_view could
> > handle 3 options:
>
> > 1. delete all the related objects (current option)
> > 2. where the foreign key to the current instance is nullable, null or
> > delete
>
> These first two options are really a duplicate of ticket #7539; it
> isn't something that should be handled at the admin level, but at the
> model level. The broad ideas behind #7539 are well established; the
> patch just needs to be carried the last few steps to trunk.
>
> > 3. replace all the related objects with an other model instance (we
> > can make a user choose it with a forms.ModelChoiceField?)
> > i really would like to contribute to this feature, because i need to
> > do this in my admin site, but i'm new, so please help me :)
>
> This is an interesting idea. At a raw technical level, introducing a
> 'pre-deletion cleanup' stage for admin deletions shouldn't be too
> difficult -- the current deletion confirmation view provides a
> convenient place in the workflow that could be replaced with a view
> that provides options to nominate how relations should be cleaned up.
>
> However, my concern is whether this could be made a generic
> capability. If this is to become a configurable capability of the
> admin interface, it needs to work with every possible model, not just
> a subset of models. It isn't immediately obvious to me how you could
> specify a relation substitution scheme in a completely generic way.
>
> There's also the issue of how to handle this sort of substitution on a
> bulk delete - if you're deleting a group of 50 objects using an admin
> bulk action or as a result of a cascaded deletion, you don't want to
> be presented with an auto-generated dialog of 50 pulldown/raw_id_admin
> widgets.
>
> I suspect the best course of action for trunk will be to make it
> *possible* to easily introduce a pre-deletion stage, but not actually
> provide that capability as part of core admin functionality (i.e.,
> cleanup and document the mechanism by which you can define a
> pre-delete view, but not actually provide a "cleanup= ('field',
> 'field')" definition on ModelAdmin that automatically turns into a
> pre-configured deletion view.
>
> 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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: New admin feature: Delete and replace with existing object
Hi Russ, nice to talk with u,
i think that we can focus only on substitute feature,
to archive it we have 2 options:
simply upgrade the current delete_view or make a new view, something
like
url(r'^(.+)/substitute/$',
wrap(self.substitute_view),
name='%s_%s_substitute' % info),
to make it work for every model we need to build form with one
ModelChoiceField.
this field will be initialized with a queryset of the model_admin
(queryset method), and then call the queryset exclude method to remove
from the field the instance/s that will be deleted.
field = forms.ModelChoiceField(queryset =
self.queryset(request).exclude(**{"%s__in" %
self.model._meta.pk.attname: objects_to_delete})
so imagine that we have 10 object
1 Banana
2 Apple
3 Tree
4 ...
10 Stick
we mark for deletion object 1 and 2, in the view the form will make us
choose objects from 3 to 10, the use choose to substitute with object
3 and all Banana and Apple in the database will be replaced with a
Tree, using the queryset update method.
is it clear?
On 7 Lug, 15:20, Russell Keith-Magee wrote:
> On Wed, Jul 7, 2010 at 3:41 PM, Ric wrote:
> > Hello i opened a ticket, but somone suggest me to discuss this new
> > feature here.
>
> >http://code.djangoproject.com/ticket/13900
> >
> > i would like to edit
> > django.contrib.admin.options.ModelAdmin?.delete_view and add a helpful
> > feature.
>
> > Instead of deleting all the nested objects, the delete_view could
> > handle 3 options:
>
> > 1. delete all the related objects (current option)
> > 2. where the foreign key to the current instance is nullable, null or
> > delete
>
> These first two options are really a duplicate of ticket #7539; it
> isn't something that should be handled at the admin level, but at the
> model level. The broad ideas behind #7539 are well established; the
> patch just needs to be carried the last few steps to trunk.
>
> > 3. replace all the related objects with an other model instance (we
> > can make a user choose it with a forms.ModelChoiceField?)
> > i really would like to contribute to this feature, because i need to
> > do this in my admin site, but i'm new, so please help me :)
>
> This is an interesting idea. At a raw technical level, introducing a
> 'pre-deletion cleanup' stage for admin deletions shouldn't be too
> difficult -- the current deletion confirmation view provides a
> convenient place in the workflow that could be replaced with a view
> that provides options to nominate how relations should be cleaned up.
>
> However, my concern is whether this could be made a generic
> capability. If this is to become a configurable capability of the
> admin interface, it needs to work with every possible model, not just
> a subset of models. It isn't immediately obvious to me how you could
> specify a relation substitution scheme in a completely generic way.
>
> There's also the issue of how to handle this sort of substitution on a
> bulk delete - if you're deleting a group of 50 objects using an admin
> bulk action or as a result of a cascaded deletion, you don't want to
> be presented with an auto-generated dialog of 50 pulldown/raw_id_admin
> widgets.
>
> I suspect the best course of action for trunk will be to make it
> *possible* to easily introduce a pre-deletion stage, but not actually
> provide that capability as part of core admin functionality (i.e.,
> cleanup and document the mechanism by which you can define a
> pre-delete view, but not actually provide a "cleanup= ('field',
> 'field')" definition on ModelAdmin that automatically turns into a
> pre-configured deletion view.
>
> 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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Django Model Related Manager Enhancements
Recently I started working on a project (django-versions) to enable versioning of model data with Mercurial. In doing so, I came across the need to have access to more data about the relationships that Django Related Manager's create. For example, I wanted to be able to access the instance of the model that a related manager was called from, as well as the field names for the forward and reverse relationship. I have created an initial stab at adding this data to the related managers as well as tests to help explain what data these new attributes expose. I think it might be easiest to start the discussion from working code, but I was hoping to get feedback about the idea in general, as well as the implementation and attribute naming convention. http://github.com/nowells/django/compare/master...manager-enhancements Does this feature make sense? Do you feel that the data is exposed in the correct way? Are the tests sufficient? If so, I would be happy to give a stab at adding documentation, I just wanted to see if the concept stood the tests of scrutiny and utility. Thanks! Nowell Strite -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.
On Thu, Jul 8, 2010 at 7:11 AM, Graham Dumpleton wrote: > Can the following issue be revisited. > > http://code.djangoproject.com/ticket/8906 > > Conversation about it at: > > http://groups.google.com/group/django-users/browse_frm/thread/c457599caab6e87d/b70e1f56ad38f4cb > > This is another of those issues where Django isn't being particular > friendly to people who want to have relocatable sites. That is, where > in in one environment it may be mounted at root of site (eg. > development server), but where it has to be mounted at a sub URL in > another (eg. production). While I can see the issue you're referring to, I'm not sure I agree with your diagnosis. The site is perfectly relocatable. You just need multiple settings files -- in development, settings will contain LOGIN_URL='/login'; in production, settings will contain, LOGIN_URL='/mount_point/login'. When you move from development to production you almost always (in my experience) have a separate settings file, if only to separate database configurations, contact emails, etc. Adding a couple of extra settings for some values that actually *are* deployment specific doesn't seem especially onerous to me. >It also relates to the whole problem where a > web application, to be a well behaved WSGI citizen, should honour > SCRIPT_NAME setting as supplied by the server, and ensure that ways > are provided such that everything in the users code, including > configuration, urls or settings files, can be expressed relative to > the URL that the application is mounted at, thereby avoiding as much > as possible any need for a user to modify their code base when > deploying to a new environment at a different location in URL > namespace. > > Yes I know Jacob knocked it on the head last time, but this problem > keeps occasionally popping up because it seems not to be obvious that > people need to go and change stuff when mounting an application at a > sub URL. Personally, I see this as a case of explicit vs implicit. As currently defined, LOGIN_URL points to the login URL. Period. Under the proposed patch, the onus is on every possible script to ensure that the script prefix has been set correctly. WSGI will do this by default, but WSGI scripts aren't the only consumers of Django code. Personally, I spend almost as much time on background processing scripts for sites I support as I do on pages served via HTTP. So - is it more confusing to require that a settings file explcitly define the full URL, or to expect every script to configure itself to populate the magic SCRIPT_NAME variable? Jacob's position (and I find myself agreeing with this position) is that it's less confusing to require the settings file to be explicit. > The solution may be the introduction of a new section in the > Django documentation outlining all the things that need to be done > differently when mounting site at a sub URL. At least then people cant > complain the requirements aren't documented even if some may think it > is a silly requirement to begin with. :-) This is certainly worth doing. Submissions welcome. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #5373
On Thu, Jul 8, 2010 at 3:55 PM, Lachlan Musicman wrote: > Hola, > > I'm new to this dev thing, but I've done some work on ticket #5373 > > http://code.djangoproject.com/ticket/5373 Field label for a > ForeignKey not translated Thanks for pitching in! Hopefully I'll be able to give you enough feedback to progress this issue without scaring you off :-) > There are two different patches fixing the same problem - I've no idea > which is considered better. I don't like the late import on the first > patch (5373.2.patch), and the second may have unexpected consequences > (5373_related.py.diff ). > > I've also added a patch for tests/regressiontests/admin_inlines that > confirms that either patch works. I agree that the first patch (.2.patch) isn't the right approach -- isinstance checks are generally an indication that you're doing something wrong (or at least that you could be doing it better). However, I'm also concerned about unexpected consequences for the second patch. The obvious use case that you're breaking is if your ForeignKey manually defines a verbose_name. So - the next step is to make the tests more robust; you'll either prove that this isn't a problem, or you'll find the edge case that needs to be fixed. As for the tests themselves; a general rule for testing is to test as close to the source of the problem as possible. While I'm sure you *can* observe this problem in the admin, the fact that the fix doesn't involve any admin-specific code leads me to suspect that a better test would be at a lower level -- in this case, testing that foreign key fields return an appropriate verbose_name, and/or that ModelForms pick up a translated verbose name. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Problem with randrange in django/middleware/csrf.py
On Thu, Jul 8, 2010 at 8:39 AM, Russell Keith-Magee wrote: > On Thu, Jul 8, 2010 at 3:17 PM, DanEE wrote: >> Hello >> >> I posted this already in django-user. But because it is rather an >> internal django/python problem I will repost it here >> >> I experienced a strange behaviour with my django application when I >> wanted to deploy and test on my apache instance on my virtual server. >> I could successfully deploy my application but when I wanted to access >> any view the browser just took forever to load and it never showed the >> view. Accessing any non existing view gave the correct debug error >> view. >> >> After a long debugging session I could locate the problem to be in >> django/middleware/csrf.py. The call which actually took a very long >> time was the call to randrange(0, _MAX_CSRF_KEY). >> >> By playing around in a python session it seems that the call to the >> system randrange with random.SystemRandom().randrange(0, >> _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30 >> minutes) whereas a call to the "normal" randrange with randrange(0, >> _MAX_CSRF_KEY) happily returns the desired random number. >> The problem seems to depend on the size of the argument. >> random.SystemRandom().randrange happily returns the random values if >> the arguments are significantly lower. (I just deleted some number >> from the _MAX_CSRF_KEY and then it worked) >> >> I had to manully set the line "randrange = random.randrange" instead >> of the if/else logic which checks for the system random generator to >> make my app work on my virtual host. >> >> Now it seems that is not a django problem per se. But I am wondering >> what I should to with this kind of error as I had to manually fiddle >> around in the django-code to be able to successfully host my >> application. > > This is concerning, but I can't reproduce anything like it -- on every > platform I have available for testing, randrange() returns almost > instantaneously. > > If you call randrange from a normal python prompt, do you see the same > sort of delays? What about if you call randrange() in a simple Django > view? (i.e., start a new project with a simple view with no forms, and > call randrange() in that view?). Do you get similar lockups if you run > the CSRF tests in the Django test suite? > > If you can find the source of this problem, we will be only too happy > to fix it -- but until we can narrow down the specific set of > circumstances that causes the problem, there's not much we can do. > > 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-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > I'm unclear on why we even allow this code to work with the "default" random implementation, which is based on a Messrne Twister, and (quoting the Python docs here), "is completely unsuitable for cryptographic purposes". To my understand that's how we're trying to use it, and if I'm wrong here I wonder why we give preference to the system random at all? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Problem with randrange in django/middleware/csrf.py
On Thu, Jul 8, 2010 at 3:17 PM, DanEE wrote: > Hello > > I posted this already in django-user. But because it is rather an > internal django/python problem I will repost it here > > I experienced a strange behaviour with my django application when I > wanted to deploy and test on my apache instance on my virtual server. > I could successfully deploy my application but when I wanted to access > any view the browser just took forever to load and it never showed the > view. Accessing any non existing view gave the correct debug error > view. > > After a long debugging session I could locate the problem to be in > django/middleware/csrf.py. The call which actually took a very long > time was the call to randrange(0, _MAX_CSRF_KEY). > > By playing around in a python session it seems that the call to the > system randrange with random.SystemRandom().randrange(0, > _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30 > minutes) whereas a call to the "normal" randrange with randrange(0, > _MAX_CSRF_KEY) happily returns the desired random number. > The problem seems to depend on the size of the argument. > random.SystemRandom().randrange happily returns the random values if > the arguments are significantly lower. (I just deleted some number > from the _MAX_CSRF_KEY and then it worked) > > I had to manully set the line "randrange = random.randrange" instead > of the if/else logic which checks for the system random generator to > make my app work on my virtual host. > > Now it seems that is not a django problem per se. But I am wondering > what I should to with this kind of error as I had to manually fiddle > around in the django-code to be able to successfully host my > application. This is concerning, but I can't reproduce anything like it -- on every platform I have available for testing, randrange() returns almost instantaneously. If you call randrange from a normal python prompt, do you see the same sort of delays? What about if you call randrange() in a simple Django view? (i.e., start a new project with a simple view with no forms, and call randrange() in that view?). Do you get similar lockups if you run the CSRF tests in the Django test suite? If you can find the source of this problem, we will be only too happy to fix it -- but until we can narrow down the specific set of circumstances that causes the problem, there's not much we can do. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Ticket #5373
Hola, I'm new to this dev thing, but I've done some work on ticket #5373 http://code.djangoproject.com/ticket/5373 Field label for a ForeignKey not translated There are two different patches fixing the same problem - I've no idea which is considered better. I don't like the late import on the first patch (5373.2.patch), and the second may have unexpected consequences (5373_related.py.diff ). I've also added a patch for tests/regressiontests/admin_inlines that confirms that either patch works. I'm not sure what to do next? cheers L. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Problem with randrange in django/middleware/csrf.py
Hello I posted this already in django-user. But because it is rather an internal django/python problem I will repost it here I experienced a strange behaviour with my django application when I wanted to deploy and test on my apache instance on my virtual server. I could successfully deploy my application but when I wanted to access any view the browser just took forever to load and it never showed the view. Accessing any non existing view gave the correct debug error view. After a long debugging session I could locate the problem to be in django/middleware/csrf.py. The call which actually took a very long time was the call to randrange(0, _MAX_CSRF_KEY). By playing around in a python session it seems that the call to the system randrange with random.SystemRandom().randrange(0, _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30 minutes) whereas a call to the "normal" randrange with randrange(0, _MAX_CSRF_KEY) happily returns the desired random number. The problem seems to depend on the size of the argument. random.SystemRandom().randrange happily returns the random values if the arguments are significantly lower. (I just deleted some number from the _MAX_CSRF_KEY and then it worked) I had to manully set the line "randrange = random.randrange" instead of the if/else logic which checks for the system random generator to make my app work on my virtual host. Now it seems that is not a django problem per se. But I am wondering what I should to with this kind of error as I had to manually fiddle around in the django-code to be able to successfully host my application. In my virtual host I use apache 2.2.15 with python 2.6.5, mod_wsgi 3.2 and django 1.2.1 Thanks in advance. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
