Re: #6735 -- Class based generic views: call for comment
On 3 October 2010 04:44, Russell Keith-Magee wrote: > 2010/10/3 Łukasz Rekucki : >> On 2 October 2010 12:32, Russell Keith-Magee wrote: >>> 2010/10/2 Łukasz Rekucki : On 2 October 2010 10:34, Russell Keith-Magee wrote: > >> 3) How do we make this shared settings immutable between requests >> (this has nothing to do with thread-safety) ? > > It's entirely about thread safety; if you've got code modifying any > instance variable, and those instance variables don't have isolated > state between class instances, thread safety will be the first > manifestation. What I meant is that you don't need multi-threaded environment to make the problem occur - just 2 sequential requests. > >> Another way is to keep this settings as class attributes and assume >> the user is sane enough not to share mutable object between class >> instances. > > ... and that's a *really* big assumption, and one that has potential > to bite users on the butt really easily -- especially new developers. IMHO, it falls into the same class of assumptions as "people won't use mutable objects as default arguments to functions". It's true that it's a common mistake among developers new to OOP in Python. But it's a Python-specific problem, not Django-specific. def with_args(view_cls, **kwargs): return type(view_cls.__name__, (view_cls,), kwargs) # in urls.py: (r'^somepath', with_args(MyView, option=False)), # or even (r'^somepath', MyView.with(option=False)), >>> >>> I can't deny this would work. It just doesn't feel very Pythonic to me. >> >> I don't share your feeling about this. Django already uses a similar >> idiom in ModelForms - you pass in a base form, some extra options and >> get a new subclass. Also, I would consider this as a shortcut for >> advanced users and advice beginners to use subclassing. > > I'm not sure I see the comparison. ModelForms are declared using a > metaclass; instances are defined in the normal way that every class is > defined. There is a modelform_factory() et al, but they're not class > methods; they're standalone functions that can be used to construct > new classes. > > MyView.with(xxx) -- a class method that is a class factory -- isn't a > construct with precedent in Django's codebase AFAICT. We can leave this as a standalone function if that changes anything. Another common pattern in use is an instance method that is a instance factory. Going up one level seems natural. PS. I'll try to put up some code today, to represent this approach. Is it okay to add this to the wiki page ? -- Łukasz Rekucki -- 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: #6735 -- Class based generic views: call for comment
On 3 October 2010 06:12, Ian Lewis wrote: > Flask seems to do it the callable singleton way: > > http://flask.pocoo.org/docs/patterns/lazyloading/ > I never used Flask, so I might be missing something, but I don't see a singleton view instance here - just a proxy, that imports a function on first use. Although functions are singleton by their nature. > Is there any precedent in other frameworks for doing it the singleton > way? Talking a bit about how other frameworks/libraries do this might > be a good idea to figure out what Joe User is likely to do. +1 on having a compare table between other frameworks. -- Łukasz Rekucki -- 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: #6735 -- Class based generic views: call for comment
Hi,
first of all, I'd like to say that I fully agree that the final
solution has to be thread-safe and has to support storing state on
self.
On Oct 2, 12:32 pm, Russell Keith-Magee
wrote:
> 2010/10/2 Łukasz Rekucki :
> > Now you lost me. If we are discouraging people from using arguments to
> > __init__, why does the page list "You can't use arguments to init() to
> > instantiate a class view" as a drawback of the __new__ based approach
> > ?
>
> The difference is that __new__ doesn't *ever* allow for initialization
> arguments -- there is no way to pass an argument in. An "arguments
> disabled by default" __init__+copy implementation allows arguments as
> an opt-in.
Not 100% true. I suppose the main use-case of initialization arguments
is to have them in urlpatterns, right? You can still do that:
(r'^path$', 'MyView', {'option1': value1, 'option2': ...}),
The other use-case is to pass initialization arguments in your
views.py, but that can easily be replaced with subclassing:
class MyView(View):
option1 = value1
...
Indeed, this doesn't completely solve the problem of shared state
because value1 etc. will be shared, but neither does any of the other
solutions. However, with __new__ any *internal* state you store during
__init__ (e.g., self.state = [1, 2]) will be thread-safe (you can
later safely do self.state.append(3)) and that's IMHO an important
advantage over the __init__+copy() approach.
Independent of the approach, passing mutable arguments to __init__
isn't such a huge issue if you think of those mutable arguments as
*globally* constructed. Global mutable objects just aren't thread-safe
and that's one of the first things you have to learn when working with
multi-threaded code. So, even the __init__+copy() approach IMHO
doesn't make this problem really dramatic. After all, you're
constructing a *global* object. The default assumption is that it
"obviously" can't be thread-safe. To me, it's actually the other way
around: How the heck would I even know just by looking at a views.py
(i.e. without reading the documentation) that the *global* view
**instance** (!) is in fact thread-safe because it copies itself?
> There's also the wierd behavior that __new__ requires. Consider:
>
> x = MyView()
>
> What is x? If you use the __init__+copy approach, x is an instance of
> MyView. If you use __new__, x is a HttpResponse. It's a minor thing,
> to be sure, but this is a bit of a code smell to me.
I agree with Łukasz that this can be seen as a view factory. At least,
this is not much more magical than having non-obvious thread-safety
due to copy(). None of the solutions are perfect, but IMHO the thread-
safety advantages of the __new__ approach (i.e., internal state
created in __init__ is thread-safe) outweigh this minor detail because
bugs due to thread-safety issues are harder to track down.
Bye,
Waldemar Kornewald
--
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: rethinking raw_id_fields
On 30 Set, 07:34, "subs...@gmail.com" wrote: > Hello all, > I was browsing the tickets and saw a few of them nagging about some > restrictions to raw_id_fields. Since my first Django installation, a couple of years ago, I fixed and used this patch: http://code.djangoproject.com/ticket/7028 I see that mtrs wrote an improved version. I also see that at each new Django release a fixed version comes up after few days (if not few hours). I think it is a huge improvement in user experience and I never fully understood why it always missed each django release since 1.0. Now I see that another improved patch comes up concerning also M2M: http://code.djangoproject.com/ticket/13221 Well, M2M and raw_id_fields are a big player in wonderful admin contrib with a poor interface: why do not improve them? Ciao. Marco. -- 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.
#6903 -- Go back to old change_list view after hitting save
I think that #6903 ticket http://code.djangoproject.com/ticket/6903 (together with http://code.djangoproject.com/ticket/12241) should be considered to be in 1.3 release. Every single person I know that use admin without this patch asks for this functionality. On 3/23/2009 Jacob said: This has gone around quite a bit, but it's still not quite perfect. It's really a hard problem, unfortunately, and we're out of time to put it in 1.1. On 2/23/2010 ubernostrum said: 1.2 is feature-frozen, moving this feature request off the milestone. I understand that release 1.3 is to be devoted to this kind of ticket. Am I right? Ciao. Marco. -- 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: #6735 -- Class based generic views: call for comment
2010/10/3 Łukasz Rekucki : > On 3 October 2010 04:44, Russell Keith-Magee wrote: >> 2010/10/3 Łukasz Rekucki : > def with_args(view_cls, **kwargs): > return type(view_cls.__name__, (view_cls,), kwargs) > > # in urls.py: > > (r'^somepath', with_args(MyView, option=False)), > # or even > (r'^somepath', MyView.with(option=False)), I can't deny this would work. It just doesn't feel very Pythonic to me. >>> >>> I don't share your feeling about this. Django already uses a similar >>> idiom in ModelForms - you pass in a base form, some extra options and >>> get a new subclass. Also, I would consider this as a shortcut for >>> advanced users and advice beginners to use subclassing. >> >> I'm not sure I see the comparison. ModelForms are declared using a >> metaclass; instances are defined in the normal way that every class is >> defined. There is a modelform_factory() et al, but they're not class >> methods; they're standalone functions that can be used to construct >> new classes. >> >> MyView.with(xxx) -- a class method that is a class factory -- isn't a >> construct with precedent in Django's codebase AFAICT. > > We can leave this as a standalone function if that changes anything. > Another common pattern in use is an instance method that is a instance > factory. Going up one level seems natural. > > PS. I'll try to put up some code today, to represent this approach. Is > it okay to add this to the wiki page ? Feel free. Even if we don't end up adopting your proposal, it's helpful for future generations to know that it *was* proposed (and if it wasn't accepted, why it wasn't accepted). 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: #6735 -- Class based generic views: call for comment
On Sun, Oct 3, 2010 at 12:12 PM, Ian Lewis wrote: > On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee > wrote: > While I'm in the "one singleton view instance is best" camp and think > that storing some state on the request and some on the view is a bit > gross, I understand Russell's arguments. New users are simply going to > save stuff on self no matter how much we complain, document etc. It's > simply a reality that likely can't be helped much. > > Other frameworks seem have View/Handler instances per request, such as > appengine's webapp so there is some precedent for creating an instance > per request. > > http://code.google.com/appengine/docs/python/gettingstarted/handlingforms.html I don't think you'll find any argument that having an instance per request would solve all the problems that this thread has described. The issue is how to declare a view that is able to be instantiated on a instance-per-request basis while simultaneously allowing decorators to be easily wrapped around that 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: rethinking raw_id_fields
On Sun, Oct 3, 2010 at 5:58 PM, Marcob wrote: > On 30 Set, 07:34, "subs...@gmail.com" wrote: >> Hello all, >> I was browsing the tickets and saw a few of them nagging about some >> restrictions to raw_id_fields. > > Since my first Django installation, a couple of years ago, I fixed and > used this patch: > http://code.djangoproject.com/ticket/7028 > > I see that mtrs wrote an improved version. > I also see that at each new Django release a fixed version comes up > after few days (if not few hours). > I think it is a huge improvement in user experience and I never fully > understood why it always missed each django release since 1.0. The reason that #7028 hasn't been included is the same reason that any other ticket hasn't been included -- time. We have finite resources. We can only fix a certain number of tickets if we want to keep a timely release schedule. As good as the ideas in #7028 are, they're not absolutely essential - we've lived without the feature for a long time, and there's no data loss at stake. As a result, it's been sacrificed in the interests of other tickets. #7028 is also subject to another major impediment -- it's dealing with an area that requires front-end expertise. From my personal perspective, I'm hesitant to get involved in anything touching the front end out of lack of knowledge. I don't profess to being a UX expert, and I'm certainly not an expert at CSS. I don't have the facilities to do rigorous testing on any platform other than OSX. So - even thought this ticket has been on my radar for a while, the barrier for entry for me is higher than it is for other tickets. 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: #6903 -- Go back to old change_list view after hitting save
On Sun, Oct 3, 2010 at 6:09 PM, Marcob wrote: > I think that #6903 ticket http://code.djangoproject.com/ticket/6903 > (together with http://code.djangoproject.com/ticket/12241) should be > considered to be in 1.3 release. > Every single person I know that use admin without this patch asks for > this functionality. > On 3/23/2009 Jacob said: This has gone around quite a bit, but it's > still not quite perfect. It's really a hard problem, unfortunately, > and we're out of time to put it in 1.1. > On 2/23/2010 ubernostrum said: 1.2 is feature-frozen, moving this > feature request off the milestone. > I understand that release 1.3 is to be devoted to this kind of ticket. > Am I right? That's the intention. Right at the moment, my focus is on the small number of big ticket items that we're trying to get in for 1.3 (logging, unittest2 support, and class-based generic views... although that last one is looking more unlikely by the day). Once those big features are finished, I'll be focussing on closing as many RFC patches as I can, including any feature requests (such as admin improvements) that have been lingering for a while. 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: #6735 -- Class based generic views: call for comment
On Oct 3, 6:12 am, Ian Lewis wrote: > Other frameworks seem have View/Handler instances per request, such as > appengine's webapp so there is some precedent for creating an instance > per request. > > http://code.google.com/appengine/docs/python/gettingstarted/handlingf... > > Flask seems to do it the callable singleton way: > > http://flask.pocoo.org/docs/patterns/lazyloading/ > > Is there any precedent in other frameworks for doing it the singleton > way? Talking a bit about how other frameworks/libraries do this might > be a good idea to figure out what Joe User is likely to do. >From a brief look at Pylons, it also creates an instance per request: "These requests result in a new instance of the WSGIController being created, which is then called with the dict options from the Routes match." (http://pylonshq.com/docs/en/1.0/controllers/). No mentioning about setting state on self and no __init__ on controllers (even the base WSGIController doesn't define __init__). George -- 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: #6735 -- Class based generic views: call for comment
On Oct 3, 4:20 am, Russell Keith-Magee wrote: > On Sat, Oct 2, 2010 at 8:01 PM, Carl Meyer wrote: > >> We could even wrap the "no args to __init__" error check in a method > >> that enables it to be overridden and silenced in a subclass; that way, > >> introducing the potentially un-threadsafe behavior would need to be an > > > Again, arguments to __init__ are not the issue. What would have to be > > checked is any assignment to self that takes place in __init__. How do > > you propose to check that? > > I don't. You've got me -- in my haste to propose an idea, I hadn't > considered assigning state in the constructor. FWIW with the proposal of overriding __setattr__ to do setattr(self.request.state, attr, value) you can check that; at __init__ there is no self.request yet. George -- 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: #6735 -- Class based generic views: call for comment
2010/10/3 Łukasz Rekucki : > On 3 October 2010 06:12, Ian Lewis wrote: >> Flask seems to do it the callable singleton way: >> >> http://flask.pocoo.org/docs/patterns/lazyloading/ >> > I never used Flask, so I might be missing something, but I don't see a > singleton view instance here - just a proxy, that imports a function > on first use. Although functions are singleton by their nature. I'm not a flask expert either but under "Loading Late" there is a LazyView which I believe is just a callable object. And later under that he adds a LazyView instance to a url rule so I think it's simply a "view is a callable" pattern. -- Ian http://www.ianlewis.org/ -- 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: #6735 -- Class based generic views: call for comment
On Sun, Oct 3, 2010 at 8:02 PM, Russell Keith-Magee wrote: >> Other frameworks seem have View/Handler instances per request, such as >> appengine's webapp so there is some precedent for creating an instance >> per request. >> >> http://code.google.com/appengine/docs/python/gettingstarted/handlingforms.html > > I don't think you'll find any argument that having an instance per > request would solve all the problems that this thread has described. > The issue is how to declare a view that is able to be instantiated on > a instance-per-request basis while simultaneously allowing decorators > to be easily wrapped around that view. I was sort of referring to the __new__() method you are describing to allow state to be stored on self. A class instance that can be wrapped by a decorator to me is simply a callable instance and people are just going to have to get used to the idea that self can't be modified safely. Anything else is a bad hack that will likely cause even more headaches down the road. That said, even Django itself has code that falls victim to storing state on self in a callable class based view (See: django.contrib.formtools.preview.FormPreview). So I can imagine many people will be confused, but it is what it is. -- Ian http://www.ianlewis.org/ -- 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: be localflavor Belgium
Am I supposed to commit the patch? I don't think I have the privileges to do that. Laurent On Sep 30, 5:35 pm, Russell Keith-Magee wrote: > On Fri, Oct 1, 2010 at 6:15 AM, Laurent Luce wrote: > > I updated the be localflavor patch to use unit tests instead of > > doctests as requested. Can you check if this is what you want. There > > was no unit tests in regressiontests/forms/localflavor/ so I am not > > 100% sure I did what is expected. I took a look at the ones in > > regressiontests/forms as models. > > The patch looks good, so I've just bumped the ticket to ready for checkin. > > Thanks for the contribution! > > 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: be localflavor Belgium
On 3 October 2010 20:53, Laurent Luce wrote: > Am I supposed to commit the patch? I don't think I have the privileges > to do that. No, only core developers can commit changes. The patch is marked RFC and has milestone 1.3, so it's pretty sure it won't be forgotten. I suspect that because Russel reviewed the patch, some other core developer needs to commit it (but that's just a wild guess). So sit back, relax and send a friendly reminder some time before feature freeze on October 18[1]. [1]: http://www.djangoproject.com/weblog/2010/sep/30/django-1_3-release-schedule/ -- Łukasz Rekucki -- 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: Proposal: Meta.required_together
Doesn't this do what you want?:
class MyModel(models.Model):
weight = ..
height = ...
width = ...
length = ...
def clean(self):
from django.core.exceptions import ValidationError
if self.weight or self.height or self.width or self.length and
not (self.weight and self.height and self.width and
self.length):
raise ValidationError("Sorry, in order to use weight, height,
width, or"
" length, you have to include them all.")
def save(self, *args, **kwargs):
self.clean()
super(MyModel, self).save(*args, **kwargs)
Of course it does require you to write a little more code, but it is
possible.
Besides, does the required_together mean that all fields are required when
one is filled out, or that some are required when the first is filled out?
What I mean is that there are many possibilities for validating a model, and
at the moment we have quite some good tools for them. Adding another Meta
option for a small portion of the cases doesn't seem so necessary to me...
Anyway, that's just my 2c.
TinO
On Sun, Oct 3, 2010 at 05:58, LookMa NoSQL wrote:
> +1 on proposal (for what it matters).
>
> Tina, where did you see that Django does that? The docs link you sent
> shows regular model validation. What Mamayo is looking for, I think,
> is the ability to add a Meta option to a model that says
> required_together=({fields: ('weight', 'height', 'width', 'length'),
> error_message: "Sorry, in order to use weight, height, width, or
> length, you have to include them all."}). At least I think that's what
> he means. This would help me too.
>
> On Oct 2, 10:17 am, TiNo wrote:
> > Hi,
> >
> > Isn't this covered by model validation [1]?
> >
> > Tino
> >
> > [1]
> http://docs.djangoproject.com/en/dev/ref/models/instances/#validating...
> >
> > On Fri, Oct 1, 2010 at 15:59, hejsan wrote:
> > > Hi.
> > > I just filed a feature request on the same or similar issue, and this
> > > thread was brought to my attention:
> > >http://code.djangoproject.com/ticket/14347
> >
> > > Basically the usecase is this:
> > > Very often we have a "Published" field on our models (or "Published
> > > date" or "Published status" etc..) It would be very nice to be able to
> > > allow people to save instances without all the required fields being
> > > filled in IF the article or whathaveyou is not published yet.
> >
> > > My suggestion was to allow the "required" field on the form field to
> > > take a callable instead of a boolean.
> > > In this callable we could check whether some other fields are filled
> > > out or whatever we want.
> >
> > > This would be a very handy feature for a very common problem.
> >
> > > best,
> > > Hejsan
> >
> > > On Sep 27, 7:34 am, Yo-Yo Ma wrote:
> > > > Thanks, David. I've read some about the "Custom validation error on
> > > > unique_together" ticket. I imagine that if people want customization
> > > > there, required_together would need the same. The only idea I have
> > > > that seems to work for both situations is:
> >
> > > > required_together = (('weight', 'height', 'You must provide a weight
> > > > and height, if you intend to use either.'),)
> >
> > > > unique_together = (('account', 'sku', 'This sku is already in use by
> > > > your company.'),)
> >
> > > > On Sep 27, 1:22 am, "David P. Novakovic"
> > > > wrote:
> >
> > > > > Is it? I read this as different to anything in the ORM.
> >
> > > > > This is about conditionally requiring a second field if one is
> filled
> > > > > out. Normally it would be done at the JS level.
> >
> > > > > I think it's a good idea, assuming I haven't missed something that
> > > > > already does this.
> >
> > > > > I can't help thinking this is part of a much larger problem though.
> > > > > That problem is multifield validation. I think we'd have to address
> > > > > that issue first before working on this specific case that is
> probably
> > > > > the simplest.
> >
> > > > > Maybe this has been considered before, but was dropped because the
> > > > > idea is too hard to encapsulate in a simple Meta style option?
> >
> > > > > David
> >
> > > > > On Mon, Sep 27, 2010 at 5:18 PM, Florian Apolloner
> >
> > > > > wrote:
> > > > > > Please post usage questions to the users list. This is already
> doable
> > > > > > with model validation.
> >
> > > > > > Florian
> >
> > > > > > --
> > > > > > 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 athttp://
> > > groups.google.com/group/django-developers?hl=en.
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Django developers" group.
> > > To post to this group,
variable view name in url tag
I know this has come up over the last few years[1] and people are mixed on the action that should be taken. I would like to bring it up again as it has bitten me a few time lately. I seems the biggest concern is backwards compatibility of the syntax. I feel that should not stop us from fixing something that is an annoying wart and also keeping the syntax in line with how other tags work. In this thread[2] Malcolm suggested introducing a new tag and depreciating the old one which could be done by bringing something like[3] into core. Im not huge on the idea of have 2 tags that do the same thing only with slightly different syntax, but if that is the cleanest upgrade I'm +1. I think this can still be done in a backwards compatible way[4], unless I'm missing something. I hope this doesn't turn into a shed planing session, thanks! [1] http://code.djangoproject.com/ticket/7917 [2] http://groups.google.com/group/django-developers/browse_thread/thread/ac2b1ea4555c0a62/21cf9b1aed6d11e0?lnk=gst&q=url+tag+viewname#21cf9b1aed6d11e0 [3] http://github.com/ulope/django-reversetag [4] http://pastebin.com/FhZSFQdn -- 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: be localflavor Belgium
2010/10/4 Łukasz Rekucki : > On 3 October 2010 20:53, Laurent Luce wrote: >> Am I supposed to commit the patch? I don't think I have the privileges >> to do that. > > No, only core developers can commit changes. The patch is marked RFC > and has milestone 1.3, so it's pretty sure it won't be forgotten. I > suspect that because Russel reviewed the patch, some other core > developer needs to commit it (but that's just a wild guess). So sit > back, relax and send a friendly reminder some time before feature > freeze on October 18[1]. No - I'll commit it when I have the time. It's just that we're focusing on major features right now, so minor feature additions are taking a back seat. Once October 18th and the feature freeze hits, I wlll commit -- or another core developer will if they beat me to it. So - Laurent - you've done everything right (and thanks for the patch); in a couple of weeks your code should be in trunk. 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: variable view name in url tag
On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant wrote:
> I know this has come up over the last few years[1] and people are
> mixed on the action that should be taken. I would like to bring it up
> again as it has bitten me a few time lately.
>
> I seems the biggest concern is backwards compatibility of the syntax.
> I feel that should not stop us from fixing something that is an
> annoying wart and also keeping the syntax in line with how other tags
> work.
>
> In this thread[2] Malcolm suggested introducing a new tag and
> depreciating the old one which could be done by bringing something
> like[3] into core. Im not huge on the idea of have 2 tags that do the
> same thing only with slightly different syntax, but if that is the
> cleanest upgrade I'm +1.
>
> I think this can still be done in a backwards compatible way[4],
> unless I'm missing something.
This isn't backwards compatible in every case. Consider:
{% url foo %}
foo could be:
- A URL pattern name
- A variable in the context
- A variable in the context *and* a URL pattern name
It's the third case where your proposal has problems. Under the
current implementation, it's *always* interpreted as a URL pattern
name. Under your proposal, the context variable would take precedence
in the third case.
It's also backwards incompatible in the second case (though not in a
way that matters as much): if you have an existing template that
raises an error, but you have a context variable that matches the name
you've used, your implementation *won't* raise an error.
However, there is another way (an alternative to adding a parallel tag) :-)
An interesting quirk/feature of Django's template language: if you
register template tags with the same name, the last registered name
wins.
This means we can define a "future_url" template tag library that
registers a {% url %} template tag. Then, in your code, you can say:
{% load future_url %}
{% url "url-name" foo=bar %}
and get the new behavior. Then, we can put PendingDeprecationWarnings
in the old {% url %} tag definition, upgraded to DeprecationWarnings
in 1.4. Then, in 1.5, we switch the behavior over and start
deprecating the future_url tag library.
I'm completely in favor of making this change; the behavior of the url
tag has always been an annoying wart, and it would be good to clean it
up.
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: variable view name in url tag
On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant wrote:
>> I know this has come up over the last few years[1] and people are
>> mixed on the action that should be taken. I would like to bring it up
>> again as it has bitten me a few time lately.
>>
>> I seems the biggest concern is backwards compatibility of the syntax.
>> I feel that should not stop us from fixing something that is an
>> annoying wart and also keeping the syntax in line with how other tags
>> work.
>>
>> In this thread[2] Malcolm suggested introducing a new tag and
>> depreciating the old one which could be done by bringing something
>> like[3] into core. Im not huge on the idea of have 2 tags that do the
>> same thing only with slightly different syntax, but if that is the
>> cleanest upgrade I'm +1.
>>
>> I think this can still be done in a backwards compatible way[4],
>> unless I'm missing something.
>
> This isn't backwards compatible in every case. Consider:
>
> {% url foo %}
>
> foo could be:
> - A URL pattern name
> - A variable in the context
> - A variable in the context *and* a URL pattern name
>
> It's the third case where your proposal has problems. Under the
> current implementation, it's *always* interpreted as a URL pattern
> name. Under your proposal, the context variable would take precedence
> in the third case.
>
> It's also backwards incompatible in the second case (though not in a
> way that matters as much): if you have an existing template that
> raises an error, but you have a context variable that matches the name
> you've used, your implementation *won't* raise an error.
>
> However, there is another way (an alternative to adding a parallel tag) :-)
>
> An interesting quirk/feature of Django's template language: if you
> register template tags with the same name, the last registered name
> wins.
>
> This means we can define a "future_url" template tag library that
> registers a {% url %} template tag. Then, in your code, you can say:
>
> {% load future_url %}
> {% url "url-name" foo=bar %}
>
> and get the new behavior. Then, we can put PendingDeprecationWarnings
> in the old {% url %} tag definition, upgraded to DeprecationWarnings
> in 1.4. Then, in 1.5, we switch the behavior over and start
> deprecating the future_url tag library.
>
> I'm completely in favor of making this change; the behavior of the url
> tag has always been an annoying wart, and it would be good to clean it
> up.
>
> Yours,
> Russ Magee %-)
Thanks for the feedback Russ. I know it couldn't be that straight forward. I'll
work on a patch this week that
implements what you mentioned. Would it be best to start a new ticket or
re-open the old ticket?
> --
> 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.
>
--
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: Proposal: Meta.required_together
Tino, are you joking? Did you even bother to read the OP's proposal. I
think there is a real lack of patience when you spend the time writing
what the OP has written without even reading it, just to try to
dismiss it.
OP:
>def clean(self):
>if any((self.weight, self.height))
>if not all((self.weight, self.height))
>raise ValidationError("Uh oh!")
On Oct 3, 2:08 pm, TiNo wrote:
> Doesn't this do what you want?:
>
> class MyModel(models.Model):
> weight = ..
> height = ...
> width = ...
> length = ...
>
> def clean(self):
> from django.core.exceptions import ValidationError
> if self.weight or self.height or self.width or self.length and
> not (self.weight and self.height and self.width and
> self.length):
> raise ValidationError("Sorry, in order to use weight, height,
> width, or"
> " length, you have to include them all.")
>
> def save(self, *args, **kwargs):
> self.clean()
> super(MyModel, self).save(*args, **kwargs)
>
> Of course it does require you to write a little more code, but it is
> possible.
>
> Besides, does the required_together mean that all fields are required when
> one is filled out, or that some are required when the first is filled out?
> What I mean is that there are many possibilities for validating a model, and
> at the moment we have quite some good tools for them. Adding another Meta
> option for a small portion of the cases doesn't seem so necessary to me...
>
> Anyway, that's just my 2c.
>
> TinO
>
> On Sun, Oct 3, 2010 at 05:58, LookMa NoSQL wrote:
> > +1 on proposal (for what it matters).
>
> > Tina, where did you see that Django does that? The docs link you sent
> > shows regular model validation. What Mamayo is looking for, I think,
> > is the ability to add a Meta option to a model that says
> > required_together=({fields: ('weight', 'height', 'width', 'length'),
> > error_message: "Sorry, in order to use weight, height, width, or
> > length, you have to include them all."}). At least I think that's what
> > he means. This would help me too.
>
> > On Oct 2, 10:17 am, TiNo wrote:
> > > Hi,
>
> > > Isn't this covered by model validation [1]?
>
> > > Tino
>
> > > [1]
> >http://docs.djangoproject.com/en/dev/ref/models/instances/#validating...
>
> > > On Fri, Oct 1, 2010 at 15:59, hejsan wrote:
> > > > Hi.
> > > > I just filed a feature request on the same or similar issue, and this
> > > > thread was brought to my attention:
> > > >http://code.djangoproject.com/ticket/14347
>
> > > > Basically the usecase is this:
> > > > Very often we have a "Published" field on our models (or "Published
> > > > date" or "Published status" etc..) It would be very nice to be able to
> > > > allow people to save instances without all the required fields being
> > > > filled in IF the article or whathaveyou is not published yet.
>
> > > > My suggestion was to allow the "required" field on the form field to
> > > > take a callable instead of a boolean.
> > > > In this callable we could check whether some other fields are filled
> > > > out or whatever we want.
>
> > > > This would be a very handy feature for a very common problem.
>
> > > > best,
> > > > Hejsan
>
> > > > On Sep 27, 7:34 am, Yo-Yo Ma wrote:
> > > > > Thanks, David. I've read some about the "Custom validation error on
> > > > > unique_together" ticket. I imagine that if people want customization
> > > > > there, required_together would need the same. The only idea I have
> > > > > that seems to work for both situations is:
>
> > > > > required_together = (('weight', 'height', 'You must provide a weight
> > > > > and height, if you intend to use either.'),)
>
> > > > > unique_together = (('account', 'sku', 'This sku is already in use by
> > > > > your company.'),)
>
> > > > > On Sep 27, 1:22 am, "David P. Novakovic"
> > > > > wrote:
>
> > > > > > Is it? I read this as different to anything in the ORM.
>
> > > > > > This is about conditionally requiring a second field if one is
> > filled
> > > > > > out. Normally it would be done at the JS level.
>
> > > > > > I think it's a good idea, assuming I haven't missed something that
> > > > > > already does this.
>
> > > > > > I can't help thinking this is part of a much larger problem though.
> > > > > > That problem is multifield validation. I think we'd have to address
> > > > > > that issue first before working on this specific case that is
> > probably
> > > > > > the simplest.
>
> > > > > > Maybe this has been considered before, but was dropped because the
> > > > > > idea is too hard to encapsulate in a simple Meta style option?
>
> > > > > > David
>
> > > > > > On Mon, Sep 27, 2010 at 5:18 PM, Florian Apolloner
>
> > > > > > wrote:
> > > > > > > Please post usage questions to the users list. This is already
> > doable
> > > > > > > with model validation.
>
> > > > > > > Florian
>
> > > > > > > --
> > > > > > > You received this message because you are s
Re: #6735 -- Class based generic views: call for comment
On Oct 3, 1:02 pm, Russell Keith-Magee
wrote:
> On Sun, Oct 3, 2010 at 12:12 PM, Ian Lewis wrote:
> > On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee
> > wrote:
> > While I'm in the "one singleton view instance is best" camp and think
> > that storing some state on the request and some on the view is a bit
> > gross, I understand Russell's arguments. New users are simply going to
> > save stuff on self no matter how much we complain, document etc. It's
> > simply a reality that likely can't be helped much.
>
> > Other frameworks seem have View/Handler instances per request, such as
> > appengine's webapp so there is some precedent for creating an instance
> > per request.
>
> >http://code.google.com/appengine/docs/python/gettingstarted/handlingf...
>
> I don't think you'll find any argument that having an instance per
> request would solve all the problems that this thread has described.
> The issue is how to declare a view that is able to be instantiated on
> a instance-per-request basis while simultaneously allowing decorators
> to be easily wrapped around that view.
>
> Yours,
> Russ Magee %-)
I haven't investigated the other solutions described in this
discussion, but the solution I proposed handles decorators just fine.
class BaseView(object):
def __new__(cls, *args, **kwargs):
obj = super(BaseView, cls).__new__(cls)
# Call __init__ manually since it will not be called
# after this method (since __new__ returns a HttpResponse
# and not a BaseView subclass).
obj.__init__(*args, **kwargs)
return obj.view() # Or other name
class MyView(BaseView):
def __init__(self, request):
self.request = request
def view(self):
return HttpResponse(self.request.path)
urlpatterns = patterns("", ("^login_required_view/$",
login_required(MyView)))
Best regards,
André Eriksson
--
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: variable view name in url tag
On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant wrote:
>
> On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
>
>> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant wrote:
>>> I know this has come up over the last few years[1] and people are
>>> mixed on the action that should be taken. I would like to bring it up
>>> again as it has bitten me a few time lately.
>>>
>>> I seems the biggest concern is backwards compatibility of the syntax.
>>> I feel that should not stop us from fixing something that is an
>>> annoying wart and also keeping the syntax in line with how other tags
>>> work.
>>>
>>> In this thread[2] Malcolm suggested introducing a new tag and
>>> depreciating the old one which could be done by bringing something
>>> like[3] into core. Im not huge on the idea of have 2 tags that do the
>>> same thing only with slightly different syntax, but if that is the
>>> cleanest upgrade I'm +1.
>>>
>>> I think this can still be done in a backwards compatible way[4],
>>> unless I'm missing something.
>>
>> This isn't backwards compatible in every case. Consider:
>>
>> {% url foo %}
>>
>> foo could be:
>> - A URL pattern name
>> - A variable in the context
>> - A variable in the context *and* a URL pattern name
>>
>> It's the third case where your proposal has problems. Under the
>> current implementation, it's *always* interpreted as a URL pattern
>> name. Under your proposal, the context variable would take precedence
>> in the third case.
>>
>> It's also backwards incompatible in the second case (though not in a
>> way that matters as much): if you have an existing template that
>> raises an error, but you have a context variable that matches the name
>> you've used, your implementation *won't* raise an error.
>>
>> However, there is another way (an alternative to adding a parallel tag) :-)
>>
>> An interesting quirk/feature of Django's template language: if you
>> register template tags with the same name, the last registered name
>> wins.
>>
>> This means we can define a "future_url" template tag library that
>> registers a {% url %} template tag. Then, in your code, you can say:
>>
>> {% load future_url %}
>> {% url "url-name" foo=bar %}
>>
>> and get the new behavior. Then, we can put PendingDeprecationWarnings
>> in the old {% url %} tag definition, upgraded to DeprecationWarnings
>> in 1.4. Then, in 1.5, we switch the behavior over and start
>> deprecating the future_url tag library.
>>
>> I'm completely in favor of making this change; the behavior of the url
>> tag has always been an annoying wart, and it would be good to clean it
>> up.
>>
>> Yours,
>> Russ Magee %-)
>
> Thanks for the feedback Russ. I know it couldn't be that straight forward.
> I'll work on a patch this week that
> implements what you mentioned. Would it be best to start a new ticket or
> re-open the old ticket?
Open a new ticket. #7917 proposes fixing the existing tag; this is a
complete new approach to the problem. However, make sure you reference
the old ticket and discussions so we have a point of reference. Feel
free to accept the new ticket for the 1.3 milestone.
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: rethinking raw_id_fields
Does anyone besides me think that an AJAX field admin solution effectively deprecates raw_id_fields? I'm interested in seeing a ticket like #14370 go forward if only to close a slew of dusty old tickets about raw_id_fields. -Steve On Oct 3, 5:58 am, Marcob wrote: > Well, M2M and raw_id_fields are a big player in wonderful admin > contrib with a poor interface: why do not improve them? -- 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: rethinking raw_id_fields
An Ajax admin solution (of the autocomplete sort, which I presume is what you're proposing) does not have the same use case for raw_id_fields. It's based on the assumption that the user knows the value of the unicode representation of the object. It does not allow for discovery like the raw_id_fields popup does: no filtering, no sorting, no searching, and no browsing. I am a strong -1 this. An aside: I may be wrong, but I believe that Zain's GSOC 2009 admin-ui project [1] includes a completed Ajax autocomplete widget. [1] http://code.djangoproject.com/svn/django/branches/soc2009/admin-ui/ -- * Chuck Harmston * ch...@chuckharmston.com http://chuckharmston.com On Sun, Oct 3, 2010 at 9:34 PM, subs...@gmail.com wrote: > Does anyone besides me think that an AJAX field admin solution > effectively deprecates raw_id_fields? > > I'm interested in seeing a ticket like #14370 go forward if only to > close a slew of dusty old tickets about raw_id_fields. > > -Steve > > On Oct 3, 5:58 am, Marcob wrote: > > Well, M2M and raw_id_fields are a big player in wonderful admin > > contrib with a poor interface: why do not improve them? > > -- > 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. > -- 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.
Contributing more
Hello, I added the localflavor for Belgium as my first contribution. I would like to contribute more code wise. I looked at the tickets with milestone 1.3 and with no patch. It is hard to know what is critical and where help is the most needed. Can someone tell me what tickets require immediate help and are not too complicated for a new contributor. I don't mind spending 2-3 days before Oct 18th. I have been using Django for 2 years and I am quite familiar with the basics like views, models, templates and forms. Please let me know. Laurent -- 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: #6735 -- Class based generic views: call for comment
On Oct 3, 1:02 pm, Russell Keith-Magee
wrote:
> On Sun, Oct 3, 2010 at 12:12 PM, Ian Lewis wrote:
> > On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee
> > wrote:
> > While I'm in the "one singleton view instance is best" camp and think
> > that storing some state on the request and some on the view is a bit
> > gross, I understand Russell's arguments. New users are simply going to
> > save stuff on self no matter how much we complain, document etc. It's
> > simply a reality that likely can't be helped much.
>
> > Other frameworks seem have View/Handler instances per request, such as
> > appengine's webapp so there is some precedent for creating an instance
> > per request.
>
> >http://code.google.com/appengine/docs/python/gettingstarted/handlingf...
>
> I don't think you'll find any argument that having an instance per
> request would solve all the problems that this thread has described.
> The issue is how to declare a view that is able to be instantiated on
> a instance-per-request basis while simultaneously allowing decorators
> to be easily wrapped around that view.
>
> Yours,
> Russ Magee %-)
I haven't investigated the other solutions described in this
discussion, but the solution I proposed handles decorators just fine.
Furthermore, you can extend it to allow for decorators by
subclassing.
Initial code:
class BaseView(object):
def __new__(cls, *args, **kwargs):
obj = super(BaseView, cls).__new__(cls)
# Call __init__ manually since it will not be called
# after this method (since __new__ returns a HttpResponse
# and not a BaseView subclass).
obj.__init__(*args, **kwargs)
return obj.view() # Or other name
class MyView(BaseView):
def __init__(self, request):
self.request = request
def view(self):
return HttpResponse(self.request.path)
urlpatterns = patterns("", ("^login_required_view/$",
login_required(MyView)))
This will create a view that requires login. We can extend this by
introducing a helper function class_decorator that takes a regular
decorator and turns it into a view class:
def class_decorator(decorator):
class Cls(BaseView):
def __new__(cls, *args, **kwargs):
def view(*args, **kwargs):
return super(Cls, cls).__new__(cls, *args, **kwargs)
return decorator(view)(*args, **kwargs)
return Cls
We can then create a LoginRequiredView for instance:
LoginRequiredView = class_decorator(login_required)
class MyView2(LoginRequiredView):
def __init__(self, request):
self.request = request
def view(self):
return HttpResponse(self.request.path)
MyView2 functions like login_required(MyView). We can also chain
decorators by multiple inheritance.
AUsersView = class_decorator(user_passes_test(lambda u: "a" in
u.username.lower()))
class MyView3(LoginRequiredView, AUsersView):
"""
View that requires users to be logged in and
have a username that contain an 'a'.
"""
def __init__(self, request):
self.request = request
def view(self):
return HttpResponse(self.request.path)
Best regards,
André Eriksson
--
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: Contributing more
Hey, I've been working on tickets that don't have tests or patches or both, to help move them along :) I've found it a good way to get involved with things that aren't too contentious. There are a few documentation bugs as well. Others will certainly have their own take on it too... David On Mon, Oct 4, 2010 at 12:11 PM, Laurent Luce wrote: > Hello, > > I added the localflavor for Belgium as my first contribution. I would > like to contribute more code wise. I looked at the tickets with > milestone 1.3 and with no patch. It is hard to know what is critical > and where help is the most needed. > > Can someone tell me what tickets require immediate help and are not > too complicated for a new contributor. I don't mind spending 2-3 days > before Oct 18th. I have been using Django for 2 years and I am quite > familiar with the basics like views, models, templates and forms. > > Please let me know. > > Laurent > > -- > 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. > > -- 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: #6735 -- Class based generic views: call for comment
I should add.. The bonus of using class-based decorators is that decorated views can be subclassed. All other functionality is retained. -- 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: Contributing more
Hey Laurent, Glad to hear you want to help out! The first step that I usually take is figuring out what component I want to work on. This is usually based around what I have the most familiarity with, or what part I'm interested in learning more about. Trac has nice features for filtering down by component, so for example I usually work on stuff with the test framework, so I'd use something like this: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&group=component&component=Testing+framework&milestone=1.3&order=priority Then once you find a ticket that looks interesting, I'd start with the triage process. The contributing docs are good to read to figure out what style of patches are good, and what the triage stages look like: http://docs.djangoproject.com/en/1.2/internals/contributing/#submitting-patches However, as a quick primer, I'd just look for tickets that are "Accepted", and if they have a patch, review them. If you think they are ready to go into trunk (have docs & tests, good style), feel free to mark them as "Ready For Checkin". This shows a core committer patches that should be checked in soon. If you find something without a patch, I'd go ahead and confirm that the issue is real, and then go ahead and try to fix it! Looking through Django's source and fixing things is usually good fun. In the spirit of Wikipedia, "Be Bold". Cheers, Eric On Sun, Oct 3, 2010 at 9:11 PM, Laurent Luce wrote: > Hello, > > I added the localflavor for Belgium as my first contribution. I would > like to contribute more code wise. I looked at the tickets with > milestone 1.3 and with no patch. It is hard to know what is critical > and where help is the most needed. > > Can someone tell me what tickets require immediate help and are not > too complicated for a new contributor. I don't mind spending 2-3 days > before Oct 18th. I have been using Django for 2 years and I am quite > familiar with the basics like views, models, templates and forms. > > Please let me know. > > Laurent > > -- > 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. > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://ericholscher.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-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.
Proposal: PositiveBigIntegerField
Positive integer fields are useful all the time, and BigIntegerField is no exception to that. On a side note, there doesn't appear to be any built-in model-field level protection from putting gigantic numbers into an IntegerField. When using IntegerField in dev (sqllite3) it allows me to put something like 5 without raising an error. When saved this way the output of that field is rendered as -1. I don't know the science behind this however, but imagine it has to do with deserializing into a long int. -- 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: Contributing more
On Mon, Oct 4, 2010 at 10:11 AM, Laurent Luce wrote: > Hello, > > I added the localflavor for Belgium as my first contribution. I would > like to contribute more code wise. I looked at the tickets with > milestone 1.3 and with no patch. It is hard to know what is critical > and where help is the most needed. > > Can someone tell me what tickets require immediate help and are not > too complicated for a new contributor. I don't mind spending 2-3 days > before Oct 18th. I have been using Django for 2 years and I am quite > familiar with the basics like views, models, templates and forms. > > Please let me know. First of all -- thanks for offering to help out! Unfortunately, there is no simple answer to the "what is critical" question. We try to ship Django releases that don't contain any bugs that cause unexpected data-loss or major system crashes at runtime -- they're the only type of bug that we genuinely consider critical, and we postpone releases if anyone reports them. So, there *shouldn't* be any of those bugs in our system. Beyond that, it's difficult to point you at a list of "important tickets". Anything that is currently open is a candidate for being closed; the tickets that get closed are the ones that people actively pursue to completion. So - what should you do? Well, here's the general list of tasks that need attention: * Any ticket in the unreviewed state [1] needs to be verified. See if you can reproduce the problem described. If you can, move the ticket to Accepted. If you can't, close the ticket. If you think there is a major design issue in question, move to Design Decision Needed. Ask around on IRC if you need guidance on how to treat a given ticket. If, in the process of verifying the problem, you can construct a test case that is integrated with Django's own test suite, you get bonus points; upload a patch containing the test when you mark the ticket accepted. * Any ticket in the accepted state that doesn't already have a patch [2], needs a patch. Try your hand at fixing the problem. * Any ticket in the accepted state that has a patch, but isn't marked "needs docs", "needs tests" or "needs improvement" [3] probably needs a review by someone. Review the patch; if it seems like the right fix for the problem, and it has tests and docs (as required), move it to RFC. * Any ticket in the accepted state that *is* marked "needs docs" [4], "needs tests" [5] or "needs improvement" [6] indicates that there is work to be done. Fix the problem, drop the flag. [1] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&order=priority&stage=Unreviewed [2] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&has_patch=%211&order=priority&stage=Accepted [3] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=%211&needs_tests=%211&needs_docs=%211&has_patch=1&order=priority&stage=Accepted [4] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_docs=1&has_patch=1&order=priority&stage=Accepted [5] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_tests=1&has_patch=1&order=priority&stage=Accepted [6] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=1&has_patch=1&order=priority&stage=Accepted These queries reveal some pretty long ticket lists, which still leaves the issue of which one to pick. [2]-[6] can be filtered by milestone, which will reduce the ticket count a little; the milestone isn't a guaranteed marker that an issue is important, but it usually means that *someone* thinks it is important. Any ticket with lots of discussion, or a long CC list probably indicates that there are lot of people interested. This is also a reasonable indication that a ticket is worth looking into. Other than that -- work on whatever interests you. Pick a component where you feel comfortable, and use that component to filter the Trac queries I gave. As for the October 18th deadline -- that's a deadline for major feature inclusion. For 1.3, this is looking like #12012, #12991, and maybe #6735 and #12323. If you want to help out with these tickets, test the candidate patches, and check the mailing lists for any recent discussions about issues still needing resolution. After that date, focus will move to smaller features and bug fixes until the end of November. Past that date, we will move to focussing on purely bug fixes until the release early in the new year. 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: rethinking raw_id_fields
With the AJAX field implementation on the table you're free to represent the objects however you want. Yeah, there's a few things left out but did you really say 'no searching'? -Steve On Oct 3, 10:09 pm, Chuck Harmston wrote: > it's based on the assumption that the user knows the value of the unicode > representation of the object. It does not allow for discovery like the > raw_id_fields popup does: no filtering, no sorting, no searching, and no > browsing. I am a strong -1 this. -- 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.
