Re: Ticket ping 3182
Hi Jacob, I understand where you are coming from. However, I do not think I am stepping out of bounds. The patch is self-contained, has proper documentation, has been accepted, has been tested, is clearly labeled ready for check in, has been reviewed and supported by a number of developers, and this all happened months ago. I have only mentioned this ticket twice in the last 1/3 of a year. Moreover, see Malcolm's comment below: Malcolm Tredinnick (March 8) > I hadn't realised it was two months old now. It will get handled > eventually and maybe fairly soon, since you've pointed out that it was > getting a little old despite being ready. There really isn't a problem > with people asking about tickets that appear to just be lying around > with no action for no clear reason, like this one, within reason. I understand that we all work on open source as a hobby. I would just like to make sure that at the next bug-squashing session by a developer with commit rights, this patch is checked in. Thank you, j On 4/23/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > > On 4/23/07, Joseph Perla <[EMAIL PROTECTED]> wrote: > > Ping: simple, ready ticket #3182 is at 4 months and counting: > > http://code.djangoproject.com/ticket/3182 . Thank you, > > Please don't do this. It's frustrating, annoying, and very impolite. > Please remember that everyone who works on Django does so as a hobby > and in his or her spare time. > > We appreciate your patience, > > Jacob > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Ticket ping 3182
Ping: simple, ready ticket #3182 is at 4 months and counting: http://code.djangoproject.com/ticket/3182 . Thank you, j --~--~-~--~~~---~--~~ 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: Are we dropping auto_now and auto_now_add for 1.0?
+1. Follows DRY. An AutoDateTimeField is very common. j On 4/6/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > > > seems like it should be as easy as a function in contrib somewhere: > [snip] > > Another option is a trivial field subclass:: > > class AutoDateTimeField(models.DateTimeField): > def pre_save(self, model_instance, add): > return datetime.datetime.now() > > Jacob > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Upcoming Django release, and the future
Thanks for that thoughtful response. Let me just point to the specific one I've been hoping to get through for the past couple months, very small in scope and complete, that should be checked in: http://code.djangoproject.com/ticket/3182 . I assumed that since this simple one hasn't gone through, then others also were floating stagnant. j On 3/6/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Tue, 2007-03-06 at 17:39 -0500, Joseph Perla wrote: > > They don't need to be in 0.96, but can someone at least check in the > > tickets already decided as ready for check-in? > > > http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&stage=Ready+for+checkin > > Some of these have been complete and ready for 2 months. > > Unsurprisingly, that particular report does get checked very regularly. > In our effort to streamline the triage project, it is important to > realise that some slightly different states have been collapsed into > each other and "ready for checkin" does not mean "can be checked in > without further thought". It really means that the patch looks > reasonable (to the traigers) and reasonable tests and docs are in > available, if appropriate. > > A bunch of them have subsequently been notated as waiting until after > 0.96 or they are for another branch. Some others are not no-brainers, so > require some thought and for a committer to have a block of time > available to drop them in. Note that a lot of tickets from that stage > have been committed over the past four weeks or so. So don't just look > at the number of tickets. From a quick scan, I couldn't find any that > have been marked as "ready" for over 2 months that are not waiting on > something else. > > 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: Upcoming Django release, and the future
They don't need to be in 0.96, but can someone at least check in the tickets already decided as ready for check-in? http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&stage=Ready+for+checkin Some of these have been complete and ready for 2 months. j On 3/6/07, Simon G. <[EMAIL PROTECTED]> wrote: > > > #3625 ( http://code.djangoproject.com/ticket/3625 ) looks like a good > candidate - it's a Python 2.3 issue with rsplit in the test system. > It's been reported three times, so people are definitely running into > it. > > 3625 has a simple patch to fix this. > > --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 -~--~~~~--~~--~--~---
cache.get_or_set()
Along the lines of get_or_create(), does it make sense to implement a
get_or_set() function for quick caches?
It can be used in this way:
from django.core.cache import cache
...
big_list = cache.get_or_set('big_list', lambda: BigItems.objects.all(),
60 * 60)
to retrieve from cache or, if not in the cache, to cache the data for one
hour in just one line of code.
Implement this in django.core.cache.backends.base as
def get_or_set(self, key, value_function, timeout=None):
_cached = cache.get(key)
if not _cached:
_cached = value_function()
cache.set(key, _cached, timeout)
return _cached
It looks a little funny with the lambda function, but I think it would be
useful. What do you think?
Thanks,
j
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
extending the user model
Have you already decided on a simple, fast, non-deprecated, standard way of extending the User model? Last I remember, a ForeignKey(unique=True) was recommended, but that was kind of a hack due to the deprecation of the OneToOneField. j --~--~-~--~~~---~--~~ 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: get_or_none QuerySet method
Also, here's the pseudo-ish code for it: def update_or_create( --same arguments as get_or_create()-- ): object, created = Class.objects.get_or_create( --args above-- ) if not created: object.__dict__.update(defaults) object.save() return object Well, Class is self or this or whatever it is in python/djangomanagers code. I'm also not sure how to do the crazy **kwargs stuff. The rest is clear: if you didn't create it, just update it, save it, and return. j On 12/20/06, Joseph Perla <[EMAIL PROTECTED]> wrote: There should also be an update_or_create() function. I often find myself get_or_creating, then updating the object's dict if it wasnt just created, then saving. This can easily be expressed more clearly in one line with this function. j On 12/20/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > > > SmileyChris wrote: > > On Dec 19, 11:08 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > > > something like this: > > > > > > user = User.objects.get (pk=user_id, default=None) > > > > Except this would break (or at least limit the functionality of) > > objects which use "default" as a field name. > > Of course, this didn't stop get_or_create(), which uses "defaults" as a > parameter. If you had an object with an attribute named "default" then > you could still do something like: > > obj = MyModel.objects.get(default__exact=42, default=None) > > But get_or_create() was new functionality and this would be changing > existing functionality. If that is unacceptable, then maybe a > get_or_default() that optionally takes the "default" parameter, using > None if no "default" specified. > > So... > MyModel.objects.get_or_default (pk=1) > would be equivalent to > MyModel.objects.get_or_default(pk=1, default=None) > > > > > > --~--~-~--~~~---~--~~ 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: get_or_none QuerySet method
There should also be an update_or_create() function. I often find myself get_or_creating, then updating the object's dict if it wasnt just created, then saving. This can easily be expressed more clearly in one line with this function. j On 12/20/06, Gary Wilson <[EMAIL PROTECTED]> wrote: SmileyChris wrote: > On Dec 19, 11:08 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > > something like this: > > > > user = User.objects.get(pk=user_id, default=None) > > Except this would break (or at least limit the functionality of) > objects which use "default" as a field name. Of course, this didn't stop get_or_create(), which uses "defaults" as a parameter. If you had an object with an attribute named "default" then you could still do something like: obj = MyModel.objects.get(default__exact=42, default=None) But get_or_create() was new functionality and this would be changing existing functionality. If that is unacceptable, then maybe a get_or_default() that optionally takes the "default" parameter, using None if no "default" specified. So... MyModel.objects.get_or_default(pk=1) would be equivalent to MyModel.objects.get_or_default(pk=1, default=None) > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
