Re: RFC: Query Methods
I replied to the ticket, but I'll mention it here as well. django-model-utils has an implementation of something that achieves the same result. It was originally from http://paulm.us/post/3717466639/passthroughmanager-for-django and has since been added to https://github.com/carljm/django-model-utils On Tuesday, January 3, 2012 at 5:18 AM, Zachary Voase wrote: > On Jan 3, 7:01 am, Russell Keith-Magee (http://keith-magee.com)> > wrote: > > On Tue, Jan 3, 2012 at 1:55 PM, Zachary Voase > (http://gmail.com)> wrote: > > > At the moment it's very easy to add methods to individual models, just > > > by putting a method on the model class itself which accepts 'self'. > > > However, defining business logic on collections of records is > > > currently pretty complicated — you have to create at least a custom > > > Manager subclass, and if you want to chain those methods together > > > you'll need a QuerySet subclass. An example of the desired behaviour, > > > and the steps required for it, is shown in [1]. > > > > > > > > > > I originally created django-qmixin [2] to tackle this problem; you can > > > define methods which will be present on the manager and all querysets > > > produced therefrom, including on relations. However, the django-qmixin > > > approach of creating a mixin and then including that on the Manager > > > class object doesn't really gel with the rest of Django core. I've > > > worked out two approaches which are easier for novices to understand, > > > and match the idioms of the rest of Django. They both involve adding a > > > @models.querymethod decorator, which would be applied to methods which > > > operate on collections of records (i.e. querysets). It's an analog to > > > Python's @classmethod. > > > > > > > > > > The first approach [3] involves adding these querymethods to the model > > > class itself; the second [4] adds them to a manager subclass (but > > > without the trouble of the QuerySet subclass). I prefer the former, > > > for simplicity, but you may believe otherwise. > > > > > > > > > I think I'm in the "otherwise" camp -- primarily for reasons of namespacing. > > > > The QuerySet and the Manager are different classes, but they effective > > share a namespace. It's good practice (and a practice that your > > example demonstrates) for the Manager and the QuerySet to use the same > > names for their methods; it makes a certain amount of sense to me that > > there should be handy shortcut to automagically perform this > > duplication. > > > > However, the same isn't true of the Model and the QuerySet. The API > > for a Model and the API for a QuerySet are quite different -- and > > intentionally so. Sticking QuerySet methods on a Model in order to > > avoid a couple of lines of manager definition and registration seems a > > little odd to me, in an "explicit is better that implicit" kinda way. > > For my money, it's better to be explicit that you're defining a custom > > manager. > > > > In practical terms, there are two ways that this could manifest. > > > > Firstly, if there is a namespace collision -- i.e., if you want > > MyObject.objects.foo() and myinstance.foo() do different things. I > > can't think of an obvious practical example off the top of my head, > > but anything where the verb and collective noun aren't distinguishable > > would be a candidate for a collision. > > > > Secondly, if you have more than one manager, you may want a method on > > one manager, but not the other. For this case, we'd need to have the > > Manager-based shortcut anyway, or tell people that if you have > > multiple managers, you need to do the full-manual queryset definion. > > > > > I'm working on a proof-of-concept implementation, but I feel it's more > > > important to agree on the interface and rationale beforehand. Any > > > thoughts? > > > > > > > > > As I mentioned to you in person at DC.eu (http://DC.eu) -- details > > notwithstanding, > > I'm +1 to this idea. QuerySet+Manager is a common pattern, and it > > deserves to have a simplification in Django's core. > > > > > Here's an example which proves your point: an `as_json()` method which > serializes a model to a JSON-compatible dictionary. You'd probably > want that on both the model instance and the QuerySet. The model > instance one would just pluck out attributes, whereas the QuerySet one > might use `values()` instead. > > I just created a ticket for this feature proposal: > https://code.djangoproject.com/ticket/17494 > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/gro
Re: Don't assume that missing fields from POST data are equal to an empty string value.
I'm very much -1 on this change.
To "fix" this change would require throwing an error anytime an incomplete
dictionary was passed as the data arg to a form. This would break any existing
code that relies on this (in particular it's common practice to accept a subset
of the fields via json). So this would be a backwards incompatible change.
Further more I disagree with the interpretation of the RFC as provided. The RFC
states that any UA may choose to not send along a form field if it contains a
null value. So the question then becomes what is a null value in regards to the
RFC? As I cannot find any mention of what constitutes a null value in the RFC I
went to my browser. Using javascript I executed
``document.getElementById('textfield').value = null`` in the js console. The
result was that the value was set to "". So in my browser (Chrome on OS X) it
is treating null and "" with equivalence.
Going by my personal interpretation of the RFC, and Chrome's behavior in my
javascript test I can only conclude that the proposed change would cause Django
forms to violate the RFC spec and while Violating the RFC spec in and of itself
isn't always the wrong thing to do I do believe that it should only be done
when RFC and implementations are at odds in a way that are incompatible with
each other. In this case they are not, and the RFC is more permissive and
should be followed as Django does not have a list of supported browsers so we
must strive to follow the RFC's where we can (and where they are actually
defined) and deviate only when the alternative is being broken in major
browsers.
Additionally I believe in this case there are two major error conditions.
A) The proposed change is made, a visitor is using a UA that I believe follows
the RFC and any Django forms with optional, and unfilled in values stop working
for this visitor.
B) The proposed change is not made, and when an optional form field is left off
of a form (or json, or any partially incomplete dictionary of values) the form
assumes the default initial value of "".
Neither error condition is optimal, however A has the additional downside that
this error is completely outside of the control of the developer whereas B is
the result of developer error and is under his control.
On Tuesday, January 10, 2012 at 8:38 PM, Tai Lee wrote:
> There is a potential for data loss with optional form fields that are
> (for whatever reason) omitted from an HTML template.
>
> For example, if we take an existing model form and template that
> works, add an optional character field to the model but fail to add a
> corresponding field to the HTML template (e.g. human error, forgot
> about a template, didn't tell the template author to make a change,
> didn't realise a change needed to be made to a template), when that
> form is submitted Django will assume that the user has provided an
> empty string value for the missing field and save that to the model,
> erasing any existing value. This is not a bug, but it is relatively
> easy to trigger silent and unexpected data loss.
>
> I have briefly discussed this with PaulM and dstufft on django-dev,
> but could did not reach any consensus.
>
> RFC1866 [1] says:
>
> > The fields are listed in the order they appear in the
> > document with the name separated from the value by `=' and
> > the pairs separated from each other by `&'. Fields with null
> > values may be omitted. In particular, unselected radio
> > buttons and checkboxes should not appear in the encoded
> > data, but hidden fields with VALUE attributes present
> > should.
> >
>
>
> The HTML4 spec at W3C.org (http://W3C.org) [2] says:
>
> > Users interact with forms through named controls.
> >
> > A control's "control name" is given by its name attribute. The scope of the
> > name attribute for a control within a FORM element is the FORM element.
> >
> > Each control has both an initial value and a current value, both of which
> > are
> > character strings. Please consult the definition of each control for
> > information about initial values and possible constraints on values imposed
> > by
> > the control. In general, a control's "initial value" may be specified with
> > the
> > control element's value attribute. However, the initial value of a TEXTAREA
> > element is given by its contents, and the initial value of an OBJECT element
> > in a form is determined by the object implementation (i.e., it lies outside
> > the scope of this specification).
> >
> > The control's "current value" is first set to the initial value. Thereafter,
> > the control's current value may be modified through user interaction and
> > scripts.
> >
> > A control's initial value does not change. Thus, when a form is reset, each
> > control's current value is reset to its initial value. If a control does not
> > have an initial value, the effect of a form reset on that control is
> > undefined.
> >
> > When a form is submitted for processing, some
Re: start using less (and bootstrap!)
I don't think this is really appropriate in core. Django itself is completely agnostic as to what you output, it doesn't pay attention to html, xml, csv, css, or anything. However if this is just an app you are making then sure. For what it's worth Pinax (a sort of collection of apps/conventions built on top of Django) has "themes" in 0.9a2, and the default theme is a bootstrap theme/app somewhat like you are suggesting. On Thursday, February 2, 2012 at 2:56 PM, Brendan Smith wrote: > for what's it worth, i really like the idea of this. > > i am also starting to use less for all of my projects and i love it. > > and for the record, with less.js it's not actually necessary to compile the > .less files on the backend every time you make changes, you can have the > compilation done on the front end and the browser will catch the results for > future requests. > > > > On Feb 2, 2012, at 2:28 PM, Ric wrote: > > > hi, i want to propose a long term idea. > > > > start using a less framework inside django. > > > > i'm using bootstrap for my django app. it's really cool. > > > > what i'am doing now is writing with less a new css to style django > > admin. > > > > my idea is that django should provide a faster way to write an app, > > and while django is absolutely awesome for writing server side code, > > it does nothing to speed up css/html. > > > > my idea is to write an app, with a setting object containing variables > > for less (colors and so on, font style ecc) and then compile a less > > for your current app. > > > > a command like manage.py compileless could do the trick, and compile > > css code for your app. > > > > django should provide an html base template (used in admin too) that > > is styled with a customizable less app. > > > > it would be a great thing for django to give developers a fast start > > for new apps with a built in less framework. > > > > i'm using bootstrap, and it's great, with a few settings an user could > > customize a base css, and do very cool things with few line of code. > > > > i'm actually working to make it work with django, i hope it will be a > > cool app. > > > > -- > > 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 > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto: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-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: start using less (and bootstrap!)
On Thursday, February 2, 2012 at 3:07 PM, Idan Gazit wrote: > The next major revision of the admin will definitely use either less or sass, > because it is uncivilized to work without such lovely tools nowadays. > > I'm less certain about bootstrap. It has some pros and cons: > > Pros: > * widely used (and thus widely understood) > * We won't need to invent our own style guide for the new admin. If you're > developing a plugin or an extension and you're using the bootstrap styles, > your thing willl mesh nicely with the rest of the admin. > * less.js has the distinct advantage of being easier to develop for than sass > for our purposes.If we go with a less.js solution (like bootstrap), we might > not need to require that all edits to admin "source" stylesheets (less/scss) > come with the recompiled CSS. This lowers the barrier to contribution > significantly, at the cost of a bit of site performance as less gets compiled > client-side. That being said, the admin isn't supposed to be used as a a > high-traffic site (or shouldn't be, I can't say how people abuse it). > > It should only get compiled the first time, after then it get's cached client side IIRC (for less.js). > > Cons: > * less has no equivalent to compass, which is chock full of reusable stuff. > * I'm already having a bit of a negative reaction to the ubiquity of the > bootstrap "look" on the web. That being said, it's relatively easy to alter > some styles, but then we make the job of 3rd party admin extenders harder, > because they must deviate from the default bootstrap style to fit into the > admin. > > -I > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/QxpHySYhgDgJ. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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.
auth.User usernames
I know this has been discussed before, but I wanted to bring it up again in light of the oncoming Djnago 1.4 beta. Can we increase the length of the username field in auth.User? It is a common pattern for emails to be used instead of usernames for a site, and 30 characters makes it difficult to follow that pattern. There are work arounds but they are all a lot less elegant than increasing the length of the username field. I think that a max_length of 75 (to match the default EmailField) would allow developers a lot more breathing room with regards to what they use as the value for username. 75 Would support most emails, usernames, UUIDs, etc. If 75 is too long for the "username" case you could set the max_length of the form to 30 still, allowing developers who want to use a longer value the ability to either subclass the form or provide their own form, which they can easily do, while still using the auth.User model which replacing is not something that is particularly easy or clean to do. Obviously there the overall problem of contrib.auth being inflexible to the differing requirements of varying problems but I don't think we should let a possible future improvement stop a small improvement that can be made today, in other words don't let the best be the enemy of good. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auth.User usernames
On Wednesday, February 15, 2012 at 5:49 PM, James Bennett wrote: > On Wed, Feb 15, 2012 at 4:37 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > I know this has been discussed before, but I wanted to bring it up again in > > light of the oncoming Djnago 1.4 beta. > > > > > So, here's the thing: you're asking for a fairly significant, > massively backwards-incompatible change which requires every Django > install on the planet to do a schema migration... about four hours > before we feature-freeze 1.4. There is simply no way this is going to > get in on that time scale; 1.5, maybe, if the inherent problems can > get ironed out, and if you're strongly interested in making this > happen I'd invite you to help out with that. > > But 1.4 beta -- and thus feature freeze -- happens tonight, and it's > flat impossible to land something of this magnitude before that > happens. > > 1.5 would work as well ;) Sorry I sometimes speak before I think things through, thoroughly. django.auth in general is something that i'm interested in and I want to try and improve to be more flexible, I just hadn't though of a general solution yet and a "easy" (code wise) fix appealed in a shorter term "provide some improvement" sort of way. > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django 1.4 beta 1 released
On Thursday, February 16, 2012 at 6:06 PM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Reinout, > > On 02/16/2012 03:35 PM, Reinout van Rees wrote: > > Partially related question: several tickets have a pull request on > > github instead of an svn patch. Is that enough? I assume a real svn > > patch is better? > > > > > A link on the ticket to a github branch or pull request is fine in lieu > of an uploaded patch. I don't know that this is formally documented > anywhere, but it's been the actual practice for a year or more now. > > fwiw Pull requests never go away whereas branches can, so for strictly archival purposes it would be better to use Pull Requests. > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk89i/sACgkQ8W4rlRKtE2dGUACfRoX9eOdRQR9vBQFHMSUnWMYW > aPUAnjxqQlqefZDDmgmhJ19bkJ3Mt2wA > =0Zak > -END PGP SIGNATURE- > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.User usernames
It's not just the django.contrib apps you lose, it's any app that uses a ForeignKey to users. Which can be a lot of them. On Friday, February 17, 2012 at 5:13 AM, Jonathan Slenders wrote: > > On 16 fév, 13:05, Tom Evans (http://googlemail.com)> wrote: > > 75 isn't large enough these days for either email or username. We run > > a patched version of django for some time that has changed both these > > fields to 255 characters in order to accommodate the needs of our > > users. See RFC 3696. > > > > > This and other issues made us moving away from contrib.auth and > contrib.sessions. It's not too hard to write your own custom > authentication and session middleware, and you can migrate whereever > you want to. The main problem is if you depend on other libraries with > rely on the existance of auth.models.User, like contrib.admin. > > Personally, I think a lot of the apps in django.contrib have a lack of > flexibility. Maybe it's good to leave these apps as they are, but > start something like contrib_v2, as the improved version. > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Should the settings.py template include USE_TZ = True?
On Monday, February 20, 2012 at 3:59 PM, Aymeric Augustin wrote: > (subject changed because I'm forking the discussion) > > On 20 févr. 2012, at 21:29, Anssi Kääriäinen wrote: > > > Another question I have meant to ask is if 1.4 is too early to have > > USE_TZ = True as default setting? I am afraid there are still some > > bugs to iron out, some documentation to improve, helper functions to > > add and most of all the timezone handling might confuse new users. > > > > > I was thinking about that too. > > The main reason for enabling time zone support by default in new projects > (through the settings.py template) was to store UTC in the database (on > SQLite, MySQL and Oracle; PostgreSQL always does that anyway). > > This decision was certainly skewed by my background in enterprise software, > where reliable handling of datetimes is a no brainer. But this isn't the most > common use case for Django. > > Python doesn't make it very easy to deal with time zones, so forcing that > concept on developers isn't friendly. The "right way" to do things is > impractical, and there isn't that much space for improvement. Besides, the > average website doesn't need time zone support, and IRC discussions show that > developers don't care. > > What do others think? I'm very much pro USE_TZ = True being the default. (On another note, i'm also Pro TIME_ZONE defaulting to UTC). UTC is the only time representation that makes sense for long term storage. All of the other timezones all have a long list of "gotchas" to dealing with them, especially in the storage side. > -- > Aymeric. > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Should the settings.py template include USE_TZ = True?
On Monday, February 20, 2012 at 4:24 PM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/20/2012 01:59 PM, Aymeric Augustin wrote: > > The main reason for enabling time zone support by default in new > > projects (through the settings.py template) was to store UTC in the > > database (on SQLite, MySQL and Oracle; PostgreSQL always does that > > anyway). > > > > This decision was certainly skewed by my background in enterprise > > software, where reliable handling of datetimes is a no brainer. But > > this isn't the most common use case for Django. > > > > Python doesn't make it very easy to deal with time zones, so forcing > > that concept on developers isn't friendly. The "right way" to do > > things is impractical, and there isn't that much space for > > improvement. > > > > > Can you give more specifics here? Exactly how much harder is it to work > with USE_TZ = True than USE_TZ = False for a new Django developer, > presuming they don't really care about timezones at this point and just > want to do things more or less right so as not to box themselves in a > corner if they want to add real timezone support in the future? > > In my experience with using Django 1.4a1, and now 1.4b1 with USE_TZ=True it has not been difficult. The biggest hurdle is that when generating a date/time programmatically you need to make sure to attach a timezone to it. With pytz this is pretty easy. ``datetime.datetime().replace()`` instead of just ``datetime.datetime()``. Really the biggest hurdle I had in using 1.4 with USE_TZ = True is that libraries I don't control tend to use date/times without a timezone attached causing an exception. I would argue that this is a benefit rather than a negative though as otherwise you just kind of assume that those other libraries are using the same timezone as you (``datetime.datetime.now vs date time.datetime.utcnow vs datetime's coming from another source in any other timezone``). And I feel like my code has less of a chance for silent data corruption now that I am no longer just assuming that libraries are using the same timezone as me and I explicitly attach a timezones to the incoming date/times asap. > > I guess I think there's some value in setting people on the right path > earlier rather than later, but it really depends on exactly how much > harder that path is. > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9CugQACgkQ8W4rlRKtE2fr6wCg2/cXMn/bHL/p6Cg5YDzZmPNe > AasAoKWeKEnDnWvcuYZR3EsqRsMlRfnB > =Sjc9 > -END PGP SIGNATURE- > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Revisiting multiline tags
On Sunday, February 26, 2012 at 4:38 AM, Łukasz Rekucki wrote: > On 26 February 2012 05:55, Joe & Anne Tennies (mailto:tenn...@gmail.com)> wrote: > > While this would be a valid argument if Django templates only rendered HTML, > > that is not the only thing it can be used to render. > > > > > > The original poster gave a very good example of a text-based email. > > This is pretty much the only valid use-case: human-readable markup > which cares about whitespace. But I don't see how multiline tags help > here, as now you have a mix of text that does and doesn't care about > whitespace, So when reviewing the template, you can't see the layout. > > > I could list lots of other formats in which white space must be followed to > > even be useful (like .CSV). > > Please don't use templates to render CSV, that's like using regular > expressions to parse XML. Most of data exchange and configuration file > formats have libraries to serialize them. So no, that's not a use > case. > > > I have used Jinja2 on multiple occasions to render C code that needed to be > > code reviewed. > > > > > While I have nothing against rendering C code with templates, I pity > the person reviewing it - why would you force anyone to review > auto-generated code? > > I'm -1 on this until someone actually provides a patch with no > performance hit. Really, we know people fork Django for their private > use. If this is such a big deal, we should have at least one person > using this in production for a while now and have an excellent quality > patch to show. > > I think it's silly to think someone would fork Django to add multiline tags. More likely they would just suck it up and deal with it, but that doesn't make it a bad change. I'm +1 for this change. > > > -- > Ł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-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Revisiting multiline tags
On Sunday, February 26, 2012 at 4:54 AM, Łukasz Rekucki wrote:
> On 26 February 2012 06:12, Yo-Yo Ma (mailto:baxterstock...@gmail.com)> wrote:
> > After Ned's message, I'm -0, because while I'm not fond of multi-line
> > tags, I cannot offer a good alternative when it comes to multi-line
> > "with" tags.
> >
>
>
> Let's not forget that until Django 1.3, {% with %} accepted only one
> parameter forcing you to write nested {% with %}'s. We had a
> discussion then and a more concise "x=..." syntax was chosen over "and
> x as ...". The syntax was also added to blocktrans. This was to ease
> those rare cases when you have to pass a few parameters to the {% with
> %} and/or make an include with changed context. A year after, It turns
> out the use cases aren't so rare anymore.
>
> Now, if your blocktrans contains 10 variables and all have more then 2
> dots in them, then maybe there are other reasons that it looks ugly
> then lack of multi-line tags.
>
>
There's not a much better solution, especially in the blocktrans case. What
else would you do? offload that
template to the view? That's silly, why have any translation in the template
then.
>
> --
> Ł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-developers@googlegroups.com
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> (mailto: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-developers@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: authentication by email
The major issue is that there is no way to do schema migrations in core (currently). So there's no way to handle increasing the length of the username field. More comprehensive solutions require more thought to figure out the pluggable User models. On Friday, March 9, 2012 at 12:54 AM, Clay McClure wrote: > "Django is a high-level Python Web framework that encourages rapid > development and clean, pragmatic design"—unless you want to do something > seemingly simple like using email addresses for authentication, in which case > you need to monkey patch models and forms to get everything working right, > which is neither rapid nor clean. What began as an innocuous feature request > five years ago is now a high-level, general purpose, abstract, seemingly > insurmountable design problem. The core developers are still perfectionists, > but they seem to have forgotten their deadlines. > > Is there not a simple, pragmatic solution (optional and for new > installations—we're not talking about backwards compatibility here) that > could be implemented until the panacea of pluggable User models gets figured > out? Something as simple (albeit ugly) as wrapping new models and forms in: > > if settings.AUTH_EMAIL_AUTHENTICATION: > > Should these things really take five years? What happened to pragmatic? > > Clay > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/KebjFDOOBF4J. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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.
Model.save and Model.full_clean
I'm working up a documentation patch to make this spelled out more explicitly
but I wonder if there isn't more that should be done.
Currently ``Model.full_clean`` is not called automatically when saving a model.
This is not a big deal when manually constructing your models as you can
just do:
m = MyModel(field=foo)
m.full_clean()
m.save()
However there is no easy way to get a similar behavior when using
``MyModel.objects.create``
or ``MyModel.objects.get_or_create``.
The documentation currently mentions that get_or_create is useful in data
import scripts, but
also mentions using it in views. My patches will try to make it more explicit
that it's unsafe
to assume that the constraints in the field (e.g. URLField) will be enforced
but I wonder if
maybe it would make sense to either make running ``full_clean`` the default or
provide a way
for people to specify that it should be ran. It appears that it's not run by
default due to
backwards compatibility: https://code.djangoproject.com/changeset/12103 .
Currently I would assume that both because of the lack of warning in the
documentation, and
because it isn't obvious behavior (e.g. an URLField that accepts unsafe input,
such as
``javascript:alert("xss");``), that more than one Django powered site is
vulnerable to attacks
such as an XSS where they are using ``create`` or ``get_or_create`` manually
without passing
through a form.
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: auth.User refactor: reboot
A big +1 to this. I'm willing to help where I can as well if you can find some use for me :) I think one of the big problems is the lack of being able to modify the user model in any appreciable way. Regardless of incremental improvements or not I think one possibly decent method is that which is used by https://github.com/aino/django-primate It lets you specify a User model that is available at django.contrib.auth.models.User but can live anywhere. If we go with the incremental improvement kind of fix this could be done with a default option that maintains the current user model. If a rewrite option is in place then the default user model could be changed to better match a more generic model. On Friday, March 16, 2012 at 12:53 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > This discussion of user authentication by email is getting pretty nasty; can > we start over? I know there's a lot of quite legitimate frustration here, but > we really need to drop the personal stuff and focus on the problem at hand. I > want to move this forward quickly, and I can commit to spending some time on > it in the coming weeks, but I'm going to lose interest faster than than you > can believe if the tone doesn't improve. Please: keep it professional, and > focus on the tech. I promise things'll go smoothly if we all do. > > As I see it, there's two basic approaches we could take: > > 1. Incremental improvement: fix the most glaring issues with auth.User > (starting with email addresses for login, clearly), and generally improve > things a bit at a time. Once User's in a state where we're happy, move on the > rest of the auth app -- again, a bit at a time. This approach would see the > largest issues fixed more quickly, but would probably do so at the expense of > code quality (e.g. requiring a one-off solution to schema migration of the > User model) and would delay a more sweeping reform until later. > > 2. Complete improvement: recognize that the auth app is fundamentally flawed, > and mercilessly refactor/replace/rewrite it, all in one go. The hypothetical > results here would be better -- a modern auth system unencumbered by the > decisions we made in 2005 -- but this would take far longer, and would block > on things like the app refactor and schema migrations. > > There's also a middle-ground proposal from Clay: make the auth app swappable, > thus making it possible for *users* to replace the auth app while leaving > time for us to make either incremental or complete change, as we see fit. > > I think we need to come together and agree on an approach before we move > forward, so I'd like to see some concrete proposals for each of these > approaches. Since all options have merits and since I think it's unlikely > we'll find consensus I'm prepared to make a BDFL ruling here. So if you feel > strongly about one approach or another, please write a concrete proposal and > post it here or on the wiki. I'll look these over -- and also review Clay's > branch -- and (again, baring consensus) make a ruling next week. > > Just so my biases are clear: normally I'd lean more towards the completionist > stance, but in this case I haven't seen an actual proposal to completely > replace auth. Further, I think the fact that it's blocked on *other* pretty > hairy issues means it'd be unlikely to see that much action that quickly. I'm > also somewhat opposed to the "pluggable auth" idea since I think it dilutes > the utility of having built-in auth. In other words, if we're going to make > auth up to users, why not just get rid of the built-in auth altogether? So > I'm leaning towards an incremental improvement approach, but only if I can > see a concrete proposal that articulates what to change, and deals with the > backwards-compatibility issues in a not-too-ugly way. > > Thanks! > > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.User refactor: reboot
On Friday, March 16, 2012 at 1:29 PM, Tom Evans wrote: > On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss (mailto:ja...@jacobian.org)> wrote: > > Hi folks -- > > […] > > > > > I'm not in favour of pluggable user models, as for me, they solve the > wrong problem. A pluggable user model has to be set up by the project > developer, whilst the attributes an app may need are specified solely > by the app developer. > > If a project developer decides to add a 3rd party app to his project, > where do the user preferences for that app live? Does the user model > automatically get expanded with the extra fields required by that app? > It all seems icky to me. > > To my mind, User + app specific user profiles are the correct > approach, plus fixing the current minor issues with d.c.a., and > providing tools and documentation to allow users to manage that > change. > > Put another way, what does a pluggable user model get us? What is the > big selling point, apart from being able to specify arbitrary columns > to appear in auth_user rather than myapp_userprofile. > > In the current situation it would allow overriding the username field to be longer in order to use say an email address. But that particular issue is sort of a red herring to the larger issue that if what you want from the User model doesn't fit the current User model, your options are A) throw it out (which means you basically can't use any third party apps that deal with users), or B) monkey patch it/hack around the limitation. The model is completely inflexible. Which is fine when you just want to _add_ information, in those cases you can just use a profile. But what about when you want to modify one of the assumptions that the user model makes? (in the above example, what constitutes a valid username). In my mind unless the User model becomes nothing more than an intermediate model that other models FK back too (with no real attributes of it's own) you are always going to have an issue where someone wants to modify some part of it and can't without doing something really hacky. And I think that having a situation like that is far worse that pluggable user models. > > Cheers > > Tom > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.User refactor: reboot
On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote: > Disclaimer: I was up really, really early this morning, so please bear with > me if I sound somewhat incoherent... > > On March 16, 2012, at 12:29 , Tom Evans wrote: > > > On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss > (mailto:ja...@jacobian.org)> wrote: > > > Hi folks -- > > > […] > > > > > > > > > I'm not in favour of pluggable user models, as for me, they solve the > > wrong problem. A pluggable user model has to be set up by the project > > developer, whilst the attributes an app may need are specified solely > > by the app developer. > > > > If a project developer decides to add a 3rd party app to his project, > > where do the user preferences for that app live? Does the user model > > automatically get expanded with the extra fields required by that app? > > It all seems icky to me. > > > > To my mind, User + app specific user profiles are the correct > > approach, plus fixing the current minor issues with d.c.a., and > > providing tools and documentation to allow users to manage that > > change. > > > > Put another way, what does a pluggable user model get us? What is the > > big selling point, apart from being able to specify arbitrary columns > > to appear in auth_user rather than myapp_userprofile. > > > > > I personally find the User/Profile mechanism in Django to be quite awkward, > to be honest. It's certainly not the end of the world, but it'd be nice if it > was...less contrived feeling. > > I have an interesting suggestion/compromise: What about a mechanism that > allows the app developer to *add* fields to the User model, but not change > (or remove) existing keys? From my vantage point, this would have nearly all > of the benefits of a pluggable user model with almost none of the drawbacks, > and it would feel much more straightforward than the current mechanism. There > may be some reason that I'm missing as to why this is foolish, though. > > Here's my hit list of perceived benefits: > 1. It regains the efficiency of a single table (which is minor, to be sure, > but since Jacob already brought it up...) > > This issue isn't as minor as one might think I don't believe. I've recently started using the fetch_related thing (which would be the only way to prevent N queries when trying to select a bunch of users + their profiles) and on a table with 20k entries (this isn't User related) where the entries are fairly large the processing time to fetch them all was very significant. This effect would increase with Tom's per app profile issue. > > 2. It allows app developers who just need a little bit more than what the > User model does to add their custom fields seamlessly. This would mean, for > instance, The subclassable user model that django-primate uses solves this as easily as it does the base fields. > > a. That the admin would just magically have the new fields in the User form, > instead of having to either plug in a custom form, set up a separate > ModelAdmin for your profile, or whatever else. For registration, we could > offer two stock forms (one minimalist one, and one complete one that just > blindly uses every field we don't know we want to exclude (e.g. is_staff)). > If neither form works for the end developer, then they write and use their > own. > > b. That the end developers don't have to write repetitive glue code on every > one of their projects to make their profile models work. (Why do I have to > write a signal to auto-save a profile object on User object save every time, > for instance?) > > 3. We don't have myapp_userprofile. This is kind of a big deal to me, because > in most of my projects there is no "clear" / "correct" place for this model > to live -- there's no single app that handles users, because that's what > django.contrib.auth is supposed to do. Getting these arbitrary columns into > auth_user is a nice categorization win. > > If I understand this correctly, we avoid the following drawbacks of a fully > pluggable system: > 1. Apps can still be written to expect certain fields on User to exist, > because the customization only allows the addition (not alteration) of fields. > > This is somewhat of a red herring I think. With any pluggable system you'll have a minimal set of required attributes. This minimum set of required is going to depend greatly on what apps you have installed. Some sites the only minimum would be the fact that a user model exists at all, some would require username, email, first and last name. > > 2. We aren't expecting nearly every Django installation to write their own > User model just to make a small addition to what stock Django offers; if you > want just an extra field for birthdate, you don't write an entire custom user > model; you just add the field. Since "I just want a few extra fields" is > (other than the email address / username snafu) probably the most common need
Re: auth.User refactor: reboot
On Friday, March 16, 2012 at 3:59 PM, David Danier wrote: > Hi, > > sorry, if this was said before, I haven't read the latest user discussions. > > I'm in favor of enhancing the auth app step by step, as everything else > seems unlikely (haven't happend for a long time, why should it now). > What I dislike about the current auth app in general is that it solves > differnt things. You either have to take it all or do everything > yourself. So perhaps a first step towards a new and shiny auth > implementation might be to split things up? What do you think? > > Currently auth consists of multiple things: > * authentication > * authorization / permissions > * Users > * Groups > > In any case, the current auth system isn't all bad. I like many things > and it works well for most cases. The email-login issue may be solves > with randomly generated usernames and a authentication backend that > matches by email-field instead. This all isn't perfect, but small steps > may be enough to get to a nearly perfect solution here. > > There are numerable issues with this that are not simply solved by an authentication backend. Amgonst them that the email column isn't unique, isn't required, isn't indexed is limited to 75 characters and isn't used as the representation for a user. > > David > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.User refactor: reboot
On Friday, March 16, 2012 at 11:51 PM, Henrique Bastos wrote: > Hello, > > I would like to share some early stage thoughts on this matter. > > On Fri, Mar 16, 2012 at 5:01 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > On Friday, March 16, 2012 at 3:59 PM, David Danier wrote: > > > ... > > > Currently auth consists of multiple things: > > > * authentication > > > * authorization / permissions > > > * Users > > > * Groups > > > > > > > > > > > > > > > Maybe the problem is that we think an User as a person. The User model could > be more like an Account, having only attributes related to authentication. > > In that case, even the email address could be placed somewhere else. I > understand that the email address is important, but for registration > purposes, not for authentication. It seems to me that what really describes > an User is in fact the User Profile (as metadata about an account). The issue is that authentication can vary from site to site. For instance on some sites usernames don't make sense and it makes more sense to use as email address as your identification token instead of a username (Facebook does this, as do many other sites). The larger issue is that no matter the length or the properties you give that field, _someone_ is going to want something different, or _something_ will change in the future that makes those existing assumptions now bad assumptions. Allowing the user model to be pluggable allows apps to change things around so that they can adjust on a per site level what a "user", or an "account" is for them. For some sites that might be username + passwords, others email + password, and still others might not have either and might be identified soley by an SSL client certificate. > > If we could separate the user creation process from the User model and put it > as part of a registration entity or something, a project could > extend/override it to set the account content and create the auxiliary models > properly. This would allow the use of an username, or an email or any kind of > unique identifier. We still would need to fix the column length, but this > would help to keep the authentication process consistent. > > This would have impact on the admin. But maybe the User attributes needed by > the admin should be provided there, as a model with FK to the Account. > > All the best, > -- > HB > > > > > > > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.User refactor: reboot
On Saturday, March 17, 2012 at 1:59 AM, Russell Keith-Magee wrote:
>
> On 17/03/2012, at 12:53 AM, Jacob Kaplan-Moss wrote:
>
> > Hi folks --
> >
> > This discussion of user authentication by email is getting pretty nasty;
> > can we start over? I know there's a lot of quite legitimate frustration
> > here, but we really need to drop the personal stuff and focus on the
> > problem at hand. I want to move this forward quickly, and I can commit to
> > spending some time on it in the coming weeks, but I'm going to lose
> > interest faster than than you can believe if the tone doesn't improve.
> > Please: keep it professional, and focus on the tech. I promise things'll go
> > smoothly if we all do.
> >
> > As I see it, there's two basic approaches we could take:
> >
> > 1. Incremental improvement: fix the most glaring issues with auth.User
> > (starting with email addresses for login, clearly), and generally improve
> > things a bit at a time. Once User's in a state where we're happy, move on
> > the rest of the auth app -- again, a bit at a time. This approach would see
> > the largest issues fixed more quickly, but would probably do so at the
> > expense of code quality (e.g. requiring a one-off solution to schema
> > migration of the User model) and would delay a more sweeping reform until
> > later.
> >
> > 2. Complete improvement: recognize that the auth app is fundamentally
> > flawed, and mercilessly refactor/replace/rewrite it, all in one go. The
> > hypothetical results here would be better -- a modern auth system
> > unencumbered by the decisions we made in 2005 -- but this would take far
> > longer, and would block on things like the app refactor and schema
> > migrations.
> >
> > There's also a middle-ground proposal from Clay: make the auth app
> > swappable, thus making it possible for *users* to replace the auth app
> > while leaving time for us to make either incremental or complete change, as
> > we see fit.
> >
> > I think we need to come together and agree on an approach before we move
> > forward, so I'd like to see some concrete proposals for each of these
> > approaches. Since all options have merits and since I think it's unlikely
> > we'll find consensus I'm prepared to make a BDFL ruling here. So if you
> > feel strongly about one approach or another, please write a concrete
> > proposal and post it here or on the wiki. I'll look these over -- and also
> > review Clay's branch -- and (again, baring consensus) make a ruling next
> > week.
> >
> > Just so my biases are clear: normally I'd lean more towards the
> > completionist stance, but in this case I haven't seen an actual proposal to
> > completely replace auth. Further, I think the fact that it's blocked on
> > *other* pretty hairy issues means it'd be unlikely to see that much action
> > that quickly. I'm also somewhat opposed to the "pluggable auth" idea since
> > I think it dilutes the utility of having built-in auth. In other words, if
> > we're going to make auth up to users, why not just get rid of the built-in
> > auth altogether? So I'm leaning towards an incremental improvement
> > approach, but only if I can see a concrete proposal that articulates what
> > to change, and deals with the backwards-compatibility issues in a
> > not-too-ugly way.
>
> Ok - I've been keeping quiet on this; partially due to the same tone issues
> that you've described, but also because I don't have a huge amount of spare
> time at the moment, and I don't want to be the person who makes a bunch of
> promises (expressed or implied) to work on something and then can't deliver
> on those promises.
>
> My biggest concern is that the middle-ground proposals that are on the table
> are implementing a workaround for a problem when the starting point of a
> long-term solution won't require that much more effort.
>
> IMHO, rather than implement a bunch of settings to introduce an
> auth.User-specific solution, we need to do two things:
>
> * Merge the app-refactor from GSoC 2010.
>
> This has a whole bunch of long-needed awaited benefits -- reliable hooks for
> app startup, configurable app labels, predictable module loading, amongst
> others -- but the one that matters for the purposes of auth.User is that it
> allows Apps to be treated as items that need to be configured as a runtime
> activity. In this case, we need to be able to specify, at a project level,
> which model is your "User" model in the auth app.
>
> * Add the concept of a LazyForeignKey.
>
> LazyForeignKey is a normal foreign key, with all the usual foreign key
> behaviors; the only difference is that the model it links to isn't specified
> in the model -- it's a configuration item drawn from an application
> configuration. So, ForeignKey('auth.User') creates a foreign key to
> django.contrib.auth.User; LazyForeignKey('auth.User') asks the auth app for
> the model that is being used as the 'User' model, and creates
Re: auth.User refactor: reboot
On Tuesday, March 20, 2012 at 10:08 AM, Tom Evans wrote: > On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee > mailto:russ...@keith-magee.com)> wrote: > > > > On 20/03/2012, at 8:38 PM, Tom Evans wrote: > > > > > > > * It's completely backwards compatible. > > > > > > > > If you've got an existing app with normal ForeignKeys to auth.User, > > > > the app will continue to work, without any migrations, as long as > > > > the rest of your project uses auth.User. It will also co-exist with > > > > any configurable app that is configured to use auth.User as the > > > > user model. It will only fall down if you have a configurable app that > > > > uses a different User model (i.e., you can't use a new feature without > > > > ensuring all the parts you need support the new feature). > > > > > > > > > > > > > So, what do I do when 3rd party app1 wants a BizarroUser model, and > > > 3rd party app2 wants WeirdUser model? Using the two together as a > > > mix-in would cause problems with any name/definition clash. > > > > > > > > > Absolutely. That's why I've kept talking about the need for a strong > > interface contract, and the fact that contrib.admin is in a strong position > > to set a minimal User interface contract. > > > > > User profiles solve the issue of app specific data in a better way > > > than specifying additional fields on a a base user object, > > > particularly as the number of apps increases. Whilst there is an > > > additional cost in joining to the user profile table, typically in > > > app1 you only need app1.UserProfile, and not appN.UserProfile. > > > > > > > > > Go back and read my posts -- I've repeatedly said that I prefer UserProfile > > as a pattern for *app specific* data. The only role that I see pluggable > > user models solving is the issue of username and email length/uniqueness, > > and/or the tracking of additional data required for the authentication > > process. Anything else app specific should be kept in a UserProfile (or > > UserProfiles, or some other model related 1-1 with User). > > (I'm not manually fixing up the line length in your emails any more, > so sorry to others about the quoted line lengths) > > Yes, I'm aware of your stance on this. I was merely pointing out that > with this scheme you will get 'pluggable' apps that insist on their > own models, ie they are no longer pluggable. It's not a big deal. > > > My proposal for this would be to treat the migration process the same as > > we've done for any other feature that we've added to Django -- make it an > > opt-in change with a documented migration path. > > > > For example, when we introduced localization, we set the default to > > USE_L10N = False, and made the default behaviors unchanged from the older > > unlocalized behavior. However, if you opted in to USE_L10N = True, you got > > all the nice new localization features, and possibly a couple of migration > > headaches. However, because it was an explicit opt-in, you're on the > > lookout for things that might have changed or broken. > > > > Similarly, I would argue that we if we include this change, we have to ship > > a concrete User model that is *unchanged* from it's current definition. We > > then have three options: > > > > 1) Ship an updated User model (say, SimpleUser) with corrected email > > max_length (and any other changes that pop up). We document the process for > > opting in to using SimpleUser, including the ALTER TABLE statements that > > are required to modify any existing databases. > > > > 2) Ship a range of sample User models representing common User model > > patterns (e.g., using email as login, username but no email, etc) and > > provide the migration path for each. > > > > 3) Punt on the entire issue, document the limitations with the built in > > User model, and let the community manage User models; document what people > > need to do in order to switch, but leave migration as an open question that > > people providing new User models need to answer. > > > > Personally, I'd be in favor of option (3), mostly because what the last 6 > > years has taught us is that no matter what we pick as field names/sizes, > > *someone* will be unhappy. However, I won't get too bent out of shape if > > Django ends up shipping at least 1 new concrete User model -- at the very > > least, it's a good way to prove we can eat our own dogfood. > > Right. So the conclusion to this is "Ship broken, allow people to fix it". > > > > > If we introduce 1-N new User classes, we could also take the opportunity to > > make one of the new User models the default user if you deploy auth using > > an App definition, but User the default otherwise. This means that any new > > projects would get the new SimpleUser class, but existing projects would > > get the older User class. > > > > The key point here is that we're not forcing every Django user to discover > > by accident that they need to run an
Re: auth.User: The abstract base class idea
On Tuesday, March 20, 2012 at 11:25 AM, Alex Ogier wrote: > There have been various proposals about replacing the User class with > an abstract base class. Ian Lewis has a semi-workable version at > http://ianlewis.bitbucket.org/django-newauth/index.html but its > proposal met with resistance in part because there's not a great > migration path from existing apps. I recently attended a Boston-area > python meetup, and met James Sullivan and Max Thayer, two of the guys > behind www.matchbox.net (http://www.matchbox.net). We came up with a similar > solution to Ian's, > but with a better path away from the status quo. Here's our flavor of > the abstract base class, based on the needs we see in other threads. > > Starting from a basic set of premises: > > 1. People want to rip out auth.User’s authentication strictures > (username, email, password) > 2. People want to plug in fields via distribution of apps, not just in > one project-wide user table > 3. People want to depend on auth.User, by foreign key mostly > 4. For the foreseeable future, by default auth.User has to map to its > old DB table > > Here’s the clear winner for me: Make auth.User a subclass of an > abstract base class. It seems no one minds the whole auth permissions > thing sticking around even if it goes unused (if it ain’t broke don’t > fix it), so leave all that on auth.User and move everything else to > auth.DefaultUser, which is a class with Meta.abstract = True. Have > auth.User inherit from DefaultUser by default, with a setting to > override that with your own class(es). Languages like Ruby do this > with mixins, we do it with > https://docs.djangoproject.com/en/dev/topics/db/models/#multiple-inheritance > > There are definitely some cons: > > 1. Requiring classes and settings to be available at the time of > definition of auth.User means circular dependencies are a problem. > 2. Multiple inheritance is wonky and confusing in python, and only a > hackish sort of standin for mixins. > 3. In the absence of a way to override fields (something that might be > added later?), you can’t subclass DefaultUser hoping to change a > default field, you can only add fields or reimplement the whole thing. > Thankfully that would be much easier. > > But still the benefits are pretty large: > > 1. No changes to existing applications. > 2. The common case of adding fields to users is easier even than > profiles: subclass DefaultUser, add your stuff, change a setting. No > get_profile() or select_related mumbo-jumbo. > 3. The second use-case of ripping out auth.User’s broken assumptions > is possible: rewrite DefaultUser in your project. > 4. The third use-case of plugging app mixins into the User model is easy. > 5. The migration path is easy. You can incrementally step away from > the default user model, and (assuming running your migration framework > on a django.contrib app doesn’t blow up somehow) you can take > advantage of migrations without requiring them. > 6. When you change fields, you break only the stuff that depends on > them. If you remove the username field, then half the default forms > stop working, but there’s no reason for auth middleware to break, etc. > > Anyways, asides for circular dependency edge cases I think the rest of > the downsides can be mitigated by good docs. What do you guys think? > > -Alex Ogier > > P.S. I hear you are accepting GSOC applications. > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > This is pretty much exactly what django-primate does, except it includes a special metaclass to allow overriding of default fields. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auth.User refactor: reboot
On Tuesday, March 20, 2012 at 1:07 PM, Nan wrote: > > > However not all databases have this same behavior when trying to insert a > > string that is longer than > > the field allows. This means that for a certain subset of Django developers > > if they didn't read the > > releases note, or just missed that section of it that Django would not > > validate the length of the > > field to be 30, but would instead validate it to be much longer, Django > > would pass it to the database > > who for those users it would silently truncate the data. > > > > > Would something like the following alleviate that problem? > > class User(models.Model): > if settings.USE_LONG_USER_FIELDS: > username = models.CharField(max_length=255, unique=True, ...) > else: > username = models.CharField(max_length=30, unique=True, ...) > ... > > > So you have three cases: > > 1) New app; settings.py generated with USE_LONG_USER_FIELDS=True; > table generated with full-length fields on syncdb; no problem. > 2) Existing app; user doesn't read the docs, doesn't change settings; > field still gets set to max_length=30, no data loss > 3) Existing app; user reads the docs, changes the settings, and > updates his database. > > This way you'd only get data loss if someone manages to read the docs > closely enough to update the settings but not the DB, which IMO is > something that gets addressed by calling it out very clearly in the > documentation anywhere the setting is mentioned. > > Just an idea... > > -Nan > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > What Alex said. If it was _just_ the username then you'd have a good argument for a setting like that. However there's username, email, some people want to add fields, some want to get rid of, or combine fields. Ideally any change would work for as many of those use cases without turning into a giant set of boolean flags that drastically alter the DB schema. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auth.User refactor: reboot
On Tuesday, March 20, 2012 at 2:00 PM, Tom Evans wrote: > On Tue, Mar 20, 2012 at 5:41 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > What Alex said. If it was _just_ the username then you'd have a good > > argument for > > a setting like that. However there's username, email, some people want to > > add > > fields, some want to get rid of, or combine fields. Ideally any change would > > work > > for as many of those use cases without turning into a giant set of boolean > > flags > > that drastically alter the DB schema. > > > > > No-one is talking about a 'giant set of boolean flags', or drastically > altering the DB schema. > > The email field needs to accept email addresses of up to 254 octets. > The username field should be able to hold common fields used as a > username, eg emails, and hence needs to be longer. > > That is one boolean flag. No more. If you want more flexibility on the > model, you would use the proposed pluggable auth models. > > What the much maligned setting gives us is a way to provision new > sites and migrate existing sites that care about that situation in to > a position where users with long email addresses can sign up to a > django site. Score. > > Cheers > > Tom > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > So you fix the problem for the people who agree that username should be longer, and that email should be longer, but not the people who feel that email should be longer but username is fine? Those settings do not feel any cleaner to me personally than monkey patching the models. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auth.user refactor: the profile aproach
If i recall on IRC the decider was to just create a display field (e.g. user.data["display"]) that the default profiles can provide (and can be overridden by other profiles of course). On Monday, April 2, 2012 at 9:17 PM, Anssi Kääriäinen wrote: > On Apr 3, 3:35 am, Jacob Kaplan-Moss (http://jacobian.org)> wrote: > > Hi folks -- > > > > I've written up a proposal for how *I* would like to address refactoring > > auth.user:https://gist.github.com/2245327. > > > > In essence, this does two things: > > > > * Vastly "prunes" the required fields on auth.user. The only things left > > are an "identifier" (which could be username, email, url, uuid, whatever), > > and a password. > > * Introduces a new "profile" system that provides a way to contribute extra > > related fields. Multiple profiles are supported, along with some syntactic > > sugar for dealing with multiple profiles in a reasonably reusable way. > > > > And that's about it. I'm deliberately trying to find a middle ground > > between "do the minimum to allow people to move on" and "throw out and > > rewrite django.contrib.auth entirely". I'm not expecting everyone to be > > thrilled by this idea, but I'm hoping that this is "Good Enough" for almost > > everyone. > > > > For more please see the document. Please do try to read the whole thing: > > I've had a few rounds of feedback incorporated already, and there's even an > > FAQ at the end. > > > > I'm not using BDFL fiat here, at least not yet. This is a proposal, and I > > very much want to hear feedback, objections, and alternatives. I'm > > particularly interested in hearing from people who've got complicated auth > > needs and think this absolutely won't work for them. > > > > I *have* reviewed all the other proposals and I'm between -0 and -1 on all > > of them. This means that if you don't like my proposal, you'll probably > > have to come up with a complete *new* idea to have any chance of getting my > > vote. > > FWIW I am +1 on this proposal. This is assuming that forms, queryset > handling of the data and so on actually work correctly and nicely. I > don't see a blocker in those areas, but before the code is actually > written and tested it is impossible to say if there will be problems. > Devil is in the details and all that. > > I hope this will not result in hacks to allow .filter(data__) and so > on. I believe we should aim for as generic solutions as possible. If > we do hacks just for the User model, they _are_ going to cause > problems later on. Most of the features needed would be neat to have > regardless of the User refactor. Custom lookups per model/field for > example would be _really_ neat feature. The downside of aiming for > generic solutions is that we once again get into the situation where > User refactor is blocked by implementing foo, bar and baz before it. > > I believe this is the right way forward. Multiple profiles makes sense > in the SQL world, and in the NoSQL world you would just embed the > profiles into the User document. I don't believe performance will be a > problem in practice, at least as long as you don't add too many > different profiles to be loaded by default. The most common use case > will just get better support: you have user profile containing three > fields, and then you have all your local fields defined in one > profile. As now, you have profile + user, now they just model your > data properly. > > I don't see a proposal of how __unicode__ is going to be handled (the > Hello, UserName requirement). My proposal: go through the profiles in > the order they are defined, and pick the first one having __unicode__ > defined as the default __unicode__. If there is no such profile, > return identifier. > > - Anssi > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.user refactor: the profile aproach
If we use __unicode__ (which i'm fine with) then it needs to follow the same resolution path as user.data[] does. On Monday, April 2, 2012 at 9:25 PM, Anssi Kääriäinen wrote: > On Apr 3, 4:20 am, Donald Stufft http://gmail.com)> > wrote: > > If i recall on IRC the decider was to just create a display field (e.g. > > user.data["display"]) that the default profiles can provide (and can be > > overridden by other profiles of course). > > > My problem with this is that for example where I work the display > field would contain '%s, %s (%s)' % (self.lastname, self.firstname, > self.empl_no). I would not like to do that data duplication. If the > 'display' can be a property then fine. But why not go directly for > __unicode__ in that case? > > - Anssi > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.user refactor: the profile aproach
On Monday, April 2, 2012 at 10:56 PM, Alex Ogier wrote: > I realize that arguing with a BDFL might get me nowhere, but I don't think > that multi-profile + select_related + proxy attributes on the user model is > the proper approach for users going forward. The proposal makes some basic > sense as an incremental improvement on the current status quo of a built-in > user with fixed 30-character identifier and single one-to-one profile. But in > the larger scheme of things it moves further in the wrong direction, in my > opinion, towards a model that addresses people's specific 80% questions > (email-as-identifier, packageable extra fields) but not the general > best-of-all-worlds mechanisms. > > Consider the other batteries-included frameworks out there. I think the three > biggest ones are probably Ruby on Rails, ASP.NET (http://ASP.NET) MVC, and > Play Framework. Something all three have in common, something I think would > be valuable for Django, is that their User identity is absent, and > authentication and authorization modules are added to a developer-created > User model ad-hoc. I think it's fair to say, the ecosystem of third-party > authentication mechanisms surrounding all three of these competitor > frameworks is MUCH healthier than Django's, for the simple reason that it is > much more flexible and sane to define your own user and plug in an > authentication module then it is to plug authentication into a fixed user > model that magically proxies back (even one as simple as a varchar identity + > password). > > The basic idea is that "authentication" is something that can be provided for > any model you like. When a user authenticates, they are providing some sort > of authentication token to your project that proves they are who they say > they are, and as a developer you are free to attach this authentication token > to *whatever you like,* not only contrib.auth.models.User. There is a rich > ecosystem of third party authentication apps for our competitor frameworks > that all work on this principle. They can provide authentication flows that > bounce the user back and forth to twitter.com (http://twitter.com), their > oauth provider, browserid, etc. and it is precisely because they don't demand > anything from a central object. Even something as simple as "all > user.identifiers that start with 'oauth2$' belong to our auth mechanism" > starts to open all sorts of security holes. What if someone wants to > authenticate by email+password OR by third party proof of email ownership (my > university has a mechanism like this)? Well, if someone can manage to register an account belonging to 'aog...@princeton.edu (mailto:aog...@princeton.edu)', maybe by triggering some obscure email change recovery form wizard or something, then suddenly they possess my account on Django. > > This is why I think the only sane long-term solution involves distinct and > pluggable authentication modules, and a concept of users that doesn't enforce > any brand of identity. The second stipulation is very important for social > reasons, if only to ensure that the path of least resistance for third-party > authentication doesn't involve trying to overload identity mechanisms for > disparate and incompatible purposes. > > JKM, you seem concerned that the notion of pluggable Users by necessity > involves magical settings. > > > I'm convinced that such an idea is ultimately a bad idea: it allows apps > > exert action at a distance over other apps. It would allow the idea of a > > user to completely change without any warning simply by modifying a setting. > > I am not convinced that this must be so. Asking a developer to write their > own User model is not the same thing as automagically reshaping > contrib.auth.models.User based on settings. A developer-defined notion of > identity is a thing that should be codified in software by constructing a > model. This community seems fixed on the idea that whatever model the > developer comes up with to satisfy the bizarre constraints of his particular > website, it must eventually be mounted at auth.User lest the world come > crashing down as foreign keys break, middleware throws exceptions and > California slides into the pacific ocean. > > Nearly every other framework out there does this the opposite way: to > authenticate with a third-party service, you add fields to your identity > model to support whatever credentials are necessary. Not the other way round, > where auth modules define models that have OneToOneFields to auth.User that > uses an AUTH_PROFILES setting to magically proxy back. > > I get that Django's core is very accustomed to the relational database mode > of thinking: "If a User might own a Twitter handle, then let's create a table > of twitter handles in the twitter-auth app, and foreign key back to the > default User model". It's really not that bad to go the other way for a > moment, and
Re: auth.user refactor: the profile aproach
On Tuesday, April 3, 2012 at 3:37 AM, Tai Lee wrote: > I like this proposal because I am a big fan of a stripped down `User` model > which is basically just an ID, whic provides a common hook into > groups/permissions and other django and 3rd party profiles. > > What I don't like is the magical `data` bag (accessing `User.data` and filter > lookups), the new `AUTH_PROFILES` setting, and the idea of Django > automagically or lazily creating profiles for me. I would rather see Django > rely solely on its `OneToOneField` field to access user profile data. > > Any pluggable app (app1) will know what fields it's own profile model has and > how to access them, relative to the central `User` object. > > If app1 relies on fields defined by another app (app2), that other app should > be a requirement of app1 and app1 would know how to access app2's fields. > > I am happy to use project-level signals for everything else (syncing common > profile data from app1 and app2, or auto-creating user profiles), because > project-level signals give me explicit control over what is going to happen > and when. I don't need any more magic here. > > Cheers. > Tai. Without the `data` bag we've done nothing except rename the username field and make it longer really. Everything else that you define can already be achieved by ignoring the fields already on User and using OneToOneFields. With the `data` bag we allow a pattern kinda similar to class inheritance. I think you also mistake the use case, it's not app1 relies on app2, it's app1 relies on _a_ field called email that provides an email address. It doesn't care where it comes from. If we do not provide a common way to access this data with this proposal, than a large number of apps are going to depend on the default profile, and we are stuck again here where everything depends on what Django Core decides for "first_name", "last_name", email length, etc. > > > On Tuesday, 3 April 2012 10:35:41 UTC+10, Jacob Kaplan-Moss wrote: > > Hi folks -- > > > > I've written up a proposal for how *I* would like to address refactoring > > auth.user: https://gist.github.com/2245327. > > > > In essence, this does two things: > > > > * Vastly "prunes" the required fields on auth.user. The only things left > > are an "identifier" (which could be username, email, url, uuid, whatever), > > and a password. > > * Introduces a new "profile" system that provides a way to contribute extra > > related fields. Multiple profiles are supported, along with some syntactic > > sugar for dealing with multiple profiles in a reasonably reusable way. > > > > And that's about it. I'm deliberately trying to find a middle ground > > between "do the minimum to allow people to move on" and "throw out and > > rewrite django.contrib.auth entirely". I'm not expecting everyone to be > > thrilled by this idea, but I'm hoping that this is "Good Enough" for almost > > everyone. > > > > For more please see the document. Please do try to read the whole thing: > > I've had a few rounds of feedback incorporated already, and there's even an > > FAQ at the end. > > > > I'm not using BDFL fiat here, at least not yet. This is a proposal, and I > > very much want to hear feedback, objections, and alternatives. I'm > > particularly interested in hearing from people who've got complicated auth > > needs and think this absolutely won't work for them. > > > > I *have* reviewed all the other proposals and I'm between -0 and -1 on all > > of them. This means that if you don't like my proposal, you'll probably > > have to come up with a complete *new* idea to have any chance of getting my > > vote. > > > > Thanks! > > > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/PMpcPCKgTuoJ. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.user refactor: the profile aproach
Like Carl I was +1 on Profiles and I'm now leaning towards the Swappable User
Models.
It's explicit (it only changes when you change the USER_MODEL setting).
It's Duck Typing which is Idiomatic in Python. ("This app depends on a user
model that defines ``email`").
If you wish to add OpenID you'd make your UserModel quack like an OpenID Duck,
as well as Quack like a Username/Password Duck.
On Tuesday, April 3, 2012 at 4:34 PM, Daniel Sokolowski wrote:
> Alex I have looked over your proposal and I agree on both your concerns with
> LFK, and Jacob’s approach; however I still find the profile approach is the
> most flexible solution.
>
> Correct me if I’m wrong but both LFK or a swappable user model approach like
> your fail to address issue of extensibility. If today my project is
> authorizing with username and password and tomorrow I wish to add OpenAuth
> then my User model is replaced, whereas with Jacobs approach I add another
> profile model, yes? What about auth apps, you could only use one, with
> profiles many could co exist; one for Facebook, Twitter, etc.
>
> Your point 4 claiming it’s undiscoverable is not entirely true, AUTH_PROFILE
> setting can be examined just as apps examine INSTALLED_APPS settings at run
> time. Your point 2 that being able to change the functionality so quickly is
> actually superior in my mind, it’s a lot more work to do a schema migration
> then the creation a of new profile table. Points 5 and 3 are good points
> and remind that there is no perfect solution to new auth.
>
> To sum up I am curious to know how your approach handles additional user data
> and authorization schemes.
>
> From: Alex Ogier (mailto:alex.og...@gmail.com)
> Sent: Tuesday, April 03, 2012 10:28 AM
> To: django-developers@googlegroups.com
> (mailto:django-developers@googlegroups.com)
> Subject: Re: auth.user refactor: the profile aproach
>
>
>
>
> Hi developers,
>
> I have written up a little bit about the alternate proposal that I made a
> while ago, Solution 2a from
> https://code.djangoproject.com/wiki/ContribAuthImprovements
>
> In addition to other arguments, there is a point-by-point breakdown of what I
> feel are the weaknesses in Jacob's proposal.
>
> You can find it at https://gist.github.com/2289395
>
> Best,
> Alex Ogier
>
> On Mon, Apr 2, 2012 at 8:35 PM, Jacob Kaplan-Moss (mailto:ja...@jacobian.org)> wrote:
> > Hi folks --
> >
> > I've written up a proposal for how *I* would like to address refactoring
> > auth.user: https://gist.github.com/2245327.
> >
> > In essence, this does two things:
> >
> > * Vastly "prunes" the required fields on auth.user. The only things left
> > are an "identifier" (which could be username, email, url, uuid, whatever),
> > and a password.
> > * Introduces a new "profile" system that provides a way to contribute extra
> > related fields. Multiple profiles are supported, along with some syntactic
> > sugar for dealing with multiple profiles in a reasonably reusable way.
> >
> > And that's about it. I'm deliberately trying to find a middle ground
> > between "do the minimum to allow people to move on" and "throw out and
> > rewrite django.contrib.auth entirely". I'm not expecting everyone to be
> > thrilled by this idea, but I'm hoping that this is "Good Enough" for almost
> > everyone.
> >
> > For more please see the document. Please do try to read the whole thing:
> > I've had a few rounds of feedback incorporated already, and there's even an
> > FAQ at the end.
> >
> > I'm not using BDFL fiat here, at least not yet. This is a proposal, and I
> > very much want to hear feedback, objections, and alternatives. I'm
> > particularly interested in hearing from people who've got complicated auth
> > needs and think this absolutely won't work for them.
> >
> > I *have* reviewed all the other proposals and I'm between -0 and -1 on all
> > of them. This means that if you don't like my proposal, you'll probably
> > have to come up with a complete *new* idea to have any chance of getting my
> > vote.
> >
> > Thanks!
> >
> > 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
> > (mailto:django-developers@googlegroups.com).
> > To unsubscribe from this group, send email to
> > mailto:django-developers%2bunsubscr...@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-developers@googlegroups.com
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> (mailto:django-developers+unsub
Re: auth.user refactor: the profile aproach
On Wednesday, April 4, 2012 at 12:20 PM, Adrian Holovaty wrote: > On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss (mailto:ja...@jacobian.org)> wrote: > > On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > > > > My point is that there is nothing about this problem that is unique to User. > > Django's own codebase contains another example of exactly the same pattern > > -- Comments. > > > > As the original author and designer of that pattern, I should probably point > > out that I now think it's a mistake. Have you actually tried using it? It > > doesn't really work very well. Every time I've introduced any sort of > > "swappable model" mechanism I've come to regret it. > > > > > Totally agree with Jacob here, plus Tai's comment that "There is such > a thing as too generic." We've made the mistake of making things too > generic in the past, and it's kind of infuriating in retrospect, both > philosophically and in terms of code maintenance/understanding. > (django/utils/tree.py, anyone??) > > I think our policy should be: make the simplest thing that can > possibly work for a narrowly-tailored use case, then make things more > generic *slowly* if there's a demand. No need to be an Architecture > Astronaut. > > Not adding anything, just saying that Architecture Astronaut is the best term ever for this. > > Adrian > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.user refactor: the profile aproach
Nothing about this proposal prevents this. And in that case, no those 2 apps would not be able to be used together. But this is hardly the first time that 2 apps cannot be used together. because of choices made like that on the app owner. On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote: > I very much share Tai's concerns about the swappable user model introducing > incompatibilities. Imagine two apps, each of which requires an "age" > attribute on the user model. But suppose one of those apps expects age to be > the number of years since that user's birth and one of those apps expects the > age to be the number of years since the user registered for the website. The > user model must provide the same attribute to both apps, but it is supposed > to have a different value for each app. A developer will be unable to use > these two apps together without patching one of them. > > A bit of a contrived example, maybe, but I can imagine this > same-name-different-purpose issue coming up over and over again, making > otherwise pluggable apps incompatible with each other. > > I think we should go with a pared down user model and allow each app to > manage whatever data it needs on each user through profiles and signals. > Developers will end up with some data duplication, but I think that is > preferable to confusion about the source and purpose of data. Profiles are > essentially a way for each app to namespace its own data and I think that's a > good thing. > > Harris > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/p4jhylEp3x8J. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: auth.user refactor: the profile aproach
I think swappable user models should be used as a replacement for get_profile() not per app profiles. It should be used for generic-esque data about a User. e.g. Email, phone number, name, etc. It should not be used for app specific data about a user, e.g. Default Gallery, Notification Settings, etc. On Tuesday, April 10, 2012 at 6:01 PM, Tai Lee wrote: > Alex, > > I think the problem with this aspect of your proposal is that it signals a > green light for other pluggable apps to follow Django's lead and provide > mixing which must be added to their `User` model in order to use the > pluggable app, instead of creating a profile model for their pluggable app. > > Django's admin is a pluggable app, and it should follow the best practices > that we recommend for authors of other pluggable apps. > > It has been suggested that "nothing is stopping pluggable app authors from > continuing to use profiles", but on the flip side, nothing is going to stop > them from using mixins and requiring a schema migration to install their > pluggable app. > > If we allow swappable models, we should strongly recommend (in documentation, > and by example with the admin) that pluggable app authors continue to use > profiles, and that only project authors use the ability to swap in a new > `User` model for their own purposes, and not to support a pluggable app. > > Cheers. > Tai. > > > On 11/04/2012, at 3:25 AM, Alex Ogier wrote: > > Tom, > > I proposed mixins to solve the specific problem: there is an app that needs > > a specific contract from a model it wants to authenticate or otherwise > > interact with, how can we make it easy for developers to implement that > > contract? > > Most apps don't actually need that much though. There are a bunch of > > standard ways to relate to a model that don't invasively change it. They > > are all still available, and in fact preferred because no matter how easy > > it is to use a mixin, doing nothing is even easier. > > Best, > > Alex Ogier > > On Apr 10, 2012 10:58 AM, "Tom Evans" > (mailto:tevans...@googlemail.com)> wrote: > > > On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis > > (mailto:ianmle...@gmail.com)> wrote: > > > > Hi, > > > > > > > > I'm not getting why you *have* to add fields to the User model to store > > > > data > > > > pertaining to the user. There is nothing in the proposal for pluggable > > > > user > > > > models that says you can never have a seperate model with a foreign key > > > > to > > > > the user model. It just means that you can define your user model the > > > > way > > > > you want it to be. > > > > > > That is perfectly fine. The problem comes when there is a simple > > > system to add fields to the user model, people will use it to add > > > fields to the user model in their pluggable apps, for 'simplicity' and > > > 'ease of use'. > > > > > > > Why can't third party apps have a model with a foreign key to the user > > > > table > > > > with the pluggable models approach? I imagine you are right that every > > > > app > > > > and it's brother adding fields to the user model is not realistic but I > > > > don't think that anyone has proposed that. Certainly not me. > > > > > > The proposed solution as decided by BDFL diktat is 2a from [1]. I quote: > > > > > > Split off as much as possible of auth.User into orthogonal mixins that > > > can be reused. > > > Modify auth.User to inherit these mixins. Care must be taken to ensure > > > that the database expression of the new User model is identical to the > > > old User model, to ensure backwards compatibility. > > > Unrelated and third-party apps can indicate that they depend on > > > various orthogonal mixins. For example, contrib.admin can specify that > > > it works with auth.User out of the box, and with any model > > > implementing PermissionsMixin if you supply your own login forms. > > > > > > At the moment, you cannot change the user model, so we do not have > > > issues relating to third party apps changing the user model. With the > > > proposed solution, you would be able to change the user model, so we > > > may have issues. > > > > > > It's also enlightening to read the code from Alex's Django branch, > > > which is an initial implementation of option 2a. > > > > > > > The thing I > > > > want to be able to is define user models suitable for my project. Third > > > > party apps adding their own fields wasn't proposed by anyone AFAIK, nor > > > > was > > > > specifically requiring that you add them yourself. Some might require > > > > that > > > > your user has something like an 'email' field because that would be a > > > > common > > > > field across apps but app specific data can easily go on a seperate > > > > model > > > > included with the app that simply has a FK to user. You can then only > > > > fetch > > > > that data on requests that need it. > > > > > > > > I'm sorry but doing a JOIN every request is a BAD idea. You will run > > > > int
Re: auth.user refactor: the profile aproach
Sorry I was mentioning that in agreement with documenting this. I had even toyed with the idea of making the default template provide a project level user model by default (to cement the fact that it's project concern not a app concern) but that is most likely more trouble than it's worth. On Tuesday, April 10, 2012 at 6:34 PM, Tai Lee wrote: > Sure. But will how will users be guided to making that distinction when > developing their pluggable apps? I haven't seen anything that would prevent > developers from doing this, and if the admin itself does it, isn't that a > green light for everyone to do it? > > Another problem with pluggable apps (like the admin) adding fields to the > `User` model is that they make an assumption that *every* user is a user of > that particular pluggable app. > > I use the admin, but not *every* user has access to the admin. Those users > shouldn't need to have values (even default values, e.g. is_staff=False) for > admin-specific fields, and admin-specific fields shouldn't be selected every > time any user is retrieved from the database. > > Cheers. > Tai. > > > On 11/04/2012, at 8:05 AM, Donald Stufft wrote: > > I think swappable user models should be used as a replacement for > > get_profile() not per app profiles. > > > > It should be used for generic-esque data about a User. e.g. Email, phone > > number, name, etc. > > > > It should not be used for app specific data about a user, e.g. Default > > Gallery, Notification Settings, etc. > > > > On Tuesday, April 10, 2012 at 6:01 PM, Tai Lee wrote: > > > > > Alex, > > > > > > I think the problem with this aspect of your proposal is that it signals > > > a green light for other pluggable apps to follow Django's lead and > > > provide mixing which must be added to their `User` model in order to use > > > the pluggable app, instead of creating a profile model for their > > > pluggable app. > > > > > > Django's admin is a pluggable app, and it should follow the best > > > practices that we recommend for authors of other pluggable apps. > > > > > > It has been suggested that "nothing is stopping pluggable app authors > > > from continuing to use profiles", but on the flip side, nothing is going > > > to stop them from using mixins and requiring a schema migration to > > > install their pluggable app. > > > > > > If we allow swappable models, we should strongly recommend (in > > > documentation, and by example with the admin) that pluggable app authors > > > continue to use profiles, and that only project authors use the ability > > > to swap in a new `User` model for their own purposes, and not to support > > > a pluggable app. > > > > > > Cheers. > > > Tai. > > > > > > > > > On 11/04/2012, at 3:25 AM, Alex Ogier wrote: > > > > Tom, > > > > I proposed mixins to solve the specific problem: there is an app that > > > > needs a specific contract from a model it wants to authenticate or > > > > otherwise interact with, how can we make it easy for developers to > > > > implement that contract? > > > > Most apps don't actually need that much though. There are a bunch of > > > > standard ways to relate to a model that don't invasively change it. > > > > They are all still available, and in fact preferred because no matter > > > > how easy it is to use a mixin, doing nothing is even easier. > > > > Best, > > > > Alex Ogier > > > > On Apr 10, 2012 10:58 AM, "Tom Evans" > > > (mailto:tevans...@googlemail.com)> wrote: > > > > > On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis > > > > (mailto:ianmle...@gmail.com)> wrote: > > > > > > Hi, > > > > > > > > > > > > I'm not getting why you *have* to add fields to the User model to > > > > > > store data > > > > > > pertaining to the user. There is nothing in the proposal for > > > > > > pluggable user > > > > > > models that says you can never have a seperate model with a foreign > > > > > > key to > > > > > > the user model. It just means that you can define your user model > > > > > > the way > > > > > > you want it to be. > > > > > > > > > > That is perfectly fine. The problem comes when there is a sim
Re: GitHub migration planning
Github Issues are not flexible enough for Django. On Wednesday, April 18, 2012 at 6:53 PM, Alex Ogier wrote: > On Wed, Apr 18, 2012 at 6:46 PM, Dalton Barreto (mailto:daltonma...@gmail.com)> wrote: > > Em 18 de abril de 2012 18:44, philipn > (mailto:phil...@gmail.com)> escreveu: > > > Hey folks! > > > > > > I started a wiki page to help plan a migration to GitHub: > > > > > > https://code.djangoproject.com/wiki/GitHub%20Migration > > > > > > I don't know what I'm doing, but I do know that the current Trac setup > > > (attaching patches, etc) is less accessible to non-core contributors than > > > GitHub and I'd love to do anything I can to help make this better. > > > > > > > > > Maybe the best way to avoid that people create issues on github is to > > disable it for the > > official repository. This is possible through the Github's Admin interface. > > > > > Err, I think the point was that Trac is less accessible than Github so > Django *should* be using Github Issues instead. > > Best, > Alex Ogier > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: GitHub migration planning
Github issues do not have the ability for anyone to close, tag, or create milestones. You have to be the creator of the ticket or someone with commit access. Django's track instance allows anyone to participate in this way and is one of the major reasons to my knowledge that Django will keep it's trace instance. On Wednesday, April 18, 2012 at 7:39 PM, Łukasz Rekucki wrote: > On 19 April 2012 00:55, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > Github Issues are not flexible enough for Django. > > > That's rather a vague statement. Github issues are actually more > *flexible* then Trac as you can define any set of tags for an issue. > What Django could possibly want to have is a way to create extra > constraints on the tags, but as a matter of fact, the current Trac > instance doesn't do that! (you can have an issue with "tests needed" > but without "patch needs improvement"). > > -- > Ł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-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: GitHub migration done!
Pretty sure this isn't going to make a compatible with the existing mirror mirror but http://hg-git.github.com/ should make it easy to go from git -> hg. On Tuesday, May 1, 2012 at 12:39 PM, Carl Meyer wrote: > On 05/01/2012 12:45 AM, Vinay Sajip wrote: > > On May 1, 2:19 am, Carl Meyerhttp://oddbird.net)> wrote: > > > Good point. I think which of those happens now depends on whether a > > > motivated someone steps up to figure out how to convert the mirror to > > > use hg-git and source from Git, and then maintain it as needed. I > > > originally did the current mirror, and it really hasn't needed any > > > maintenance over the past two years, but I no longer use Mercurial or > > > the Mercurial Django mirror, so that "motivated someone" is not likely > > > to be me this time around. > > > > > > > > > I don't mind doing it, if it's sufficiently low-maintenance, > > I can't speak for how it will be with hg-git (there is a bit more > potential complexity since the source repo is not simple and linear like > Subversion), but hgsubversion has required exactly zero maintenance > since I first set it up. > > > and I do > > use Mercurial as well as Git. Did you implement it using a local repo > > and a cron job, or was there something else you used which was more > > purpose-built? > > > > > It's just a cron job and a local repo using hgsubversion; every five > minutes it pulls the latest from Subversion and pushes it to Bitbucket. > The repo and cron job are hosted on the djangoproject.com > (http://djangoproject.com) server. If you > are able to get the conversion from git working and repeatable on a > local repo, I think Jacob can probably get you hooked up to host it on > djangoproject.com (http://djangoproject.com) (which also has an ssh key with > permission to push to > bitbucket.org/django/django (http://bitbucket.org/django/django)). > > The tricky bit will be making the switch to sourcing from git in a way > that doesn't change all the historical commit hashes, making the new > mirror repo merge-incompatible with the current mirror (and all clones > of it). It's possible there will be no way to do that, in which case I > guess a new incompatible mirror is still better than no mirror at all. > > Carl > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Djangopeople.net status
djangopeople.me ? On Thursday, May 10, 2012 at 7:39 PM, Russell Keith-Magee wrote: > On Thu, May 10, 2012 at 8:55 PM, Bruno Renié (mailto:bubu...@gmail.com)> wrote: > > On Thu, May 10, 2012 at 8:04 AM, Russell Keith-Magee > > mailto:russ...@keith-magee.com)> wrote: > > > On Thu, May 10, 2012 at 9:19 AM, Aaron C. de Bruyn > > (mailto:aa...@heyaaron.com)> wrote: > > > > On Wed, May 9, 2012 at 1:37 PM, Alex Sosnovskiy > > > (mailto:alecs@gmail.com)> wrote: > > > > > > https://convore.com/djangopeoplenet-development/ - gives http404 > > > > > > > > > > > > > > > Djangopeople.net (http://Djangopeople.net) is dead? > > > > > > > > > > If to be honest I don't understand you, guys! What's the profit of > > > > > rewriting > > > > > views to class-based if djangopeople.net (http://djangopeople.net) is > > > > > down for a year ? > > > > > > > > > > > > > > > > > > > > > > > > > That's because the rewritten code has never been deployed. > > > > > > Look at the whois record for djangoproject.com > > > > (http://djangoproject.com) verses > > > > djangopeople.net (http://djangopeople.net). I don't think > > > > djangopeople.net (http://djangopeople.net) is officially part > > > > of Django. > > > > > > > > > > > > > I can confirm for you -- djangopeople.net (http://djangopeople.net) has > > > never been an "official" > > > part of the Django project. It was always an effort run outside of the > > > official (although Simon, the original developer, is a Django core > > > developer). > > > > > > That said, I'm still interested in making djangopeople.net > > > (http://djangopeople.net) an official > > > resource of the Django project. It was a very useful resource in it's > > > time, which I for one miss. If anyone is interested (including Bruno, > > > if he's still interested) in managing the project for the long term, > > > let me know. > > > > > > > > > I am still interested, the issue right now is to get admin access to > > the djangopeople.net (http://djangopeople.net) DNS records and an > > up-to-date dump of the data. > > Regarding that, Simon Willison is pretty hard to reach and the best > > way to contact him is via Andew Godwin who can talk to him IRL. But as > > you may know, they're both busy people so that's why we're in the > > current situation. > > > > > I'll shake the tree again and see what I can do. > > Another option would be to start from scratch; if we're making the > official, we could host you at people.djangoproject.com > (http://people.djangoproject.com), start with a > clean database, and use the blog/mailing list/etc to get the word out > and repopulate the database. It's less than ideal, but it would get > over the hurdle. After all, we're perfectionists with deadlines :-) > > > There is also the issue of hosting, at the time Andrew was happy to > > host the rebirth of djangopeople.net (http://djangopeople.net) on ep.io > > (http://ep.io) but since it's closing > > down we'd have to find another option. > > > > > As Jacob noted, the DSF can help out here. If you can come up with an > estimate of what you need, I can put it to the board and get you those > resources. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django git guidelines
On Friday, May 18, 2012 at 11:04 AM, Carl Meyer wrote: > Hi Anssi, > > Thanks for working on git usage guidelines! I very much agree that a > pull request should only be created when the contributor considers the > branch finished and ready for review and merge (for instance, there > should never be a pull request created without the necessary docs and > tests). Having lots of half-finished pull requests in the queue is a > burden on everyone. > > On 05/18/2012 05:38 AM, Anssi Kääriäinen wrote: > > The take above is that topic branches published on github are nothing > > more than a way to publish a patch set. They are _not intended for > > others to work upon_. The main problem I have with assuming the github > > branches should never be rebased is this: > > 1. A developer publishes some work on github > > 2. A reviewer spots some minor issues (typos, whitespace issues, > > pep-8 issues). > > x. > > 4. Committer merges the final work into master branch. > > > > Now, the issue is what should the original developer do in step x.? He > > could do the fixes and add a commit. However, we do not want (possibly > > multiple) extraneous "whitespace cleanup" commits in there. So, the > > branch needs to be rebased. Other option is that the committer does a > > squash merge of the work. The clearest example why we can't just merge > > the full history is that there might be commits which break Django > > totally and these commits must not be merged to master. > > > > > I think you've correctly identified the two options here: rebase or > squashed merge.* I'm not sure it's clear that rebase is the better > choice of those two. > > Advantages of rebase: > > * The contributor gets their own name on the final commit to master. > > * Less work for committers, more work for contributors (arguable whether > this is an advantage or disadvantage). > > Advantages of squashed merge: > > * Line-by-line code comments on the pull request (and in general, > in-context history of the development of the pull request) are not lost > every time the contributor rebases and force-pushes. > > * We don't ask every contributor to Django to learn advanced > history-rewriting features that some find difficult to use, and that > lead to more risk of data loss (or at least perceived data loss for > users who aren't familiar with the magic of the ref-log). Only core > committers need to use an advanced feature of git. > > All in all, I would be -1 on making rebase a required part of > contributing to Django. I would prefer to leave this choice up to the > contributor, and say something like: > > "If you want your own name on the final commit in master, feel free to > rebase your pull request down to a single commit with a well-formatted > commit message. Otherwise, we will 'merge --squash' your pull request > into a single commit on master, and credit you in the commit message." > > Carl > > > *The third option, just doing regular merges of multiple-commit pull > requests, I don't think is nearly as bad as you make it out to be: > master would never actually be in a broken state for anyone tracking it, > even if there were broken halfway states in the merged branch, and it is > possible to track the "main line" of development back through each merge > commit, without ever touching any broken or in-progress commits. But > those in-progress commits would still be in the repo, and would be shown > by default by "git log" and e.g. the github commit list - I agree that > this makes it harder to quickly scan meaningful changes in the history, > and is not preferable. > > I personally prefer doing normal merges with --no-ff. While "clean up whitespace" commits are extraneous, they don't particularly hurt anything. If an incoming pull request is particularly messy it's easy enough to say that the pull request is sound in theory/implementation but that they need to rebase it to clean up the history. > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django git guidelines
On Friday, May 18, 2012 at 12:30 PM, Anssi Kääriäinen wrote: > On May 18, 6:08 pm, Donald Stufft (http://gmail.com)> wrote: > > I personally prefer doing normal merges with --no-ff. While "clean up > > whitespace" > > commits are extraneous, they don't particularly hurt anything. If an > > incoming pull > > request is particularly messy it's easy enough to say that the pull request > > is > > sound in theory/implementation but that they need to rebase it to clean up > > the history. > > > > > While the white space commits aren't that serious, there are a couple > of issues which need rebasing: > - If we aim to have well formatted commit messages, any bad commit > messages must be rewritten by changing history. Git ensures there > isn't any other way. > - I believe merging in broken states (code doesn't compile etc) will > make bisecting much harder. I am not sure of this... > - I don't find it particularly good idea to have 10 lines patches > come in in 5 commits when just a single one is required. If you looks > at the pull requests, you will see this is not far fetched. > > I think here is where it's going to come down to judgement calls. If their is an undue amount of extraneous commits for small patches then sure either rebasing or squashing probably makes sense. (Or rejecting telling the author to clean up their history). Commits broken for reasons other then what you are bisecting for make bisect a tad bit harder but not terribly so, basically you'd just take a peek at the log and switch to a nearby commit and test that one instead. > > > - Anssi > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django git guidelines
On Friday, May 18, 2012 at 1:40 PM, Alex Ogier wrote: > I am +1 on merge --squash. The reason is that there is tremendous > value to having a mostly linear mainline development branch, > especially for one so widely depended on as Django's. My feeling is > that we should aim to have the official branches consist of only those > commits that we would feel comfortable checking out and developing > with. It is much nicer to run "git log" and see a series of focused > bug fix patches than it is to see a tangle of "Fix the reticulating > splines by frobbing the axis" "Oops, the axis was already fixed, > revert that commit" "Do the real work in hobnob.py". > > In addition to making automated git bisects possible, it also lowers > the bar for contributions: so long as the code changes in a pull > request are sound, we can accept fragmented histories and badly > formatted commit messages and put the onus on the committers to clean > up commit messages for posterity. > > In my experience, squash makes git bisect harder, instead finding the bad commit to be a small, atomic change, you're often given a large change where you must then determine which change out of the entire commit caused the issue. > > Best, > Alex Ogier > > On Fri, May 18, 2012 at 12:48 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > On Friday, May 18, 2012 at 12:30 PM, Anssi Kääriäinen wrote: > > > > On May 18, 6:08 pm, Donald Stufft > (http://gmail.com)> wrote: > > > > I personally prefer doing normal merges with --no-ff. While "clean up > > whitespace" > > commits are extraneous, they don't particularly hurt anything. If an > > incoming pull > > request is particularly messy it's easy enough to say that the pull request > > is > > sound in theory/implementation but that they need to rebase it to clean up > > the history. > > > > > > While the white space commits aren't that serious, there are a couple > > of issues which need rebasing: > > - If we aim to have well formatted commit messages, any bad commit > > messages must be rewritten by changing history. Git ensures there > > isn't any other way. > > - I believe merging in broken states (code doesn't compile etc) will > > make bisecting much harder. I am not sure of this... > > - I don't find it particularly good idea to have 10 lines patches > > come in in 5 commits when just a single one is required. If you looks > > at the pull requests, you will see this is not far fetched. > > > > I think here is where it's going to come down to judgement calls. If their > > is an > > undue amount of extraneous commits for small patches then sure either > > rebasing > > or squashing probably makes sense. (Or rejecting telling the author to clean > > up their history). > > > > Commits broken for reasons other then what you are bisecting for make bisect > > a tad bit harder > > but not terribly so, basically you'd just take a peek at the log and switch > > to a nearby commit and > > test that one instead. > > > > > > > > - Anssi > > > > -- > > 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 > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto: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-developers@googlegroups.com > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto: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-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django's CVB - Roadmap?
I tend to agree, in general, with the reply that there should be a function based api to cover the 80% use case, but in the case of Django's CBV's this is likely covered by the as_view method. On Friday, June 1, 2012 at 10:54 AM, Jacob Kaplan-Moss wrote: > On Fri, Jun 1, 2012 at 10:14 AM, Victor Hooi (mailto:victorh...@gmail.com)> wrote: > > The reason for my post - is there anything from the Django core as a whole > > on this? What's the future roadmap like in terms of CBV's? Are there going > > to be any changes to it, or are we safe to assume things will be as they are > > now. > > > > > I think as a whole we're divided. Luke's opinions differ from > mine, and it's entirely unclear to me who's "right" or even if there's > a "right" to be had. And that's just the two of us! > > I think this might be a situation where we need some more feedback > from the community and some more time to decide what the right move > here is. > > So... what do *you* think? > > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django's CVB - Roadmap?
On Tuesday, June 5, 2012 at 9:05 AM, Albert O'Connor wrote: > My feeling is that though some people might have uses for CBV, we > shouldn't be suggesting that developers should prefer CBV to function > based views. When it comes to maintainability, FBV are better, and I > would agree that they are more Pythonic. > > When I tried to use CBV, I found the inheritance semantics lead to > unexpected results when composing mixins. I wanted to spend my time > creating web apps and not debugging to figure what 3 lines of glue > code I would have to write in the correct overridden method to make > CBV work for me in my usecase. At the time I felt of have a list of > say context providers would have made more sense than mixins. > > Don't confuse the current Generic Class Based Views with Class Based Views in general. In almost every case Class Based Views are a net win, it's the generic views that are often the incorrect choice (as it makes sense, if what your view is doing isn't generic, then a Generic view isn't what you need). > > If people have uses for CBV, they should be available, but advocating > that more builtin or contrib views should be made class based is > something I would be against personally, unless it really made sense > in a specific use case. > > Albert O'Connor > > On Tue, Jun 5, 2012 at 2:02 AM, Marc Tamlyn (mailto:marc.tam...@gmail.com)> wrote: > > There is a plan to do some work on the docs at the djangocon sprints - in > > particular trying to get some examples of when you 'could' and when you > > 'should not' use the generic CBVs. > > > > With regards to Zach's point about TDD testing - some of that may simply be > > familiarity. I don't know about you but it would have been very difficult > > for me to get into successfully TDDing a functional view until I'd written > > several dozen views and knew what the pattern is. You can still test the CBV > > top to bottom, exactly as you would with a function based view. Yes there > > may be some shift to conventions, but that will come with familiarity. > > > > I think part of the important difference is that when you look at a CBV for > > the purposes of unit testing it, you feel very quickly that you should be > > testing the individual methods. This is actually really nice and gives a lot > > more branch-coverage without rerunning the same 4 database queries every > > time for variables which aren't used. Without CBVs a complex view can easily > > extend over 50 or so lines, whereas it's more natural to split this up and > > test the sections independently with a Class based system. I know in general > > we should be 'writing less view code' and pushing the logic elsewhere, but > > that depends on what that logic is - for example the view layer needs to > > decide whether to return JSON or HTML depending on certain headers in the > > request, and that is more easily testable as an overridden render to > > response method than as the last 4 lines of a 50 line view. > > > > Marc > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/django-developers/-/VZsGxxTYyoIJ. > > > > To post to this group, send email to django-developers@googlegroups.com > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto:django-developers+unsubscr...@googlegroups.com). > > For more options, visit this group at > > http://groups.google.com/group/django-developers?hl=en. > > > > > > > -- > > <><><>< Albert O'Connor - amjoc...@gmail.com (mailto:amjoc...@gmail.com) > > albertoconnor.ca | wildernesslabs.ca | watpy.ca > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django's CVB - Roadmap?
On Tuesday, June 5, 2012 at 9:29 AM, Albert O'Connor wrote:
> Class Based View are awesome, except the ones which are built in?
>
>
Both the Built in Generic Class Based Views, and Class Based Views
in general are great. Generic Class Based Views are not awesome when
your view is not generic.
>
> I agree, as has been suggested, that if you make a really flat class
> based views like the admin itself, you can gain some benefits, but I
> still think those benefits are heavily tied to assumptions one can
> make in a specific problem space. Keeping the ability to create a
> Class Based View has value, but it is up to to the people who like
> them to show the rest of us how they can be used with out creating
> more problems then they solve, and just because they exist doesn't
> mean they should be used more than they are. Apparently when it comes
> to generic class based view they should be used less.
>
>
The typical FBV that i've personally witnessed ends up being one large
chunk of code where it's both impossible to reuse, but slightly differently,
in a way that the original view didn't give you, and impossible to test small
"units" of functionality.
My best guesses as to why most people tend to write this way is because
people like their views to be "one unit". For function based views that unit
is one function and for class based views that unit is one class.
The difference then lies in that within a class it is very easy to have multiple
"sub units" (methods) that can each be dedicated to one purpose, and can
easily be tested independently.
Outside of the testing benefits, you now have a view where you can easily
modify one "sub unit" without having to reach in and rewrite part of the view.
An example would be, with the generic views, it's the pattern to have a
"get_queryset" method which returns the queryset that the view will work off
of. With a simple Mixin of::
class UserMixin(object):
user_field_name = "user"
def get_queryset(self, *args, **kwargs):
qs = super(UserMixin, self).get_queryset(*args, **kwargs)
qs = qs.filter(**{self.user_field_name: self.request.user if
self.request.user.is_authenticated() else None})
return qs
We now have the ability to "reach" into, and add filtering by the currently
logged
in user to any view that uses the get_queryset method in this way. This means
that I could write a view that returns all of the "Widgets" in a system, and by
simply adding this Mixin to the view, create a second view that lists all of
"my" widgets.
In order to do this with FBV's i'd either need to modify the existing FBV to
accept
a parameter that says if it should filter by logged in user or not or
copy/paste
the code into a new FBV. These options can be acceptable, especially when you
control the code where those views come from. However if you do not control
that code (if it for instance, comes from Django or comes from an external
library)
now you have the ability to really make those kinds of tweaks.
>
> Albert
>
> On Tue, Jun 5, 2012 at 9:14 AM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
> > On Tuesday, June 5, 2012 at 9:05 AM, Albert O'Connor wrote:
> >
> > My feeling is that though some people might have uses for CBV, we
> > shouldn't be suggesting that developers should prefer CBV to function
> > based views. When it comes to maintainability, FBV are better, and I
> > would agree that they are more Pythonic.
> >
> > When I tried to use CBV, I found the inheritance semantics lead to
> > unexpected results when composing mixins. I wanted to spend my time
> > creating web apps and not debugging to figure what 3 lines of glue
> > code I would have to write in the correct overridden method to make
> > CBV work for me in my usecase. At the time I felt of have a list of
> > say context providers would have made more sense than mixins.
> >
> > Don't confuse the current Generic Class Based Views with Class Based
> > Views in general. In almost every case Class Based Views are a net win,
> > it's the generic views that are often the incorrect choice (as it makes
> > sense,
> > if what your view is doing isn't generic, then a Generic view isn't what you
> > need).
> >
> >
> > If people have uses for CBV, they should be available, but advocating
> > that more builtin or contrib views should be made class based is
> > something I would be against personally, unless it really made sense
> > in a specific use case.
> >
> > Albert O'Connor
> >
> > On Tue, Jun 5, 2012 at 2:02 AM, Marc Tamlyn > (mail
Re: Django's CVB - Roadmap?
On Tuesday, June 5, 2012 at 9:55 AM, Zach Mathew wrote: > I'm not suggesting that CBVs make it harder to test (I actually think it > should be no different because the tests should avoid being implementation > specific). I just feel that the pattern of testing/refactoring is different > than the typical TDD approach (one could argue that this is not necessarily a > bad thing - but that's a whole another can of worms). > > I think Marc makes a very valid point about CBVs being well suited for unit > testing. This I agree with. But I typically try to avoid unit testing as much > as possible in favour of a more "outside-in" approach (ie. integration > testing). > > For example, I would avoid unit testing the "get_context_data" method on a > CBV and instead have a test that performs a request on the view and tests the > context variables. This is going to be slower than just unit testing get_context_data. > > I'm beginning to think that the divisions on this issue among developers > might be tied to development style. This would explain why some people love > them and some people hate them. > > > > On Tuesday, June 5, 2012 2:02:14 AM UTC-4, Marc Tamlyn wrote: > > There is a plan to do some work on the docs at the djangocon sprints - in > > particular trying to get some examples of when you 'could' and when you > > 'should not' use the generic CBVs. > > > > With regards to Zach's point about TDD testing - some of that may simply be > > familiarity. I don't know about you but it would have been very difficult > > for me to get into successfully TDDing a functional view until I'd written > > several dozen views and knew what the pattern is. You can still test the > > CBV top to bottom, exactly as you would with a function based view. Yes > > there may be some shift to conventions, but that will come with familiarity. > > > > I think part of the important difference is that when you look at a CBV for > > the purposes of unit testing it, you feel very quickly that you should be > > testing the individual methods. This is actually really nice and gives a > > lot more branch-coverage without rerunning the same 4 database queries > > every time for variables which aren't used. Without CBVs a complex view can > > easily extend over 50 or so lines, whereas it's more natural to split this > > up and test the sections independently with a Class based system. I know in > > general we should be 'writing less view code' and pushing the logic > > elsewhere, but that depends on what that logic is - for example the view > > layer needs to decide whether to return JSON or HTML depending on certain > > headers in the request, and that is more easily testable as an overridden > > render to response method than as the last 4 lines of a 50 line view. > > > > Marc > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/_9hq-OjYc3wJ. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django's CVB - Roadmap?
On Tuesday, June 5, 2012 at 10:35 AM, Carl Meyer wrote: > > > On 06/05/2012 08:12 AM, Donald Stufft wrote: > > In order to do this with FBV's i'd either need to modify the existing > > FBV to accept > > a parameter that says if it should filter by logged in user or not or > > copy/paste > > the code into a new FBV. > > > > > Not true, you can also have a function view that returns a > TemplateResponse, and do the same types of tweaks using reusable decorators. > > Maybe in that exact case. You can take the example further and have the same or another Mixin also handling setting the user field of model instance (which on a tangent, is one of the places Generic CBV's can improve imo). So now you can Mixin automatically setting the ``user`` field of a Model to the currently logged in user. You could also be calling an external API, and want to pass additional data to that API in this instance of the view, TemplateResponse won't help you and the original options stand here where you either copy/paste the view, or modify the existing view. It's pretty much a fact that module level functions in Python are completely unable to deal with any modification to internal logic without building up a list of kwargs/flags that they accept. Even if you are forward thinking and break your FBV's into multiple sub functions that the actual view calls, you cannot modify how it calls those functions, or swap out which functions it calls without getting into hacky monkey patching or copy and pasting things. > > Carl > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django's CVB - Roadmap?
On Tuesday, June 5, 2012 at 11:11 AM, Albert O'Connor wrote: > > Both the Built in Generic Class Based Views, and Class Based Views > > in general are great. Generic Class Based Views are not awesome when > > your view is not generic. > > > > > My experience is using Generic Class Based Views as an inspiration for > ones own Class Based Views lead to a bad user experience, both for > myself and apparently other people. I think it is worth highlight in > the documentation that Generic Class Based Views are useful, but > apparently not how you should write your own. > > The GCBV's tried to go very far into reusability, to the point where they have several layers of indirection to what is going on. Personally I prefer a case where you have the base view which is well written and contains all of the "Base" functionality instead of having a base view which is actually comprised of half 3-6 different Mixins. However adopting some of their conventions into your own CBV's will go a long way (get_object, get_queryset etc). > > Mixing in your UserMixin with other mixins that do additional query > modifications will lead to the writer of code having to create new > mixin which either combines both lines of code into one through > copying or explicitly calling each mixin, which will itself be > additional lines of code. > > This is only true if you write poor mixins. > > I can see an argument for using CBV to create library views which are > expected to both be reused and customized extensively, but those CBV > should themselves be flat with a very clear execution model. Using > inheritance to override behaviour with the syndication framework works > because you only have to look at one class to see what behaviour you > are modifying, but it doesn't scale to a any number of mixins, except > many for the one your provide in your distinct use case. > > It should be noted a vast majority of views that developers write > which aren't "generic" will never ever be reused and thus probably > should be CBV. > > I assume you meant shouldn't be here. There are benefits beyond the reusability (which the reusability is something I speak a lot about), in terms of testing, breaking things into easier to digest chunks. Even the most non-generic view tends to create a good deal of boilerplate. Even something as simple as the default get() and post() methods reduces the amount go cognitive overhead needed while parsing what a view does. As an example a dummy: https://gist.github.com/2875669 Similar number of lines (intact the CBV is a bit more), however with the CBV I've broken my view down into smaller chunks which, other then via self, are not able to affect one another. This allows me to focus on a much smaller unit of code if I am debugging making me have to "page" less of the application into my head at once. (As an example, maybe the post method accidentally reuses a variable from the setup code that the generic code was expecting to be there). Even if all you use the CBV's for is a "Namespace to hold crap" I feel that your code will end up better as it enables you to break apart a view into smaller and more manageable chunks, without polluting the views.py namespace with multiple functions for every view. > Albert > > On Tue, Jun 5, 2012 at 10:46 AM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > On Tuesday, June 5, 2012 at 10:35 AM, Carl Meyer wrote: > > > > > > > > On 06/05/2012 08:12 AM, Donald Stufft wrote: > > > > In order to do this with FBV's i'd either need to modify the existing > > FBV to accept > > a parameter that says if it should filter by logged in user or not or > > copy/paste > > the code into a new FBV. > > > > > > Not true, you can also have a function view that returns a > > TemplateResponse, and do the same types of tweaks using reusable decorators. > > > > Maybe in that exact case. You can take the example further and have the same > > or another Mixin also handling setting the user field of model instance > > (which on > > a tangent, is one of the places Generic CBV's can improve imo). So now you > > can > > Mixin automatically setting the ``user`` field of a Model to the currently > > logged in user. > > > > You could also be calling an external API, and want to pass additional data > > to that > > API in this instance of the view, TemplateResponse won't help you and the > > original > > options stand here where you either copy/paste the view, or modify the > > existing > > view. > > > > It's pretty much a fact that module level
Re: Breaking out localflavor
I could be wrong but offhand to make a namespace package you're going to need to make a namespace package for everything above it. So for a namespace at django.contrib.localflavor.* I *think* that django and django.contrib would both need to be namespace packages as well. If i'm right about that then https://github.com/django/django/blob/master/django/__init__.py will need to be moved to somewhere else as well. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Backporting some Python 3 support features to 1.4.x?
Just as an additional aside, the apps can also depend on the actual six library itself instead of Django's embedded version (It could be an optional dependency on Django < 1.5). The major things I think would be anything Django specific that don't come from six. On Thursday, September 6, 2012 at 2:09 PM, Aymeric Augustin wrote: > Hello, > > Several people have started porting their apps for Python 3, but they're > running into trouble when they try to support both Django 1.4 and master. > They end up with regrettable patterns such as: > > try: > from django.utils.six import PY3 > except ImportError: > PY3 = False > > Authors of pluggable apps generally chose to support the current and the > previous version of Django. Thus their users can alternatively upgrade Django > and their apps, which makes upgrades less scary. > > Now we have two alternatives: > 1) tell them to roll their own compat or wait until they can target 1.5 + 1.6 > — quite a downer, > 2) add some forwards compatibility tools to 1.4. > > We generally don't add features to minor releases, but there's a precedent > (csrf_noop), and the patch is as harmless as they come (see attachment). > > What do you think? > > -- > Aymeric. > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > Attachments: > - python3-forwards-compat-for-django-14.diff > -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Testing multidb with TEST_MIRROR
On Thursday, September 6, 2012 at 6:10 PM, Jeremy Dunck wrote: > What's the base branch for the fast_tests_merged comparison? https://github.com/akaariai/django/compare/django:master...fast_tests_merged -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Improve Django markdown rendering.
https://bitbucket.org/ionata/django-bleach On Thursday, September 6, 2012 at 10:48 PM, Waylan Limberg wrote: > On Thu, Sep 6, 2012 at 8:22 PM, Thomas Purchas (mailto:tpurc...@gmail.com)> wrote: > > I have submitted a path to improve the way Django handles html in markdown. > > Specifically how it escapes it. > > > > Ticket 6526 has all of the detail, could someone please review my patch. > As the maintainer of the Python-Markdown library, I'll weigh in here. > > I'll start by noting that safe-mode was a poorly chosen name for the > feature (which was added before I joined the project). Really, it is a > means of restricting raw html and IMO, should only always "escape" raw > html. However, because of the word "safe" in the name, the feature has > grown to support other so-called "safety" features to avoid XSS (for > example injecting malicious JavaScript into a markdown style link) > etc. That said, I can make no claims that it is actually "safe". > > The "replace" option is supported for backward compatibility reasons > (also why it is still the default) and "remove" is really just a > shortcut for "replace" with the "html_replacement_text" set to a blank > string. Not sure why anyone would want either of those options. Remove > is too surprising to the document author and replace is a lousy (IMO) > attempt at an explanation. While escape might not be expected by the > author, once noticed, it not nearly as surprising. > > If someone wants "safe" output from Markdown, I recommend using a > library specific to that purpose like bleach [1]. In fact, it would > make more sense to me to create a separate "clean" filter (perhaps > called "clean_html"?) which calls `bleach.clean()` and provide it as a > filter that can be used with any of the markup languages offered by > Django. > > If instead, improvements are only going to be made to the markdown > filter, then I would suggest a complete overhaul allowing access to > all of markdown's features [2]. For example, markdown outputs xhtml by > default. Some may want html - which the markdown lib supports - but > the Django filter does not. > > To me, the markdown filter in its current state is completely useless. > I have always had to re-implement my own, more powerful solution. > > My recommendation is to do one of the following (in order of preference): > > 1) Remove contrib.markup (per Django's depreciation policy) and leave > it to third party apps to support. > 2) Completely refactor the markdown filter to support all of the > markdown library's features except for "safe_mode" and add a new > "clean" filter which can wrap any markup filter. > 3) Add a new "clean" filter and simply drop support for Markdown's > safe_mode - leaving the rest as is. > > I do not recommend the approach of the current patch. It leaves a bad > taste in my mouth. Also note that I do not recommend supporting > Markdown's "safe_mode" in any form. Of course, the Django team will > need to make whatever decision will better serve the community - not > me. > > [1]: https://github.com/jsocol/bleach > [2]: http://packages.python.org/Markdown/reference.html#markdown > > -- > > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Django 1.5 release plans
On Wednesday, September 12, 2012 at 11:58 PM, timest wrote: > Can django support mongodb in version 1.5 ? If by supports you mean via the ORM, that's highly unlikely. Other then that there's nothing stopping you from using MongoDB within Django in any version of Django. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #3011 - Custom User Models -- Call for final review
On Tuesday, September 18, 2012 at 9:13 PM, Ben Slavin wrote: > Lastly, I haven't seen a path to easily allow third-party apps to gracefully > support both The Old Way and The New Way (1.4 and 1.5). It feels a bit wrong, > but should we be considering the addition of get_user_model and > settings.AUTH_USER_MODEL to 1.4.x that's hardcoded to contrib.auth.User so > third-party apps can rely on the presence of these mechanisms? > I don't think adding a hardcoded AUTH_USER_MODEL is going to give the kind of coverage people would want. Likely the best way would be for people to write a wrapper function around the relevant methods/settings and include it in their own projects. This sucks for duplication across all those projects but otherwise it means they'll only be able to support the latest 1.4.x and 1.5+. Likely to be a better user compatibility story by handling the fallback on a per app basis (Django could provide examples though). -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #3011 - Custom User Models -- Call for final review
On Tuesday, September 18, 2012 at 10:34 PM, Ben Slavin wrote: > Those apps that require (or choose to offer) a deeper stack of version > support can choose to do so, but the pragmatism of making the common case > easy (and removing the need for cross-project duplication) seems to justify > the unified interface. After I sent that I thought about it more, adding explicit values in 1.4.x doesn't really hurt anything. And the example wrapper functions could still be added to the docs for people who need more. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: The key of permissions model
Can't you add the constraint in both code and in the DB. On older sites
the constraint just won't exist in the DB (Could include it in the release
notes so people can add it to existing sites if they wish).
On Wednesday, September 19, 2012 at 6:40 PM, Anssi Kääriäinen wrote:
> We use the style of "app_label.permission_name" in multiple places of
> our code to refer to given auth.models.Permission. However, there is
> no unique key for that combination, the key is content_type,
> permission_name. I verified that it is actually possible to hit this
> problem by using the Meta.permissions.
>
> I am not sure what we can do about this... Or if we even need to do
> anything about this.
>
> Without schema changes we can't have a DB constraint for the key. But,
> maybe we could validate (as part of model validation) that there are
> no overlapping permissions? If the user goes and creates overlapping
> permissions despite of this, we can't do anything about that.
>
> The reason why I am wondering about this is that I'd like to add
> Permissions.objects.get_permission('app_label.permission_name')
> convenience method. And, while investigating that I realized that the
> app_label, permission name isn't a key...
>
> I am likely going to add the get_permission() anyways, it will just
> throw "returned more than 1" if the above problem is hit.
>
> Thoughts?
>
> - Anssi
>
> --
> 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
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> (mailto: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-developers@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: How to test patch
Travis or Jenkins can be setup to test PR's and use Github's API to mark the PR as good to merge or not. On Sunday, October 28, 2012 at 5:20 AM, Russell Keith-Magee wrote: > > On Sun, Oct 28, 2012 at 3:55 PM, Dominic Rodger (mailto:dominicrod...@gmail.com)> wrote: > > Another long time user here (at some point I'd love to make the jump to > > contributor, just need to find more time) - out of interest, is there a > > reason we don't use Travis? I wonder if that might help those with commit > > access, since pre-tested pull requests would mean you could have confidence > > that the tests at least pass. Apologies if this has been discussed before > > (there are a few contributors to this group called Travis, which made > > searching a bit tricky!). > > > > We do have a CI server (a Jenkins install) - you can find it here: > > http://ci.django-cms.org/job/Django/ > > We don't currently test every fork or pull request on GitHub, but that's > certainly an interesting idea, especially if we could get validation that a > pull request passes the full test suite. > > I haven't spent any time messing around with Travis configuration to know how > hard this would be to set up -- and whether the build failures can be > communicated in an effective way. If you're looking for a way to contribute, > investigating the options here might be an interesting place to start. > > Yours, > Russ Magee %-) > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Updating default errors in contrib.auth.forms.PasswordResetForm
The canonical way of handling this so as not to leak information like that is to do exactly the same thing UX wise for success and failures, and just update the message to state that if an email address by that account has been registered they will get an email soon. On Friday, November 2, 2012 at 9:18 PM, Russell Keith-Magee wrote: > Hi Lee, > > What you propose certainly sounds reasonable -- anything that reduces the > exposure of valid accounts to an external source is a good thing, IMHO. > > Did you have an alternative wording to suggest? If you do, please open a > ticket. > > Yours, > Russ Magee %-) > > On Fri, Nov 2, 2012 at 9:42 PM, Lee Trout (mailto:leetr...@gmail.com)> wrote: > > Hi all, > > > > I wasn't sure if it was best to open a ticket or post to the dev group so > > here I am... > > > > I was curious what others thought about changing the default error in the > > PasswordResetForm which currently displays "That e-mail address doesn't > > have an associated user account. Are you sure you've registered?". > > > > I feel like there could be a better default that doesn't expose the fact > > that an email may or may not be in use. (And that probably goes for the > > unusable password error, too.) > > > > Relevant bits: > > https://github.com/django/django/blob/stable/1.4.x/django/contrib/auth/forms.py#L191 > > > > Lee > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/django-developers/-/9EylAZDthMsJ. > > To post to this group, send email to django-developers@googlegroups.com > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto:django-developers%2bunsubscr...@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-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: 1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note
The major help is preventing clobbering a value for concurrency. Prior to this when you loaded an object from SQL into a django model, it would fetch all the values as they were at that time, and store them in the model instance. Then when you saved it it would write all those values back out to the database, even if someone else had changed them and you didn't. Now if you fetch a particular instance, and make a change, you can save only that value, and you won't clobber other peoples saves if they made a change to an unrelated field on that row. On Friday, November 2, 2012 at 9:42 PM, Christian Jensen wrote: > I was just writing some code against 1.5 and thought I might use the new > .save(update_fields=['xyz']) then I realized I was using PostgreSQL - which > is an MVCC... which re-writes the entire row as far as I know even when one > column is being updated. > > I popped into the release notes and it does in fact indicate that it is > useful for high concurrency scenarios. > > I thought it would be nice to note in the docs somewhere that it is really > not useful for database of this type unless you are using a healthy amount of > the update_fields elsewhere. > > I might be wrong on all of this. > > I have never made a documentation change nor have any idea what the process > would be so if someone chooses to make this note, please do! > > Thanks everyone! > Christian > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/LIGJJ2qwBZgJ. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: post-collectstatic signal
On Tuesday, November 13, 2012 at 10:43 PM, Justin Holmes wrote: > > My only concern is that we'll limit our audience by requiring users to use a > specific STATICFILES_STORAGE. What if they're already using a custom one? Put the meat of your backend in a mixin, provide options for the default ones, and instructions on mixing it into custom ones. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: use SQLAlchemy Core for query generation
On Sunday, December 23, 2012 at 4:08 PM, Florent Gallaire wrote: > Django ORM should work for SQL and NoSQL DBMS. > NoSQL integration in Django is a more interesting and needed subject, > but who cares about that in the core team ? > > Why should the Django Object Relational Mapper be modified to work with non relational databases? Trying to shoe horn random NoSQL into the Django ORM feels like a bad idea. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: use SQLAlchemy Core for query generation
On Wednesday, December 26, 2012 at 10:00 PM, Russell Keith-Magee wrote: > Why? Because we've gone to extraordinary lengths to make sure this sort of > thing is at least theoretically possible. > > Although we use the term "ORM", and there's currently only relational > implementations of Django's ORM, there's nothing relational about the Django > ORM API. We've very deliberately posed the API in terms of functions you want > to perform on objects: > > * Get me the author named "Douglas Adams" > * Get a list of books that are more than 3 years old > * Update the login counter on this user by one. Because except for very simple models you will not be able to sanely take a model written for a Relational database and switch it to a NonRelational database. If you cannot provide the same sort of mostly transparent switching like the ORM provides for MySQL -> PostgreSQL -> Oracle then there is little benefit in keeping it within the same system. All of your examples work on simple models sure. What about: * Anything requiring a join, explicitly with select_related() or implicitly with __ magic. * select_for_update * No standard way of handling "Related" fields (Do you Inline them? Mimic a ForeignKey?) * The entire transaction system on systems without transactions There is also the problem of vastly different access patterns, assumptions, and performance characteristics. * Getting a list of Books that are more than 3 year old is a very simple operation in SQL with very predictable performance, getting a list of books older than 3 years old if they are stored in Redis, less so. * Systems that depended on a unique=True enforcing a constraint of uniqueness no longer happening. * index=True becoming NO-OP. * A simple Join potentially goes from an inexpensive operation to one that requires traversing several million rows with horrible performance. The access patterns, assumptions of functionality, and assumption of performances are so different between even the different NoSQL solutions, much less the various NoSQL solutions and Relational databases that either you're going to have second class citizens (Sure you can use X system with Django models, but only as a competely segregated unit and you can't touch [a list of features]), or you're going to need to limit the features down to a subset that all databases can support (We already have this problem with PostgreSQL vs MySQL vs SQLite, it will be tenfold if we include NoSQL databases). In order to actually use the power of your datastore you need to use a class of "ORM" that is designed to work within it's access patterns. Django as a whole should be avoiding giving people footguns, and attempting to shove NonRelational databases into the ORM will be providing a massive footgun. As soon as it happens you'll have a whole host of people attempting to run apps and sites that depended on things that relational databases assured suddenly having it yanked out from underneath them and it will be Django's fault for providing that footgun. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: use SQLAlchemy Core for query generation
On Wednesday, December 26, 2012 at 10:56 PM, Russell Keith-Magee wrote: > That depends entirely on what you consider the goal of the ORM to be. > > You have assumed that the goal would be "allow an arbitrary query to run on > any underlying data store, and run with equivalent efficiency". In this > model, you could take your fully operational Django PostgreSQL project, and > roll it out under MongoDB (or any other supported store), and it would > Magically Work™. > > I completely agree that this is a completely unrealistic goal, and would, as > you rightly point out, constitute a high-calibre footgun. That's what people will expect from it in large part. It may not be what's intended but it's what people will expect. > > However, there's another way of looking at it. You're focussing on the ORM as > a query generation engine. Of more interest is the ORM as a metadata layer > for models in a data store, with some basic reliable querying features. > > Think of it this way -- the goal isn't to allow an arbitrary query to run on > any data store. The goal is to allow Django's admin to operate on a model in > any data store, or to allow a Django ModelForm to retrieve and/or store an > object in any datastore. This can easily be done with 2 (or more) separate systems. There is 0 reason why the Admin and the ModelForms need to only realistically work within a single system. If your goal is to allow someone to use the admin, modelforms, or some other tool to interact with all of them that does _not_ require anything more than basic access then you can define an API that the admin expects and as long as your "Model" fits that API it can be used there. Then you can have one ORM for Relational databases that is able to use the full power of the ORM, one for each of the various "classification" of ORM (which don't even need to live in Django Core) and as long as they implement the interface that the Admin (for example) expect they will work out of the box. A system like this removes the expectation from users that you can take a model written for a relational database and cram it into a NonRel (and the inverse), allows you to have "shared" consumers of the various implementations, but still have access to the full power of the underlying implementations. > The queries required to support Django's admin and/or ModelForms are all > inherently simple CRUD operations -- operations that have simple (and for the > most part, efficient) analogs in every data store. > FWIW the Admin cannot even currently handle all database tables because of assumptions it makes about performance (so far I've seen it expects `SELECT COUNT(*) FROM ;` to return in a reasonable amount of time). Applying even greater diverging performance patterns to it is a harder than you're assuming especially if you take all of the features of the admin into account. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Switch to database-level autocommit
On Friday, March 1, 2013 at 7:48 AM, Aymeric Augustin wrote: > Hello, > > I'd like to improve transactions handling in Django. The first step is the > current emulation of autocommit with database-level autocommit. > > ** Rationale ** > > PEP249 says that any SQL query opens a transaction and that it's the > application's job to commit (or rollback) changes. This model is also > required by the SQL standard. But it isn't very developer-friendly. > > To alleviate the pain, Django commits after each ORM write. Unfortunately, > this means that each read opens a transaction, that eventually gets committed > after the next write, or rolled back at the end of the query. Such > transactions are useless and don't come for free. Relying on them to enforce > integrity is extremely fragile — what if an external library starts writing > to a log table in the middle of one of these implicit transactions? The term > "footgun" comes to mind. > > Database authors have reached the same conclusion, and most databases > supported by Django use autocommit by default, ignoring the SQL standard. On > PostgreSQL and SQLite, this is the only mode available. > > As a consequence, to implement the behavior mandated by PEP 249, the Python > libraries (psycopg2, sqlite3, etc.) automatically start transactions. And > then Django automatically commits them. This is not only wasteful, but also > buggy. It's the root cause of "idle in transaction" connections on > PostgreSQL. It's also sometimes poorly implemented: for instance, executing > "SAVEPOINT …" on SQLite commits implicitly. (It's arguably a bug in the > design of the sqlite3 module. The Python bug tracker suggests it's going to > be documented.) > > Basically, Django intends to provide autocommit by default. Rather than fight > the database adapter that itselfs fights the database, I propose to simply > turn autocommit on, and stop implicitly starting and committing transactions. > Explicit is better than implicit. > > ** Implementation ** > > All databases supported by Django provide an API to turn autocommit on: > > - http://initd.org/psycopg/docs/connection.html#connection.autocommit > - http://docs.python.org/2/library/sqlite3#sqlite3.Connection.isolation_level > - http://mysql-python.sourceforge.net/MySQLdb.html => conn.autocommit() > - http://cx-oracle.sourceforge.net/html/connection.html#Connection.autocommit > > This obviously has far-reaching consequences on transaction handling in > Django, but the current APIs should still work. (Fixing them is part 2 of the > plan.) The general idea is that Django will explicitly start a transaction > when entering transaction management. > > This will obviously impact maintainers of backend for other databases, but if > it works on Oracle (which doesn't have autocommit — it's emulated in OCI) and > on PostgreSQL (which enforces autocommit), I hope it can work anywhere. > > ** Backwards-compatibility ** > > Roughly, I'd classify Django users in four groups: > 1 - "Transactions, how do they work?" > 2 - "Django autocommits, doesn't it?" > 3 - "I'm using TransactionMiddleware!" > 4 - "I'm managing my transactions." > > Groups 1 and 2 won't see the difference. There won't be any difference for > group 3. Group 4 may be impacted by the change, but I believe most people in > this category have autocommit turned on already — or would like to, if > they're on MySQL — and will understand the change. > > I don't see much point in providing an option to turn autocommit off, because > starting a transaction is a much more explicit way to achieve the same > effect. We usually don't provide "backwards compatibility with bugs". > > Yay or nay? +1 > > -- > Aymeric. > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: deprecate and remove django.contrib.comments
On Mar 7, 2013, at 11:48 AM, Jacob Kaplan-Moss wrote: > Hi folks -- > > This one's simple: I'd like to deprecate `django.contrib.comments`, > scheduling it to be removed in a couple of releases. > > My rationale is this: if you don't really care much about how comments > work but just want something easy, then Disqus (and its competitors) > are easier to use and have much better features (spam prevents, > moderation, etc.). If you want something complex and specific, on the > other hand, you're better off writing something from scratch. > > Practically, I'd do this by deprecating `django.contrib.comments` in > 1.6. We'd immediately stop making any changes to it (except for > security or data loss issues). It'd stay deprecated in 1.7, and would > be removed in 1.8. > > If someone volunteers to maintain it as an external project I'll move > the code to a new repo and direct people there in the docs. If nobody > volunteers, then it'll go to the great /dev/null in the sky. > > Any objections? > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > +1 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Documenting lazy() and memoize()
On Mar 11, 2013, at 10:50 AM, Tom Evans wrote: > Hi all > > Someone just asked on users@ "How do I reverse a URL inside > settings.py". I gave a solution (eventually; got it wrong the first > time!) using two functions from django.utils.functional, lazy() and > memoize(). > > Neither of these two functions are documented. and so aren't part of > the API - really I shouldn't have been suggesting them. > > Is this deliberate? They seem perfectly useful and correct > implementations of lazy() and memoize(), and for places like this, > very useful. > > If it is not deliberate, I can whip up some documentation so that they > can become blessèd parts of the API. > > Cheers > > Tom > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > https://docs.djangoproject.com/en/1.5/ref/urlresolvers/#reverse-lazy ? - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Remove download_url from setup.py
Just an idea. I think it might make sense to remove the download_url from setup.py. It has caused problems in the past (http://www.djangoproject.com/m/bad-installer.txt) and I don't think leaving it there adds much value. It does however add yet another place that a package releaser needs to update and makes `pip install Django` more fragile. The only major benefit I can see is providing a download link on PyPI, but given that there's a link right 40px or so to directly download from PyPI and a giant green download button further up the page I think this benefit is minimal. Thoughts? ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Request method in urls.py
w you to specify the method in the
> routing configuration, Django seems to be an exception in this respect.
>
> It would be extremely easy to implement, and would lead to vastly better code
> across new projects, including a simpler way of writing rest style interfaces:
>
> url('^objects/$', 'views.create_object', methods=['post', 'put'],
> name='create_object'),
> url('^objects/$', 'views.get_objects', name='list_objects'),
>
> This has come up many times before and been swatted down for various reasons.
> One is that it could be implemented with a one-off dispatcher, as in:
>
> url('^objects/$', create_or_list(list=get_objects, create=create_object),
> name='create_or_list_objects')
>
> But this is overly complex for what should be a simple configuration, forces
> one to create the same name for the url, and worse, creates a level of
> indirection breaking the abstraction up; or in other words you're trying to
> do route configuration, why not do it in the place you're already doing route
> configuration?
>
> The other argument is that you can do this with Class Based Views. I don't
> believe this is a good argument as one would have to utilize Class Based
> Views to get this basic functionality. In fact CBV's, only really solve two
> common issues, one is the boilerplate inherit in forms, and the other method
> routing. But the proposed solution to method routing is simpler and better.
>
> I will gladly implement the code required for this, but don't wish to do so
> if it's going to be quashed, which is why I bring it up here.
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Django 1.6 release timeline
On Apr 30, 2013, at 3:31 PM, Jacob Kaplan-Moss wrote: > Hi folks - > > Unless there are strong objections, here's what I'm thinking for the > Django 1.6 release timeline: > > Alpha: May 16 > Beta: June 20 > RC: Aug 1 > Final: as early as Aug 8, or later if more RCs are needed. Sounds reasonable. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Django 1.6 release timeline
On Apr 30, 2013, at 7:10 PM, Andrew Ingram wrote: > On 30 Apr 2013, at 23:38, Shai Berger wrote: >> I see one issue with this: According to current procedures, if this timeline >> is followed, support for 1.4 will be dropped less than 6 months after the >> release of 1.5. At least for some of us (which, as I mentioned earlier on >> the >> list, only moved to 1.4 when the 1.5 release forced us to), this may be a >> bit >> of a problem. >> >> Shai. > > It seems like 1.4 support might need to be extended. I'm assuming that given > the success of the kickstarter campaign, Andrew's schema migration > functionality will be made available to 1.4, and the functionality seems to > be a prerequisite for migrating to the new way of handling user models. > > Andy There is no requirement to migrate for the new way to handle user models. The only time you'd need to migrate is if you want to swap out your existing user models that Django provides with new ones. If you don't do that then you don't need to migrate. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: test discovery
On May 8, 2013, at 5:00 PM, Carl Meyer wrote: > Jacob has suggested that back-compat breaks in test-running are not as > serious as in production code, and that we should just switch to the new > test runner by default in Django 1.6. This is what the pull request > currently does. This will mean that some people's test suites will > likely be broken when they upgrade to 1.6. They would have two options, > both documented in the release notes: they can update their test suite > to be discovery-compatible immediately, or they can just set TEST_RUNNER > to point to the old runner and get back the old behavior, which they can > keep using until Django 1.8 (or longer, if they package the old runner > externally). This sounds reasonable to me. Tests are not production code so I agree with Jacob. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Recommending a Python 3-compatible MySQL connector
On May 10, 2013, at 11:49 AM, Luke Plant wrote: > On 10/05/13 14:12, Aymeric Augustin wrote: >> Hi Mark, >> >> On 10 mai 2013, at 10:16, Mark Hughes wrote: >>> Another option to consider could be mysql-connector-python >>> >>> https://pypi.python.org/pypi/mysql-connector-python/1.0.9 >> >> Thank you, it's the official library I was missing! >> >> Unfortunately, it's licensed under the GPL. To the best of my >> understanding, importing modules in the same Python process triggers >> GPL contamination. Therefore, if Django officially supports this >> module, anyone distributing code that works with Django should either >> release it under the GPL or specify that it's illegal to use it with >> MySQL. > > Can the GPL really do this? My own thoughts on this are here: > > http://lukeplant.me.uk/blog/posts/python-and-copyright/ > > I'm not saying that we should use GPL code if there is BSD alternative, > but as far as I can see, it's impossible for the GPL to say *anything* > in this situation, because there is nothing a typical Django project > would be doing with that library that would actually require them to > accept the terms of the license. > > The GPL allows *using* of the code for any purpose. It's only when a > project becomes a distributor of the GPL code that it is required to > abide by the other terms. > http://jacobian.org/writing/gpl-questions/ In particular look at VanL's responses. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Perception of attitude in tickets
n > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
BCrypt + Python3
I went looking for BCrypt + Django + Python3 today and this is what I found: The current recommended solution to bcrypt + Django is using py-bcrypt which is not compatible with Python3. Someone else has taken py-bcrypt and created py3k-bcrypt however they made the decision to enforce having str instances sent in for password/salt instead of bytes which makes it incompatible with Django's encode function on the BCrypt password hashers[1]. So I created a library simply called `bcrypt`[2] which has the same API as py-bcrypt but it functions on Python 2.6+ and 3.x (as well as PyPy 2.0 since it's implemented via CFFI). When testing this against Python3 + Django I discovered that Django isn't properly encoding/decoding when talking to the external library so I made a patch that causes it to always send bytes to the external library, and str's to other pats of Django. That can be found here: https://github.com/django/django/pull/1052 My bcrypt library is obviously new code but it's a small wrapper over crypt_blowfish from OpenWall[3] and I'm wondering (assuming no one objects to me merging my Patch) if it would make sense to switch the documentation away from suggesting py-bcrypt and have it suggest bcrypt instead since it will allow BCrypt to function on Python3 as well. Thoughts? [1] I believe this is inheriently wrong as bcrypt operates on bytes not on unicode characters, and in order for this to work py3k-bcrypt must be assuming a character set it can encode(). [2] Found at https://crate.io/packages/bcrypt/ or https://github.com/dstufft/bcrypt [2] Found at http://www.openwall.com/crypt/ - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: BCrypt + Python3
On May 11, 2013, at 4:10 AM, Claude Paroz wrote:
> Le samedi 11 mai 2013 07:59:18 UTC+2, Donald Stufft a écrit :
> I went looking for BCrypt + Django + Python3 today and this is what I found:
>
> The current recommended solution to bcrypt + Django is using py-bcrypt which
> is not compatible with Python3.
>
> Someone else has taken py-bcrypt and created py3k-bcrypt however they made
> the decision to enforce having str instances sent in for password/salt
> instead of bytes which makes it incompatible with Django's encode function on
> the BCrypt password hashers[1].
>
> So I created a library simply called `bcrypt`[2] which has the same API as
> py-bcrypt but it functions on Python 2.6+ and 3.x (as well as PyPy 2.0 since
> it's implemented via CFFI). When testing this against Python3 + Django I
> discovered that Django isn't properly encoding/decoding when talking to the
> external library so I made a patch that causes it to always send bytes to the
> external library, and str's to other pats of Django. That can be found here:
> https://github.com/django/django/pull/1052
>
> My bcrypt library is obviously new code but it's a small wrapper over
> crypt_blowfish from OpenWall[3] and I'm wondering (assuming no one objects to
> me merging my Patch) if it would make sense to switch the documentation away
> from suggesting py-bcrypt and have it suggest bcrypt instead since it will
> allow BCrypt to function on Python3 as well.
>
> Thoughts?
>
> [1] I believe this is inheriently wrong as bcrypt operates on bytes not on
> unicode characters, and in order for this to work py3k-bcrypt must be
> assuming a character set it can encode().
> [2] Found at https://crate.io/packages/bcrypt/ or
> https://github.com/dstufft/bcrypt
> [2] Found at http://www.openwall.com/crypt/
>
>
> Hi Donald,
>
> There are several approaches in string handling in Python 3, being as content
> input or output. As for me, I'm generally privileging unicode strings
> whenever possible. See for example the Python hashlib behaviour for digest()
> and hexdigest(): digest() returns a bytestring as it can return a full range
> of bytes (0-255), while hexdigest() returns a string as the result is
> guaranteed to be ASCII-safe.
>
> Similarly I would have returned a string (unicode) from hashpw() as far as it
> is guaranteed to be ASCII-safe. As for inputs, I think it is easy enough to
> accept both bytestrings and strings, test them and encode('utf-8') when
> needed.
> I recognize that it looks a bit odd on Python 2 to receive unicode when you
> fed bytes to a method.
>
> I'm not sure there is a "right" way, it's all about design and choice. Feel
> free to ignore me :-)
As far as the return value from hashpw goes it's bytes primarily because the
inputs to hashpw are expected to be bytes.
As far as the input values for hashpw goes, it accepts only bytes because
bcrypt as an algorithm functions only on streams of bytes, not on unicode
characters. Not every character in the world can be represented in utf-8 and I
believe it's better for a library to require bytes (you can see the hashlib on
python3 does this) than to make a possibly erroneous guess.
>
> Claude
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Perception of attitude in tickets
On May 13, 2013, at 5:12 AM, Chris Wilson wrote: > Hi all, > > On Mon, 13 May 2013, Russell Keith-Magee wrote: > >> This isn't political equivocating. Its a genuine call to the community to >> tell us how we can make things better. > > If I may make a suggestion to be considered by the community: > > The status WONTFIX sounds awfully rude to me. It's like saying "That's a pony > and you can't have one, ever." It implies a terminal finality which actually > isn't meant in some cases, because it is possible (as we've seen) and even > sometimes recommended by a core developer, for a sufficiently determined > person to push for change on the mailing list and make it happen. > > Perhaps there's a case for a status like "DISCUSSION" or "NEEDINFO" when a > feature might be accepted if sufficient evidence for it comes to light, but > that evidence isn't there yet. > > I'd like to feel that reload() and first() are cases where a core developer > might choose to close a ticket with this new status instead of WONTFIX. I > would also hope that the core developers might be gentler with newbies like > me instead of scaring us off with a gruff one-word reply of WONTFIX. > > I think there is value in people "voting" for a feature on the ticket if they > don't feel up to arguing the case on the mailing list (which is a trial by > fire, and not for the faint hearted). Whoever is brave enough to take up the > issue on the mailing list can point to the number of votes on the ticket as > evidence for a desire for the feature, and hence its usefulness. And voting > on the ticket instead of here saves a lot of "me too" noise on the mailing > list. > > Cheers, Chris. > -- > Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838 > Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK > > Aptivate is a not-for-profit company registered in England and Wales > with company number 04980791. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > I think the problem with voting on an issue is that it will make people feel justified in asking/demanding a feature that doesn't have a chance of going on. A bad idea with a 100 yes votes isn't going to get in any more than a bad idea with 1 yes vote. That's not to say it's not an ok idea. I don't know if it is or not. But it is an issue and folks will feel like # of votes justifies bad ideas getting implemented. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Ticket 13978: Allow inline js/css in forms.Media
Re CSP It's more or less fine to start using it. It needs a clean API for configuring it still but it's pretty solid. However a newish feature that has been added is the ability to allow _some_ inline scripts but not all. This feature doesn't have widespread support yet sadly though. The other thing about CSP is that policies are defined per response. So a page that uses inline scripts could be allowed them while another page doesn't. On May 15, 2013, at 6:28 PM, Aymeric Augustin wrote: > On 14 mai 2013, at 02:36, Derek Payton wrote: > >> I have a working patch with tests and docs for #13978, which would add the >> ability to have inline JS and CSS in forms.Media. I feel that this ticket is >> a much better solution than, e.g., scattering the required inline media >> throughout your templates. However the issue was raised that this goes >> against the W3C's Content Security Policy. Per Julian's recommendation, I am >> bringing this here for consideration. >> >> Ticket: https://code.djangoproject.com/ticket/13978 > > > > Disclaimer: I'm certainly not the most qualified person when it comes to > frontend, but since this message didn't get an answer, here's one. > > > Hi Derek, > > https://github.com/dmpayton/django/commit/a676b609004863dd726332df865b9ead7487767e > looks fairly reasonable to me. > > CSP doesn't look ready for general consumption just yet, at least judging by > the two first lines of django-csp's docs: >> Content-Security-Policy is a complicated header. There are many values you >> may need to tweak here. > >> It’s worth reading the latest CSP spec and making sure you understand it >> before configuring django-csp. > Different sites have different security requirements, for instance a site > where only admins can edit stuff is generally immune to XSS. I don't think > the existence of CSP in its current state is a sufficient reason to reject > this ticket. > > A minor suggestion: InlineJS/CSS sounds even more explicit than > EmbeddedJS/CSS. > > I left a few other questions on GitHub. I don't expect a long answer, I just > want to make sure you've considered them. > > -- > Aymeric. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?
On May 15, 2013, at 9:01 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > Does anyone have some clever thoughts on how to solve #16650? > > https://code.djangoproject.com/ticket/16550#comment:7 is a good > summary of the problem: if you're using extensions, you need a way to > run some custom SQL in tests after the DB gets created by the test > harness but before syncdb runs. > > The current patch and suggested solution on the ticket won't work (see > the thread), but I think it's a legit need and I'd like to come up > with a good solution and possibly reopen the ticket. > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > pre_syncdb signal? syncdb is still called in tests right? - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: BCrypt + Python3
On May 18, 2013, at 5:15 AM, Aymeric Augustin
wrote:
> Apologies for answering so late. I see the change discussed here was already
> committed. The change itself is fine — essentially because it's limited to
> the bcrypt password hasher — but I'd like to bring some perspective to parts
> of this discussion.
>
> Overall, I strongly advocate consistency in the Python ecosystem, and the
> standard library sets the, err, standard. Here's how it deals with this
> situation in Python 3.
>
>>>> import hashlib
>
> 1) Hash functions must reject str objects because the encoding isn't
> guaranteed:
>
>>>> hashlib.md5('foo')
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: Unicode-objects must be encoded before hashing
>
> 2) Digests must be returned as bytes (quite obviously):
>
>>>> hashlib.md5(b'foo').digest()
> b'\xac\xbd\x18\xdbL\xc2\xf8\\\xed\xefeO\xcc\xc4\xa4\xd8'
>
> 3) Hex digests must be returned as str:
>
>>>> hashlib.md5(b'foo').hexdigest()
> 'acbd18db4cc2f85cedef654fccc4a4d8'
>
> Adapting this example to Python 2 is left as an exercise :)
>
> As a consequence, I agree with Claude's recommendation to use unicode strings
> whenever possible (eg. for hex digests). However, I believe that a simple
> hash function mustn't accept unicode strings. Wrappers — say, an
> make_password_hash function — must encode unicode strings to bytes before
> passing them to hash functions.
>
> Regarding Donald's pull request, `data = force_bytes(data)` makes sense,
> because the hasher must be fed bytes. There's already a `password =
> force_bytes(password)` just above.
>
> I'm less enthusiastic about the change adding `force_text(data)`. It actually
> works around bcrypt.hashpw returning an unexpected type in these
> circumstance. But, if that's how bcrypt.hashpw works, that's fine.
Well the python library returns bytes (and accepts bytes for the salt) because
fundamentally bcrypt operates on bytes, and the C library reflects that. The
force_text would need to happen either in Django or in the Python library and I
believe it's more appropriate for it to happen in Django.
>
> Donald, we've discussed this before and I know you have strong feelings
> against the design of the standard library in this regard. Still, Python is
> the environment we're living in, and we shouldn't fight it.
>
> --
> Aymeric.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: RFC: "universal" view decorators
into Django? > > Jacob > > > > > > > > > > > > > > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Proposal: deprecate and remove egg template loader
I’m fine with this, but just be warned that it does mean anything that ships a Django app will need a zip_unsafe=True or else they no longer support being installed with easy_install. On July 12, 2015 at 10:53:20 AM, James Bennett (ubernost...@gmail.com) wrote: > There's not much to this, really, except what's in the subject line of this > message. > > The problem of providing a single-file, no-build-step format for > distributing and installing Python packages has been solved by wheels, and > wheels also don't cause the pile of weirdness that comes with using eggs. > > So Django should really stop encouraging/supporting the use of eggs. At a > minimum, this should involve Django 1.9 starting the deprecation process > for the egg template loader, and any other parts of Django which contain > special-case workarounds to deal with eggs. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers > (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAL13Cg-Y8OXrJvF%2BeXof9v0uBKCJ76owqH4dMzrShVKwVoLxUg%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. > --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.55a3d2a8.454c19cb.ef7a%40Draupnir.home. For more options, visit https://groups.google.com/d/optout.
Re: Pre-DEP: community support of unmaintained versions of Django
On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote: > Hi Christian, > > On 08/18/2015 08:01 PM, Christian Hammond wrote: > > I know it's been a while since we discussed this, but today's security > > release is the first one that's really affecting our product and we've > > finally got things in shape to be able to start distributing unofficial > > Django security releases (we've also just been swamped since our > > discussion earlier this year). > > > > I wanted to dig into the versioning scheme just a bit. We tried going > > with local version identifiers, but it turns out these are fairly > > useless... > [snip] > > Given that, what would your feelings be on allowing for 1.6.11.x > > releases? This way we wouldn't take up any possible future versioning > > slots (unlikely as they may be), while being compatible with all > > versions of setuptools, and compatible with specifying version ranges. > > This would still appear solely on our own downloads page and > > announcements, with an appropriate note on them being unofficial builds. > > In my ideal world, the version number would help convey unofficial-ness > a bit more strongly, but after re-reading PEP 440 I don't think it > leaves us with any good options. I considered post-releases (e.g. > 1.6.11.post1), but "The use of post-releases to publish maintenance > releases containing actual bug fixes is strongly discouraged." So given > the lack of good options, I'm OK with 1.6.11.x. Anyone else on the core > team have a problem with that? 1.6.11.x should work fine, though I’m confused why not just issue 1.6.12+? > > > Also as a status update, we've started a fork and applied for the > > pre-notification list. I've backported all current security fixes to a > > branch, ensured the test suite passes with flying colors, and have added > > a README detailing everything you've requested. This is all up at > > https://github.com/beanbaginc/django. Let me know if there's anything > > you'd like changed. > > The README looks great, thanks! > > Carl > > -- > You received this message because you are subscribed to the Google Groups > "Django developers > (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/55D49FEE.80503%40oddbird.net. > > For more options, visit https://groups.google.com/d/optout. > - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.55d4a082.245ae313.6c62%40Draupnir.home. For more options, visit https://groups.google.com/d/optout.
Re: Pre-DEP: community support of unmaintained versions of Django
On August 19, 2015 at 11:31:46 AM, Carl Meyer (c...@oddbird.net) wrote: > On 08/19/2015 09:28 AM, Donald Stufft wrote: > > On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote: > >> In my ideal world, the version number would help convey unofficial-ness > >> a bit more strongly, but after re-reading PEP 440 I don't think it > >> leaves us with any good options. I considered post-releases (e.g. > >> 1.6.11.post1), but "The use of post-releases to publish maintenance > >> releases containing actual bug fixes is strongly discouraged." So given > >> the lack of good options, I'm OK with 1.6.11.x. Anyone else on the core > >> team have a problem with that? > > > > > > 1.6.11.x should work fine, though I’m confused why not just issue 1.6.12+? > > Because that looks exactly like the version number an official Django > release would use, and the idea is to be as clear as possible that these > are not official Django releases. For some users (who don't read READMEs > etc) the version number is one of the few things we can be pretty sure > they'll see. > > Do we have any evidence that users will notice a fourth digit and will make the mental association that they are not official releases? I wouldn’t if I hadn’t read this thread. I mean I don’t actually care if they use 1.6.11.x or 1.6.12+, I just don’t think it’s really buying anything extra. If you want the version number to contain something that says “unofficial” just tack an unofficial local version number on the end of whichever solution is picked (so 1.6.11.5+unofficial or 1.6.12+unofficial) or whatever. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.55d4a2f7.394e58e8.6c62%40Draupnir.home. For more options, visit https://groups.google.com/d/optout.
Re: Methodology for increasing the number of PBKDF2 iterations
On September 20, 2015 at 7:26:09 PM, Alex Gaynor (alex.gay...@gmail.com) wrote: > > Unfortunately 24k iterations is behind where we'd want to be > (~100k iterations, or a factor of 4, last I checked). If I remember, a key thing was we wanted the PBKDF2 iterations to be much higher than they were because they hadn't kept up with improvements (or adjusted at all at) but we didn't want to just jump from some low amount (20k?) straight to 100k in one release. The 25% number was, if I recall, an attempt to move us to that point over time, so it was purposely chosen to be faster than CPU increases because if it was equal to that we'd never catch up to where we should be. ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.55ff4179.5b345c86.ead3%40Draupnir.home. For more options, visit https://groups.google.com/d/optout.
Re: Methodology for increasing the number of PBKDF2 iterations
On September 21, 2015 at 10:55:57 AM, Collin Anderson (cmawebs...@gmail.com) wrote: > Is there an external library for Python < 2.7.8? I know we don't officially > support the system version of python in RHEL/CentOS and Ubuntu, but I bet > we could get away with requiring a dependency for those old versions of > Python in new versions of Django. > https://cryptography.io/en/latest/hazmat/primitives/key-derivation-functions/#cryptography.hazmat.primitives.kdf.pbkdf2.PBKDF2HMAC ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.56002c64.29abc385.ead3%40Draupnir.home. For more options, visit https://groups.google.com/d/optout.
Re: Static type checking for public API
It supports a mode that is comparable with Python 2.x, but which isn’t as nice. You essentially need to ship additional stub files that just have the type hints in them. On October 11, 2015 at 1:13:20 PM, Collin Anderson (cmawebs...@gmail.com) wrote: Hi John, I think we need to wait until we drop Python 2.x support to be able to do this, as 2.x won't accept this syntax. Does that sound right? Thanks, Collin On Sunday, October 11, 2015 at 9:22:17 AM UTC-4, John Michael Lafayette wrote: Python now has static type checking. All you do is follow function parameters with ": paramType" and add "-> returnType" before the colon at the end of the function declaration and auto-complete will work on the return value in IntelliJ. Can you add the function parameter types and return types to all the functions in the public API? > So like change this... > def func(param): > > To this... > def func(param: int) -> str: That way when I call a function, the static type checker will make sure I pass in the right type. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/81f6b5a2-14a2-4a7a-82c4-74d3016ff59f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.561a9939.58492978.14b73%40Draupnir.home. For more options, visit https://groups.google.com/d/optout.
Re: Should contrib.auth include support for 2fa out of the box?
I agree with Alex, no idea about that particular implementation though. It supports a lot of different implementations of two factor, though I suspect Django wouldn’t need all of those things. I think it would be reasonable to define something like auth_backends, but for 2fa and just ship u2f and TOTP by default. On October 26, 2015 at 1:22:54 PM, Tim Graham (timogra...@gmail.com) wrote: > > > On Trac [1], Alex says, "Django did a tremendous service to its users by > making strong password hashing be the default. The world is pushing > forward, and now 2fa is the next standard that many sites fail to meet. > Django should include support for 2fa out of the box, ideally with support > for both u2f and TOTP (Google Authenticator)." > > > Doing a quick search, I found > https://github.com/Bouke/django-two-factor-auth as a possible existing > implementation that might be a starting point if we decide to integrate > something. What do you think? One sticking point could be that it uses a > ThreadLocals middleware. I didn't look to see how "necessary" that is. > > > [1] https://code.djangoproject.com/ticket/25612 > > -- > You received this message because you are subscribed to the Google Groups > "Django developers > (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/5ae7be8e-949c-4074-b613-04ca2a62fed8%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.562e6323.1664632e.924e%40Draupnir.home. For more options, visit https://groups.google.com/d/optout.
Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3
> On Nov 17, 2015, at 3:03 PM, Aymeric Augustin > wrote: > > On 17 nov. 2015, at 18:00, Tim Graham <mailto:timogra...@gmail.com>> wrote: > >> Do you think it's correct to make the change in Django itself? >> https://github.com/django/django/pull/5676 >> <https://github.com/django/django/pull/5676> -- I didn't track down the >> reason why this changed in Python. > > > > Per PEP 386, the standard scheme is ‘c’, although ‘rc’ is acceptable as well. PEP 386 has been superseded by PEP 440 which recommends “rc” because almost everyone was using “rc” and not “c”. It didn’t seem reasonable to have a decision which was solely bike shedding (it can handle rc as easily as it can handle c) to favor an option that flew in the face of what most projects were doing. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/D79091CB-743C-4D96-8CAF-29718BDA61D9%40stufft.io. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3
> On Nov 17, 2015, at 12:00 PM, Tim Graham wrote:
>
> There was a small hiccup with the 1.9 release candidate yesterday. Unless
> there is some other conflating factor that I missed, generating release
> packages using Python 2 will yield a name like "Django-1.9c1.tar.gz" while
> Python 3 yields "Django-1.9rc1.tar.gz" ('rc' instead of 'c'). Yesterday's
> release must have been the first release candidate to be generated using
> Python 3, and this broke the download page because
> django.utils.version.get_version() (which the website uses) returns "c1" for
> the file name instead of "rc1". I put in a (perhaps temporary) fix to correct
> this: https://github.com/django/djangoproject.com/pull/547
> <https://github.com/django/djangoproject.com/pull/547>
>
> Do you think it's correct to make the change in Django itself?
> https://github.com/django/django/pull/5676
> <https://github.com/django/django/pull/5676> -- I didn't track down the
> reason why this changed in Python.
> While get_version() isn't a public API, it's widely used according to GitHub
> search.
>
Whoever generated the tarballs is probably using a version of setuptools older
than 8.0 in their Python 2 environment and a version of setuptools newer than
8.0 in their Python 3 environment.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/F8D9E8C5-852C-4BDF-A8E9-C3D91CFA7972%40stufft.io.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: annoyance with Python 3.2 support in Django 1.8
> On Nov 26, 2015, at 9:50 AM, Tim Graham wrote: > > The thing that makes me a little uncomfortable is promoting the use of > possibly insecure Python 3.2 well after it's end-of-life. I guess there might > be some Linux distributions that will backport security fixes to their own > versions of Python 3.2, but it seems that Ubuntu 12.04's version of Python > 3.2 didn't incorporate the security fix which caused breakage. FTR the next major version of pip does not support Python 3.2. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/247186BB-8325-4418-9046-AAA5E6C9711D%40stufft.io. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 1.8 shipping invalid .py files in the startapp template
> On Nov 28, 2015, at 11:03 AM, Tim Graham wrote: > > Claude said, "I also encountered this error when using pip 1.5.6 (default > version in Debian stable)." I guess at least some people might not want to > upgrade system packages. > > Is your main opposition to the change a "purity" one? Sure, we could add a > pip version check, but I don't see any downside to the proposed change. > pip 1.5.6 will print the warning but it’s just a warning. Newer pips will silence it. A failure to compile to .pyc never fails the install for pip. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/322CC149-D15F-4125-8A3A-7DE9F7895797%40stufft.io. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Channels integration plan, first draft
That syntax allows you to add extra, opt in lists of dependencies to install. It does not pass through to runtime. Sent from my iPhone > On Dec 18, 2015, at 12:34 PM, Marc Tamlyn wrote: > > On a packaging note, is there a way to use django[channels] type syntax like > flask does? I'm not familiar with the restrictions of this but it may remove > the need for try/except imports. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/A0DC6ED8-E38A-4FB3-A53F-646F4892550A%40stufft.io. For more options, visit https://groups.google.com/d/optout.
Re: Proposal for a new templatetag definition syntax
I'll +1 the restriction of template tags to being arg/kwarg like. I see no
reason, other then porting already written tags, to worry about the ability to
do ``{% mytag foo as bar %}``. Personally I would think it would be desirable
to make this match python as much as possible. Python programmers will find it
more familiar then attempting to turn parameter passing into a parsing
situation, and non python programmers will find it simple enough learn quickly.
Being a restricted grammar, it also has the benefit to have less surprises, you
don't have to worry about how this random tag works, there's one (obvious) way
of doing it.
Something like
class MyTag(tags.Tag):
width = tag.IntegerArgument()
height = tag.IntegerArgument()
using = tag.StringArgument(required=False)
as = tag.StringArgument(required=False, default=None)
which would translate to:
``{% mytag 600 700 %}``
``{% mytag 600 700 as="mytag_return" %}``
``{% mytag 600 700 "template_name.html" %}``
``{% mytag 600 600 using="template_name.html" as="mytag_return" %}``
The only thing I really don't like about this is the ``as`` kwarg. We could
stuff a boolean into a Meta class that is something like ``allow_assignment``
which will support something more like what we have now…
``{% mytag 600 700 as "mytag_return" %}``
``{% mytag 600 700 "template_name.html" as "mytag_return" %}``
``{% mytag 600 700 using="template_name.html" as "mytag_return" %}``
With the stipulation that the as [keyword] must appear as the last item in the
tag.
On Monday, September 12, 2011 at 7:17 AM, Jannis Leidel wrote:
> Hi all,
>
> > For many years, writing templatetags has been among the most hilariously
> > complicated things we Django developers did. Anyone who has written parsing
> > for
> > templatetags, over and over, shares this pain. Further, the current syntax
> > present a tremendous problem for Armin Ronacher's GSOC towards template
> > compilation: template tags define a ``render()`` method, which takes the
> > current context (a stack of dictionaries) and perform some behavior which is
> > opaque to the caller. This is a problem because one of the core objectives
> > of
> > the template compilation infrastructure is to store the template context in
> > Python local variables, rather than in dictionaries. For all these reasons,
> > several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas Obrist,
> > Chris Beaven) just sat down (we actually stood, mostly) and tried to iron
> > out a
> > proposal that solves these problems, taking inspiration from the plethora of
> > libraries that exist today.
> >
> > We ultimately created two possible solutions, one inspired primarily by
> > django-classy-tags and django-templatetag-sugar, the other mostly inspired
> > by
> > django-ttags.
>
> FTR, the app is called django-ttag, not django-ttags.
>
> > We came to a fragile agreement on the first. We primarily
> > evaluated two cases for these, one very simple, the other more complex, and
> > compared the resulting implementations.
> >
> > The first case we considered was a templatetag which takes two, required,
> > arguments. Invocation looks like ``{% mytag foo bar %}``. The two
> > definitions
> > look like:
> >
> > class MyTag(Tag):
> > args = [
> > Argument("foo"),
> > Argument("bar"),
> > ]
> >
> >
> > class MyTag(Tag):
> > foo = Argument()
> > bar = Argument()
> >
> >
> > the second case we considered was a tag which has one required, positional,
> > argument, and two optional, keyword arguments, which can occur in any order,
> > followed by a final, optional keyword argument, meaning any of the following
> > invocations are valid:
> >
> > {% mytag src limit 1 offset 10 %}
> > {% mytag src limit 1 offset 10 with foo %}
> > {% mytag src limit 1 %}
> > {% mytag src offset 10 limit 1 %}
> > {% mytag src %}
> >
> > and the two implementations were:
> >
> > class MyTag(Tag):
> > args = [
> > Argument("source"),
> > Unordered(
> > NamedArgument("limit", required=False),
> > NamedArgument("offset", required=False),
> > ),
> > NamedArgument("as", required=False, resolve=False)
> > ]
> >
> >
> > class MyTag(Tag):
> > source = Argument()
> > limit = NamedArgument(required=False)
> > offset = NamedArgument(required=False)
> > as_ = BasicArgument(required=False)
> >
> > class Meta:
> > ordering = (
> > ('source',),
> > Unordered('limit', 'offset'),
> > ('as_',)
> > )
> >
> > The general consensus was that the second implementation was *very* slightly
> > preferable in the simple case, however it was significantly more
> > complicated in
> > the second case, and thus the first implementation was preferable overall.
>
> I'd like to express my sincere discomfort with the two example cases you used
> to develop the API. At least from the experience I have with writing template
> tags (with the standard API, @simple_tag, django-template-sugar,
> django-classy-tags and django-tagcon/ttag) i
Re: RFC: "universal" view decorators
Gonna add this in here as well as ticket #14512 I think using decorators to modify the way a CBV behaves is the wrong way to go about it, my reasoning is: 1) Decorators on functions make sense, since the only way to modify a function is to wrap it, so decorators provide a shortcut to do so. 2) There's already a standard way to add functionality to a class that has existed for a long time, is well tested, and as a bonus is something that people new to python but not new to programming will understand immediately. 3) Decorating a class is different to how adding any other kind of functionality to a CBV is done. 4) Customizability. Currently your only options to change the way one of the current decorators work is to rewrite it, unless the original author of the decorator thought of your use case, thought it was valid, and added a flag/option for it. - This can be alleviated by using Object based decorators instead of function based, but that becomes uglier too because then you end up having to first subclass the decorator, then decorate the class. 5) Conceptually all the decorator really is doing is mixing in one method anyways, it's just hiding this away and adding more code and complexity, and reducing customizability and readability for the sole purpose of being able to use an @ symbol. 6) Forwards compatibility. The function based generic views have been deprecated. While function based views will probably always be supported, personally I think CBV's are the way forward, and it makes sense to have them be first class citizens as regards to adding in things like requiring logins, with the function based views having the helper code. 7) Backwards compatibility. With a (much simpler) bit of wrapper code, the decorators can easily still be supported (login_required etc) and can internally use the classes and present the same interface as they used to. The major difference being, now they'll be able to subclass them and customize tiny bits of it as well. To just expand a little more in general on this @login_required class ProtectedView(TemplateView): template_name = "secret.html" vs class ProtectedView(LoginRequired, TemplateView): template_name = "secret.html" In the first, the "things" defining how this CBV behaves are in two locations, which makes it harder to read, additionally you end up with a function that wraps a function that wraps a function (to some degree of wrapping) to actually get all of this to work. Each layer of wrapping adds another layer of indirection, and adds another layer of confusion for someone attempting to read the code. I really dumbed down example would be https://gist.github.com/1220512 . Obviously that isn't working code, but it gives a general idea of what I mean. Obviously if that is the path that is chosen it will need to be cleaned up and made to actually work. Hopefully this email makes sense. I just hope that since CBV's are new we can use this as an opportunity to do things in a cleaner, consistent and more generic way instead of continuing the old way (that made sense for functions) for the sake of doing it the same way. tl;dr; Using Mixins to add in functionality to a CBV makes way more sense then using a decorator which is essentially going to be doing the same thing as a mixing would, it just makes finding what is going on harder, makes customizing the decorator harder and/or uglier, and goes against the way functionality is currently added to a CBV. On Thursday, September 15, 2011 at 4:44 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > I'd like to convert all the view decorators built into Django to be > "universal" -- so they'll work to decorate *any* view, whether a > function, method, or class. I believe I've figured out a technique for > this, but I'd like some feedback on the approach before I dive in too > deep. > > Right now view decorators (e.g. @login_required) only work on > functions. If you want to use a decorator on a method then you need to > "convert" the decorator using method_decorator(original_decorator). > You can't use view decorators on class-based views at all. This means > making a class-based view require login requires this awesomeness:: > > class MyView(View): > @method_decorator(login_required) > def dispatch(self, *args, **kwargs): > return super(MyView, self.dispatch(*args, **kwargs) > > This makes me sad. It's really counter-intuitive and relies on a > recognizing that functions and methods are different to even know to > look for method_decorator. > > #14512 proposes a adding another view-decorator-factory for decorating > class-based views, which would turn the above into:: > > @class_view_decorator(login_required) > class MyView(View): > ... > > This makes me less sad, but still sad. Factory functions. Ugh. > > I want @login_required to work for anything:: > > @login_required > class MyView(View): > ... > > class Something(object): > @login_required >
Re: RFC: "universal" view decorators
Documentation is being worked on, and is orthogonal to the current discussion of how to handle things like requiring logins with the new CBVs. On Friday, September 16, 2011 at 12:08 PM, Javier Guerra Giraldez wrote: > On Fri, Sep 16, 2011 at 8:34 AM, Reinout van Rees (mailto:rein...@vanrees.org)> wrote: > > Watch out, in general, with adding more and more mixins. > > > > I explained just the most basic template CBV to a colleague: there are just > > two mixins and a base class there, but his eyes already started to glaze > > over because I had to jump from class to class to class to explain how it > > all hung together. > > that is my own reaction too when trying to see where in the code is > everything that i knew from the old generic view functions. > > mixins are a great way to encapsulate specific, well defined behavior; > but tracing the code is a real chore, even so clean code as Django's. > I guess that when you know by heart exactly what does each one do, > they become a pleasure to use. > > So, my two cents: please do the documentation first. once there's a > single place to find exactly what the purpose, mechanism and span of > each one, then adding more would be welcomed. > > > -- > Javier > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: RFC: "universal" view decorators
Existing in python != pythonic. (not stating that class decorators aren't pythonic, but that argument is flawed) Just watched the video my thoughts regarding it, and this discussion. The Augment pattern is a terrible use case for class decorators when you are just overriding methods. It's nothing more then Mixins with a different syntax, for no reason that I can determine other then someone not liking the way declaring a mixin looks, functionally you are still mixing in. What benefit do you get from hiding the fact you are really just doing a Mixin? With the code Jacob posted there is… 16? (My math might be wrong) different permutations of code flow just to support universal decorators. The order would matter in the sense that any mixins would have to come before the base view class, so: class ProtectedView(LoginRequired, View) is valid but class ProtectedView(View, LoginRequired) is not. But this is just python, there's nothing magical about object inheritance and in python object inheritance is left to right. Additionally, as I just thought, there is a way to satisfy both camps. The support code I proposed to allow @login_required with Mixins to still work with function based views could include the universal decorator approach that Jacob included. That would be a change so that the actual "is this a user, are they logged in etc" logic would live in a class that could be mixed in, then the support code for functions would use that class and wrap the test portions around the function view, and then the universal decorator code could just do the Augment pattern. All camps == Happy? People who prefer mixins can mixin, people who prefer @decorators can decorate, everything is supported from one code base. On Friday, September 16, 2011 at 1:45 PM, Roald de Vries wrote: > On Sep 16, 2011, at 6:19 PM, Donald Stufft wrote: > > > Documentation is being worked on, and is orthogonal to the current > > discussion of how > > to handle things like requiring logins with the new CBVs. > > I just watched "Class Decorators: Radically Simple" by Jack Diederich, > who wrote the class decorators PEP, and I think it's very useful to > watch (25 min.) for this discussion. According to him it is good > practice to return the class that is decorated, which I think we > should follow, and which solves the biggest practical problems with > decorating. Moreover, the fact that class decorators exist indicate > that they are pythonic. So +1 for the decorators. > > Considering the mixins: IMHO, the order of base classes shouldn't > matter. Can this be satisfied by the mixin-approach? > > @Carl Meyer: I would opt for applying decorators *in* the class, so > you can still derive from it. Like:: > > class MyView(View): > @classonlymethod > def as_view(cls, *args, **kwargs): > return login_required(super(MyView, cls).as_view(*args, > **kwargs)) > > Cheers, Roald > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: RFC: "universal" view decorators
unittest.skip isn't a Mixin, it turns the class into an exception and raises it. django.test.utils.override_settings is a mixin and it's terrible, it dynamically creates a new subclass, and overrides 2 methods. It's magic and more complex then need be. On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote: > > > On Fri, Sep 16, 2011 at 9:47 PM, James Bennett (mailto:ubernost...@gmail.com)> wrote: > > We have the following constraints: > > > > 1. Django supports class-based views. > > > > 2. Django supports function-based views (ultimately these are the same > > thing, which is that Django supports anything as a 'view' so long as > > it's callable, accepts an HttpRequest as its first positional argument > > when being called and either returns an HttpResponse or raises an > > exception). > > > > 3. The natural way to add processing in/around a class is subclassing > > and either overriding or mixing in. > > > > 4. The natural way to add processing in/around around a function is > > decorating. > > > > Any solution to this needs to address those constraints, and allow > > code to look and feel natural. > > > > Based on that, some arrangement which allows the same basic logic to > > exist in a "mixin" (I dislike that word) for classes and a decorator > > for functions seems most appropriate, even if it does mean having two > > ways to do things -- that's a distinction I think we can live with, as > > people will appreciate that it doesn't result in strange-looking code. > > > > > > -- > > "Bureaucrat Conrad, you are technically correct -- the best kind of > > correct." > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-developers@googlegroups.com > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto:django-developers%2bunsubscr...@googlegroups.com). > > For more options, visit this group at > > http://groups.google.com/group/django-developers?hl=en. > > > > I agree with all your points, except #3, I think it's an over simplification. > There's another way to change a class: class decorators. And there's ample > precedent for their use in such a manner, unittest's skip decorators, our own > decorators for swapping settings during testing, etc. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: RFC: "universal" view decorators
The main reason I got into the implementation is because I think it's an important detail, decorating classes in my opinion is the right thing to do when what you are doing is something along the lines of registering the class, or doing some sort of validation and raising an exception etc. django.test.utils.override_settings when decorating a class is nearly functionally equivalent to adding a mixin, it takes the base class, and adds in 2 methods. It's not actually a mixing, but I meant it's nearly equivalent to a mixin (in the TestCase case). I don't think class decorators are the right way to do this sort of pseudo mixin in a very opaque way. That being said… Is there a problem with turning the current decorators into mixins, and support both decorating the class, and mixing in from the same code base? It's somewhat unpythonic in the 2 ways to do it camp, but it'd all be done with 1 code base, and would satisfy both camps I believe? On Friday, September 16, 2011 at 10:32 PM, Alex Gaynor wrote: > > > On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > unittest.skip isn't a Mixin, it turns the class into an exception and > > raises it. > > > > It doesn't *turn* a class into anything, it simply returns a function, > instead of a new class, and the function raises SkipTest, the point wasn't > the implementation detail, but rather the syntax and pattern at work. > > > django.test.utils.override_settings is a mixin and it's terrible, it > > dynamically creates a new subclass, and overrides 2 methods. It's magic and > > more complex then need be. > > > > > a) it's not a mixin > b) yes, it creates subclasses, because the alternative is mutating the > original class, which isn't how people generally expect decorators to work, > we expect them to be syntactic sugar for: > > A = wrap(*args)(A) > > such that we can also do > > B = wrap(*args)(A) > > and have two classes (or functions). > > c) I'm not sure how it's magic, but certainly if it's too complex we'd take > patches to simplify the implementation. > > > > > On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote: > > > > > > > > > > > > > > > On Fri, Sep 16, 2011 at 9:47 PM, James Bennett > > (mailto:ubernost...@gmail.com)> wrote: > > > > We have the following constraints: > > > > > > > > 1. Django supports class-based views. > > > > > > > > 2. Django supports function-based views (ultimately these are the same > > > > thing, which is that Django supports anything as a 'view' so long as > > > > it's callable, accepts an HttpRequest as its first positional argument > > > > when being called and either returns an HttpResponse or raises an > > > > exception). > > > > > > > > 3. The natural way to add processing in/around a class is subclassing > > > > and either overriding or mixing in. > > > > > > > > 4. The natural way to add processing in/around around a function is > > > > decorating. > > > > > > > > Any solution to this needs to address those constraints, and allow > > > > code to look and feel natural. > > > > > > > > Based on that, some arrangement which allows the same basic logic to > > > > exist in a "mixin" (I dislike that word) for classes and a decorator > > > > for functions seems most appropriate, even if it does mean having two > > > > ways to do things -- that's a distinction I think we can live with, as > > > > people will appreciate that it doesn't result in strange-looking code. > > > > > > > > > > > > -- > > > > "Bureaucrat Conrad, you are technically correct -- the best kind of > > > > correct." > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Django developers" group. > > > > To post to this group, send email to > > > > django-developers@googlegroups.com > > > > (mailto:django-developers@googlegroups.com). > > > > To unsubscribe from this group, send email to > > > > django-developers+unsubscr...@googlegroups.com > > > > (mailto:django-developers%2bunsubscr...@googlegroups.com). > > > > For more options, visit thi
Re: RFC: "universal" view decorators
I just got my wisdom teeth removed so i'm not exactly feeling the greatest, however I committed what I've done so far and pushed to my copy of django on github. The goal is to provide a Mixin for class based views, a decorator for class based views, a decorator for methods, and a decorator for functions, all from the same codebase. Currently I have the decorator for classes working, and the mixin working. I have the places where the other 2 will go but from a combination of not being very good at decorators, and not feeling well I haven't finished it yet. Anyways here's what I've gotten so far: https://github.com/dstufft/django/compare/master...universal-mixin-decorators On Wednesday, September 21, 2011 at 8:26 AM, Roald de Vries wrote: > Hi all, > > Haven't seen a comment on this topic for a few days, so was wondering if a > core dev can make a design decision yet. I have some spare time in the > remainder of this week, so if the (universal) decorator-approach is chosen, I > should be able to finish it shortly (the mixin-approach is a bit harder to > estimate). > > Cheers, Roald > > > On Sep 17, 2011, at 4:32 AM, Alex Gaynor wrote: > > On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft > (mailto:donald.stu...@gmail.com)> wrote: > > > unittest.skip isn't a Mixin, it turns the class into an exception and > > > raises it. > > > > > > > It doesn't *turn* a class into anything, it simply returns a function, > > instead of a new class, and the function raises SkipTest, the point wasn't > > the implementation detail, but rather the syntax and pattern at work. > > > > > django.test.utils.override_settings is a mixin and it's terrible, it > > > dynamically creates a new subclass, and overrides 2 methods. It's magic > > > and more complex then need be. > > > > > > > > > a) it's not a mixin > > b) yes, it creates subclasses, because the alternative is mutating the > > original class, which isn't how people generally expect decorators to work, > > we expect them to be syntactic sugar for: > > > > A = wrap(*args)(A) > > > > such that we can also do > > > > B = wrap(*args)(A) > > > > and have two classes (or functions). > > > > c) I'm not sure how it's magic, but certainly if it's too complex we'd take > > patches to simplify the implementation. > > > > > > > > On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote: > > > > > > > > > > > > > > > > > > > > > On Fri, Sep 16, 2011 at 9:47 PM, James Bennett > > > (mailto:ubernost...@gmail.com)> wrote: > > > > > We have the following constraints: > > > > > > > > > > 1. Django supports class-based views. > > > > > > > > > > 2. Django supports function-based views (ultimately these are the > > > > > same > > > > > thing, which is that Django supports anything as a 'view' so long as > > > > > it's callable, accepts an HttpRequest as its first positional > > > > > argument > > > > > when being called and either returns an HttpResponse or raises an > > > > > exception). > > > > > > > > > > 3. The natural way to add processing in/around a class is subclassing > > > > > and either overriding or mixing in. > > > > > > > > > > 4. The natural way to add processing in/around around a function is > > > > > decorating. > > > > > > > > > > Any solution to this needs to address those constraints, and allow > > > > > code to look and feel natural. > > > > > > > > > > Based on that, some arrangement which allows the same basic logic to > > > > > exist in a "mixin" (I dislike that word) for classes and a decorator > > > > > for functions seems most appropriate, even if it does mean having two > > > > > ways to do things -- that's a distinction I think we can live with, > > > > > as > > > > > people will appreciate that it doesn't result in strange-looking > > > > > code. > > > > > > > > I agree with all your points, except #3, I think it's an over > > > > simplification. There's another way to change a class: class > > > > decorators. And there's ample precedent for their use in
Re: Cleaning up manage.py and import paths
+1 mkdir project cd project git init django-admin.py startproject project Is basically what I already do, and either way it's not terrible hard to switch, but I think it makes a lot of sense to use CWD as the top level directory. On Wednesday, October 12, 2011 at 10:59 AM, Luke Plant wrote: > On 12/10/11 15:06, Carl Meyer wrote: > > > > > > On 10/12/2011 07:53 AM, Russell Keith-Magee wrote: > > > I'm not convinced it's a bad idea. From an pedagogical perspective, > > > it's easy to explain -- Make a directory to contain all the bits for > > > your project, move into the directory, then bootstrap your project. > > > > > > > > > It's not so easy to explain why startproject can't just create the > > directory to contain all the bits it creates in the first place, instead > > of making me do it manually :-) > > > > > I think there could be at least one good reason - if the developer has > already created a directory in which to store all the stuff, which would > actually be my natural instinct especially when it comes to a new > project with VCS: > > $ mkdir foo > $ cd foo > $ hg init > > # OK, now what am I going to put in it? Oh, a Django project. > > In fact, it might be good idea to encourage use of VCS by mentioning it. > If I remember SVN correctly, you would actually need to think about it > before 'mkdir foo' - you 'svnadmin create', then checkout the empty repo > to start working. For either of these workflows, you probably wouldn't > want startproject creating your main directory. I actually like the idea > that Django is not supposed to be managing your entire project - rather, > your project uses Django. > > Luke > > -- > "Oh, look. I appear to be lying at the bottom of a very deep, dark > hole. That seems a familiar concept. What does it remind me of? Ah, > I remember. Life." (Marvin the paranoid android) > > Luke Plant || http://lukeplant.me.uk/ > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: RFC: "universal" view decorators
Sorry for the delay, Here's a possible method of handling the idea of adding the additional functionality of things like requiring logins to both FBV's and CBV's in a way that I feel is consistent with the methodologies of each of those types (decorators for FBV, Mixins for CBV). This also keeps all the logic in one place. It allows for anyone (even people using FBV's) to easily extend the decorators and create their own versions of them, without having to rewrite the whole thing (which was one of the major reasons I like CBV's). It shouldn't break anything, the tests are passing and a functional test in a browser they all appear to be working. https://github.com/dstufft/django/compare/master...mixin-decorators Thoughts? Good Idea? Bad Idea? On Thursday, September 22, 2011 at 2:49 AM, ptone wrote: > > > On Sep 21, 8:44 am, Donald Stufft (http://gmail.com)> wrote: > > > > > > The goal is to provide a Mixin for class based views, a decorator for class > > based views, a decorator for methods, and a decorator for functions, all > > from the same codebase. > > > > Currently I have the decorator for classes working, and the mixin working. > > I have the places where the other 2 will go but from a combination of not > > being very good at decorators, and not feeling well I haven't finished it > > yet. > > I like the overall direction of this approach (mixin class as the root > container of functionality) - but a number of technical issues still > need to have a resolution demonstrated (ie the decorating function > behavior) > > One, perhaps pony, of a universal approach, would be to convert the > decorator kwargs into class attributes, so that they could be > overriden in subclasses of a decorated parent, something easy to do > with mixins as the starting point. > > Also on a somewhat related note, a better option for middleware > process_view to interact with class based views > > -Preston > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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: Localization on User model
This is a harder problem then just that. While doing that would allow a solution to the name problem, there are more problems django.contrib.auth's User model and it would be best to come up with a generic solution that fixes all of these problems, instead of applying bandaid fixes. On Thursday, November 10, 2011 at 12:53 PM, hcarvalhoalves wrote: > I believe the solution is to actually figure a migration path to move > everything that is non-essential to outside the User model. To > identify a User, it should be enough to have username, password and > permissions, and have the rest of the fields live in a > django.contrib.auth.models.DefaultUserProfile. > > On 22 set, 02:26, lvella http://gmail.com)> wrote: > > The User model included in Authentication subsystem is very annoying > > to use here in Brazil. The common "first name" and "last name" method > > of identifying people found in English speaking countries is very > > unnatural to our culture, which people usually have two or more family > > names. It is a cultural trait of here that renders unsuitable the > > splitting of the name into first and last on the model. There are > > countries/cultures with other people naming customs that is also hard > > to localize with this model [1][2]. > > > > What about changing this in future versions? Maybe simply a > > "true_name" field would do? Or maybe a way to customize the fields in > > the User model. > > > > [1]:http://en.wikipedia.org/wiki/Arabic_name > > [2]:http://en.wikipedia.org/wiki/Eastern_Slavic_naming_customs > > > > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@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.
