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
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
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/conventio
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:
> * wi
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 f
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 bet
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 eno
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 f
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 af
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
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.
> >
>
>
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
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, Cl
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:
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 whic
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
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 > (mail
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
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:5
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 frustrat
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
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 pa
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
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. Ho
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:
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 decide
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
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
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 y
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 uniqu
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 w
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 Settin
*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.
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 fol
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 statem
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://o
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
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
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&#
x27;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, 20
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, Victo
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
en 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
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
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
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 Tues
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 t
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
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 develo
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
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 mes
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
> setting
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 u
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
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 h
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, 20
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
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 o
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
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
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 t
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 an
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 some
om/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
Thoughts?
-----
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
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
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
igrate 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
int 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: 0x6E3CBCE93372DC
cal 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
ay, I wanted to take a few minutes and share the impressions I've had to
> date - perhaps this way, others will have a better experience in future.
>
> Thanks for reading
>
> Simon
>
> --
> You received this message because you are subscribed to the Google Groups
suming
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
De
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
roblem 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 id
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 oth
ngo-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
gt; --
> 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.c
gt;
>
>
>
>
>
>
> --
> 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
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
"Djan
rs@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/op
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
> &
en 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 Goog
endency 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 F
elopers.
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
ers/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 subsc
nds “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: 0x6E
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: 0x6E3CBCE9337
heir 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 // 7C6
on 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 i
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 fam
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 programmer
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)
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.o
riday, 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.
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
s 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:
> > unittes
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.
> > >
> >
>
+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 wrot
ing, 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, D
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
1 - 100 of 146 matches
Mail list logo
