Re: Extend support for long surnames in Django Auth

[Donald Stufft]

> On Jul 30, 2016, at 4:40 PM, Aymeric Augustin 
> <aymeric.augus...@polytechnique.org> wrote:
> 
> I have trouble believing that a significant number of people are used to 
> typing 100+ characters when inputting their name into a website — let alone 
> that a significant number of people have a last name that contains more than 
> 100 characters and that isn’t a joke. How would it fit on a passport?


See #6 of 
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

—
Donald Stufft



-- 
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/5DE6F3BD-2AFC-4DC2-864F-D68D333587B4%40stufft.io.
For more options, visit https://groups.google.com/d/optout.

Re: Should we require pytz for timezone support in Django?

[Donald Stufft]

> On Jun 4, 2016, at 1:18 PM, Aymeric Augustin 
> <aymeric.augus...@polytechnique.org> wrote:
> 
> That doesn’t sound optimal because pytz’ release cycle is tied to the TZ 
> database’s cycle, which is different from Django’s.


IMO just stick pytz in install_requires and be done with it. It’s a very 
trivial dependency, and is available as a Wheel, various eggs, and sdists. Just 
to put some numbers behind this:

93.6% of all downloads of Django from PyPI [1] are originating using a tool 
that will properly support dependencies out of the box. Another 3.5% of that 
are using a tool that we can’t detect— this is largely older versions of pip 
and devpi that didn’t accurately report themselves in the User-Agent header, so 
is going to also be largely things that support dependencies properly. Another 
2.3% of the downloads are coming from mirroring clients like devpi, 
bandersnatch, etc where it’s likely the consumers are mostly or entirely 
automated tooling that understands dependencies again.

Finally, 0.5% of all downloads for Django from PyPI are made using the browser, 
where people may or may not be passing that to a tool that properly understands 
dependencies.

In addition, the latest versions of all Python versions that Django supports 
come with pip already available, eliminating the bootstrapping issues.

Given these numbers, and the existing of ensurepip, I think it’s easily time 
for Django to just start depending on things, particularly when those things 
are something as trivial to install as a pure python library like pytz.

[1] Using the now public metrics database.

—
Donald Stufft



-- 
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/F935353C-45B1-414E-8851-57DAAFA1BB57%40stufft.io.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

[Donald Stufft]

> On May 6, 2016, at 3:49 PM, Aymeric Augustin 
> <aymeric.augus...@polytechnique.org> wrote:
> 
> Sure, this works for WSGI, but barring significant changes to Django, it 
> doesn’t make it convenient to handle WSGI synchronously and WebSockets 
> asynchronously with the same code base, let alone in the same process.

User level code would not be handling WebSockets asynchronously, that would be 
left up to the web server (which would call the user level code using 
deferToThread each time a websocket frame comes in). Basically similar to 
what’s happening now, except instead of using the network and a queue to allow 
calling sync user code from an async process, you just use the primitives 
provided by the async framework.

-----
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CDDB586D-A787-461D-99E2-483A90E2572A%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

[Donald Stufft]

> On May 6, 2016, at 1:45 PM, Andrew Godwin <and...@aeracode.org> wrote:
> 
> Want to just cover a few more things I didn't in my reply to Aymeric.
> 
> On Fri, May 6, 2016 at 9:11 AM, Donald Stufft <don...@stufft.io 
> <mailto:don...@stufft.io>> wrote:
> 
> In short, I think that the message bus adds an additional layer of complexity
> that makes everything a bit more complex and complicated for very little 
> actual
> gain over other possible, but less complex solutions. This message bus also
> removes a key part of the amount of control that the server which is 
> *actually*
> receiving the connection has over the lifetime and process of the eventual
> request.
> 
> True; however, having a message bus/channel abstraction also removes a layer 
> of complexity that is caring about socket handling and sinking your 
> performance by even doing a slightly blocking operation.
> 
> In an ideal world we'd have some magical language that let us all write 
> amazing async code and that detected all possible deadlocks or livelocks 
> before they happened, but that's not yet the case, and I think the worker 
> model has been a good substitute for it in software design generally.
> 
> 
> For an example, in traditional HTTP servers where you have an open connection
> associated with whatever view code you're running whenever the client
> disconnects you're given a few options of what you can do, but the most common
> option in my experience is that once the connection has been lost the HTTP
> server cancels the execution of whatever view code it had been running [1].
> This allows a single process to serve more by shedding the load of connections
> that have since been disconnected for some reason, however in ASGI since
> there's no way to remove an item from the queue or cancel it once it has begun
> to be processed by a worker proccess you lose out on this ability to shed the
> load of processing a request once it has already been scheduled.
> 
> But as soon as you introduce a layer like Varnish into the equation, you've 
> lost this anyway, as you're no longer seeing the true client socket. 
> Abandoned requests are an existent problem with HTTP and WSGI; I see them in 
> our logs all the time.


I don’t believe that to be true. For example: The client connects to Varnish, 
Varnish connects to h2o, h2o connections to gunciorn which is running WSGI. The 
client closes the connection to Varnish, so Varnish closes the connection to 
h2o, so h2o closes the connection to gunicorn who can then throw a SystemExit 
exception and halt execution of the code.

> 
> 
> This additional complexity incurred by the message bus also ends up requiring
> additional complexity layered onto ASGI to try and re-invent some of the
> "natural" features of TCP and/or HTTP (or whatever the underlying protocol 
> is).
> An example of this would be the ``order`` keyword in the WebSocket spec,
> something that isn't required and just naturally happens whenever you're
> directly connected to a websocket because the ``order`` is just whatever bytes
> come in off the wire. This also gets exposed in other features, like
> backpressure where ASGI didn't currently have a concept of allowing the queue
> to apply back pressure to the web connection but now Andrew has started to 
> come
> around to the idea of adding a bounding to the queue (which is good!) but if
> the indirection of the message bus hadn't been added, then backpressure would
> have naturally occurred whenever you ended up getting enough things processing
> that it blocked new connections from being ``accept``d which would eventually
> end up filling up the backlog and then making new connections hang block
> waiting to connect. Now it's good that Andrew is adding the ability to bound
> the queue, but that is something that is going to require care to tune in each
> individual deployment (and will need regularly re-evaluated) rather than
> something that just occurs naturally as a consequence of the design of the
> system.
> 
> Client buffers in OSs were also manually tuned to begin with; I suspect we 
> can hone in on how to make this work best over time once we have more 
> experience with how it runs in the wild. I don't disagree that I'm 
> reinventing existing features of TCP sockets, but it's also a mix of UDP 
> features too; there's a reason a lot of modern protocols back onto UDP 
> instead of TCP, and I'm trying to strike the balance.
> 
> 
> Anytime you add a message bus you need to make a few trade offs, the 
> particular
> trade off that ASGI made is that it should prefer "at most once" delivery of
> messages and low latency to guaranteed delivery. This choice is likely one of
> the sanest ones you ca

Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

[Donald Stufft]

ing which allows
you to make several HTTP requests on a single HTTP connection without waiting
for the responses before sending each one. Given the nature of ASGI it would be
very difficult to actually support this feature without either violating the
RFC or forcing either Daphne or the queue to buffer potentially huge responses
while it waits for another request that came before it to be finished whereas
again you get this for free using either async IO (you just don't await the
result of that second request until the first request has been processed) or
with WSGI if you're using generators (you just don't iterate over the result
until you're ready for it).

I believe the introduction of a message bus here makes things inherently more
fragile. In order to reasonable serve web sockets you're now talking about a
total of 3 different processes that need to be run (Daphne, Redis, and Django)
each that will exhibit it's own failure conditions and introduces additional
points of failure. Now this in itself isn't the worst thing because that's
often times unavoidable anytime you scale beyond a single process, but ASGI
adds that complication much sooner than more traditional solutions do.

ASGI purports to make it easier to gracefully restart your servers by making it
possible to restart the worker servers (since there is no long live open
connections to them) and simply spin up new ones. However, that's not really
the whole story, because while that is true, it really only exists as long as
your code changes don't touch something that Daphne needs to be aware of in
order to process incoming requests. As soon as Daphne needs restarted then
you're back in the same boat of needing another solution to graceful restarts
and since Daphne depends on project specific code, it's going to require to be
restarted much more frequently than other solutions that don't. It appears to
me like it would be difficult to be able to automatically determine whether or
not Daphne needs a restart on any particular deployment, so it will be common
for people to just need to restart the whole stack anyways.

So what sort of solution would I personally advocate had I the time or energy
to do so? I would look towards what sort of pure Python API (like WSGI itself)
could be added to allow a web server to pass websockets down into Django. I
admit that in some cases people would then need to layer on their own message
buses (since that's just about the only reasonable way to implement something
like Group().send()) but even here they'd be able to get added gains and "for
free" features by utilizing something that specializes in this sort of
multicast type of message (a pub/sub message bus more or less). Of course
currently no web servers would support whatever this new "WSGI but for
WebSockets" would be, so you'd need to implement something like Daphne that
could handle it in the intrim (or possibly forever if nobody implemented it)
but that's the same case as with ASGI now.

Handling scaling out to multiple processes and graceful restarts would be
handled the way they are today. Either you'd have some master process that
isn't specific to the Django code (like Daphne is) that would spin up new
processes, start sending traffic to them and then close out the old processes.
This generalizes out past a single machine too, where you'd have something like
HAProxy load balancing between machines and able to gracefully stop sending
requests to once instance and start sending them to a new instance. For
Websockets anytime you have a persistent connection to your worker you'll need
some way trigger your clients to disconnect and reconnect (so they get
scheduled onto the new server/process), but that's something you'll need with
ASGI anyways anytime you need to restart Daphne anyways (and since the thing
intiating the restart there is tied to your application code, a hook can be
provided that gets called on shut down that lets the application do some
application specific thing to tell people to reconnect).

In this solution, since everything is just HTTP (or Websockets, or whatever)
all the way down you end up getting to reuse all of the battle tested pieces
that already exist like HAProxy. It's also easier to simply drop in another
piece, possibly written in another language or another technology since
everywhere in the stack speaks HTTP/Websocket and you don't have to go and
teach say, Erlang how to ASGI.

[1] This gets exposed in a variety of ways in different servers. In gunicorn it
shows up as a SystemExit exception, in uWSGI I believe it shows up as an
IOError. In something like Twisted or AsyncIO it would likely show up as a
CancelledError.


-
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 unsubscr

Re: Vendoring multipledispatch

[Donald Stufft]

> On Apr 7, 2016, at 1:31 AM, Sylvain Fankhauser <sylvain.fankhau...@gmail.com> 
> wrote:
> 
> The only problem I can see is dependencies conflicts, where Django would need 
> package X version > 1.0 and another installed package would need package X 
> version 0.9. I have this issue with a project of mine that required six >= 
> 1.10 and for some reason Xcode on OSX with the system Python (ie. not 
> installed with brew for example) forces you to have six 1.9, which comes 
> before in the PYTHONPATH. I know that Lektor <https://www.getlektor.com/> for 
> example solves this by having an install script 
> <https://www.getlektor.com/install.sh> that creates a virtualenv and installs 
> it inside this virtualenv.
> 
Yea. This is a problem with OS X Python from the system. They ship a bunch of 
libraries that are on the sys.path by default but which can’t be replaced (even 
more so in the most recent version of OS X when SIP is turned on which prevents 
installing anything into the system Python as well). This issue has been 
reported to Apple and I think there is a good chance that they’ll have it fixed 
in a way that a user can install packages into.

Overall though, users shouldn’t install things into their system Python which I 
think is supported by the fact that the system Python on recent versions of OS 
X are not writable, even with sudo, unless you disable one of the major 
security components of your machine. That doesn’t affect just any potential 
dependencies Django might have, but also Django itself.

> Also James mentioned that "back in the days pip wasn't as awesome as it is 
> today", but we have to keep in mind that a lot of OSes still use an old pip 
> version by default (Debian stable for example ships pip 1.5 
> <https://packages.debian.org/search?keywords=python-pip=names=stable=all>).
> 

pip 1.5 is new enough that you get most of the reliability benefits. Major 
things it’s missing are:

* Implicit wheel cache, allowing sdists to only be compiled once and the built 
binaries reused between installs.
* Implicit http cache, allowing files to only need to be downloaded once.
* Manylinux1 support, allowing people to publish binary wheels for Linux 
systems to PyPI.
* Conditional dependencies inside of a sdist without a hack workaround.

Minor, but nice quality of life things are:

* Massively reduced verbosity on install.
* Nicer progress bars.

> Anyway as long as Django is installed in a virtualenv this shouldn't be too 
> much of an issue, but I think we should expect some issues from the users and 
> these should be documented otherwise people might get frustrated.
> 
> Cheers,
> Sylvain
> 

-
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CCC99F08-1813-4E09-AE4B-B5E4BF58F618%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Vendoring multipledispatch

[Donald Stufft]

> On Apr 7, 2016, at 8:20 AM, Erik Cederstrand <erik+li...@cederstrand.dk> 
> wrote:
> 
> 
>> Den 6. apr. 2016 kl. 13.42 skrev Marc Tamlyn <marc.tam...@gmail.com>:
>> 
>> Does anyone (potentially from OS packaging worlds maybe) have a good reason 
>> NOT to have a dependency?
> 
> Here is a list off the top of my head. This is not necessarily an argument 
> against dependencies, just some things to consider.
> 
> 
> 1: Availability. If Django depends on version x.y.z and x.y.z is removed from 
> PyPI, or the whole package is deleted, then Django is no longer installable 
> (google "NPM kik" for a recent example).
> 
> 2: Customization. We need to tweak functionality in some non-upstreamable 
> way, cherry-pick new functionality, or fix security issues before they are 
> published on PyPI.
> 
> 3: Version conflicts, as mentioned by Sylvain.
> 
> 4: Security/stability. We depend on version x.y and a witty developer uploads 
> dependency x.y.z+1 with an Easter egg, or the PyPI developer account is 
> hacked and x.y is replaced.
> 
> 
> These issues are amplified in a world where many people have automated 
> production deployments running 'pip install -U -r requirements.txt'. Issues 
> could spread very fast.
> 
> This may not be much different than what people are already exposed to with 
> their own project dependencies, but vendoring (directly or by dependency) is 
> endorsement by the Project, so any issues in the dependencies will fall back 
> on the Project.
> 


For 1, 3, and 4, Django is already exposed to these problems for the vast 
majority of use cases since if you want to use any database other than SQLite 
then you have to install something or if you want to use an ImageField, or 
bcrypt, etc. Having ``pip install Django`` work but not ``pip install Django 
psycopg2`` when you’re running a site that uses PostgreSQL doesn’t get you 
anything extra there.

-
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/989F87C0-B9E1-4745-BCFC-ED19DC61C37F%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Vendoring multipledispatch

[Donald Stufft]

> On Apr 4, 2016, at 7:50 AM, Michał 'Khorne' Lowas-Rzechonek 
> <khor...@gmail.com> wrote:
> 
> So, I think I'm left with two options: reinvent 
> https://pypi.python.org/pypi/multipledispatch, or import that into 
> django.utils along with the license etc.
> 

Without looking at this specific thing too closely, maybe it’s time for Django 
to gain a required dependency instead of bundling or reinventing everything?


-
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3B506FDB-54D2-440D-8295-05DFDB88719D%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Feedback on Django Channels

[Donald Stufft]

> On Mar 22, 2016, at 1:24 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> 
> I do think encrypting the Redis channel layer is something we should offer: 
> Redis out of the box doesn't do transport-layer encryption, which is going to 
> make Channels a hard sell to anyone with any for of regulatory/compliance 
> requirements. [1]


I don’t know a whole lot about the design of channels, so ymmv but I tend to be 
a bit nervous on trying to implement a “mini” replacement to something like TLS 
because it’s fairly tricky to get right. Even using something like fernet, you 
still have things like replay attacks and such that may be possible (unless 
channels design prevents it) that TLS already has baked in protection for.

It is true that reds doesn’t do TLS out of the box, but adding it is not really 
*that* hard, you typically just bind redis to a localhost only port (which I 
think it does by default) and then install stunnel bound to a public port to 
“unwrap” the TLS before passing it on to redis. On the client side you may need 
to also run stunnel to “wrap” the stream with TLS if your client does not 
support it, but redis-py supports TLS’d connections natively so, at least from 
Python, it’s not any harder to connect to a TLS’d Redis server.

-----
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1706B9DC-7479-43CD-897B-330F1E9C2F43%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: remove support for unsalted password hashers?

[Donald Stufft]

> On Feb 5, 2016, at 10:04 AM, Tim Graham <timogra...@gmail.com> wrote:
> 
> I'm not sure if we can keep support for unsalted hashes while removing the 
> special logic in identify_hasher() for those hashers since they don't confirm 
> to Django's normal hash format?
> https://github.com/django/django/pull/6082/files#diff-2f01db46550174ad3e55be7070b98ec9
> 
> I guess a use case where you are integrating with a legacy system that 
> doesn't allow upgrading of passwords wouldn't allow the "wrapping hashers" 
> technique.

Seems like it would be trivial to migrate the database to make the hashed 
password conform to the format.

-
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/196F5D27-B720-4D9E-8EC4-074B18E9E8E2%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: remove support for unsalted password hashers?

[Donald Stufft]

> 
> On Feb 5, 2016, at 7:05 AM, Rafał Pitoń <rafio.x...@gmail.com> wrote:
> 
> Will I still be able to implement unsalted hasher if I so desire?
> 
> Don't get me wrong, I understand thats pretty crappy way to store password, 
> but there are times when you inherit large set of data from site that you are 
> moving from some old PHP contraption that happens to be around since 2006, is 
> big (>100 users), ran by company that dominates one of nation's markets 
> and says "absolutely no" on making all those housewifes reset passwords, and 
> your passwords happen to use md5(md5(pass) + md5(pass)) for passwords?


You can implement them still sure, there’s nothing stopping you.


You can also do bcrypt(md5(md5(pass) + md5(pass)) and then you’ve fixed the 
issue without needing to issue a password reset.

-
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0A69E02C-F025-4E4B-9709-8D135BA5539C%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: remove support for unsalted password hashers?

[Donald Stufft]

> On Feb 2, 2016, at 1:52 PM, Tim Graham <timogra...@gmail.com> wrote:
> 
> Just to be clear, my proposal here is only about removing 
> UnsaltedSHA1PasswordHasher and UnsaltedMD5PasswordHasher. The salted versions 
> of these hashers remain.



It seems silly to remove the unsalted options and leave the salted options, 
they are basically equally [1] as secure since computational power is such that 
it is, that it’s not really worth it to use rainbow tables anymore anyways.

[1] Ok, Ok, technically salted are a wee bit more secure, but given that you 
can compute the MD5 of every single possible lower case alpha numeric of 6 
characters or less in under a minute on a single regular desktop/server.. I 
don’t believe the distinction is useful.

---------
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/123D52C5-FE34-4B70-9D1D-8B5B702A405A%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

[Donald Stufft]

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: 1.8 shipping invalid .py files in the startapp template

[Donald Stufft]

> On Nov 28, 2015, at 11:03 AM, Tim Graham <timogra...@gmail.com> 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: annoyance with Python 3.2 support in Django 1.8

[Donald Stufft]

> On Nov 26, 2015, at 9:50 AM, Tim Graham <timogra...@gmail.com> 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: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

[Donald Stufft]

> On Nov 17, 2015, at 12:00 PM, Tim Graham <timogra...@gmail.com> 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: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

[Donald Stufft]

> On Nov 17, 2015, at 3:03 PM, Aymeric Augustin 
> <aymeric.augus...@polytechnique.org> wrote:
> 
> On 17 nov. 2015, at 18:00, Tim Graham <timogra...@gmail.com 
> <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: Should contrib.auth include support for 2fa out of the box?

[Donald Stufft]

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: Static type checking for public API

[Donald Stufft]

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: Methodology for increasing the number of PBKDF2 iterations

[Donald Stufft]

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: Methodology for increasing the number of PBKDF2 iterations

[Donald Stufft]

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: Pre-DEP: community support of unmaintained versions of Django

[Donald Stufft]

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: Pre-DEP: community support of unmaintained versions of Django

[Donald Stufft]

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: Proposal: deprecate and remove egg template loader

[Donald Stufft]

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: Requiring GitHub login for actions on Trac

[Donald Stufft]

> I'm sorry. Please accept my apologies and let me rephrase that without
> spam-fighting-induced frustration:
> 
> "Other than reducing spam, Django as a project will benefit from this
> change be freeing core dev time and energy currently used to delete
> spam manually and tweak a feeble anti-spam plugin. Core dev time
> and energy are often cited as bottlenecks in the Django development
> process."
> 
> Other advantages have been put forward; I won't rehash them.


+1

It would also enable us to unify access controls too I think? I think we could
just pull permissions from GitHub?

---
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" 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/5A2D0897-B9FE-4043-A6DE-BB5D26507360%40stufft.io.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

[Donald Stufft]

On August 3, 2014 at 9:48:53 PM, Adam Brenecki (adambrene...@gmail.com) wrote:
> The patch I've written implements this mitigation, with one difference:
> instead of using xor, it uses a Vigenère cipher (as suggested by FunkyBob),
> as xor was creating non-printable characters which caused problems. I think
> this should be OK as Vigenère is commonly used for one-time pads and does
> more or less the same thing to characters that xor does to bits.
>  
> This is pretty much what django-debreach does, except that *it* uses AES
> instead of xor (i.e. the output is K + AES(K, S).). However, this adds
> processing load to every request and a dependency on PyCrypto, and as far
> as I can tell this doesn't actually add any benefit over xor/Vigenère.
>  
> So, in summary, I think I'm doing nearly exactly what the paper says, and I
> think it effectively makes the attack practically impossible, but I'd love
> to hear from someone who has a better idea than I as to if I'm actually
> correct on all of this.

Thoughts:

-1 on implementing our own Vigenère cipher.

If I understand the patch correctly it doesn't use the pad as a nonce exactly,
it will happily accept the same pad + CSRF token multiple times over and over.
Anything that treats the CSRF token as an opaque sequence of characters (which
is essentially what it is prior to this patch) should be backwards compatible
if my understanding is correct. Further more it looks like the original
unpadded CSRF token is still in the cookie so anything that pulls it's tokens
out of the cookie directly should be completely unaffected. 

Is my understanding correct? If so then the only thing I can imagine this
breaking is something that expected a certain length for the CSRF token and
afaik the length of the token is not within our backwards compatibility
promises.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.53dfe906.327b23c6.1280a%40Thor.local.
For more options, visit https://groups.google.com/d/optout.

Re: FR: Setting for CSRF Header (pull-request included)

[Donald Stufft]

On August 4, 2014 at 3:52:56 PM, Wes Alvaro (he...@wesalvaro.com) wrote:
> I don't see that as a drawback at all. Third party code should not be
> concerned with the CSRF cookie information. There's a separation of
> concerns that's being violated there. Are you speaking from knowledge of
> 3rd party code needing access to this data or hypothetically? If you have
> an example, I'd be interested to see why they are accessing it and why they
> aren't implemented as a CSRF middleware.
>  

Well any thing with hardcoded cookie names in javascript would break
with this setting although i’m inclined to say you shouldn’t change
the setting in that case.

--  
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" 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.53dfe589.6b8b4567.1280a%40Thor.local.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Donald Stufft]

On August 1, 2014 at 10:28:22 AM, Robert Grant (robertlagr...@gmail.com) wrote:
> Hi Tim
>  
> I did. I just reread it though; thanks for the link. There are multiple
> ways to do registration, agreed, but then one could - for example - make
> your same argument about logging into a system. Why provide that when some
> people might not want a site with authentication, or might want to do it
> through Facebook or OpenID? (Or, as per your reference to James' reasons,
> Persona?)
> 

I think the difference between django-registration and South is that
there is a benefit to blessing a singular migrations framework as
the one true way of doing it. Namely that is interoperability.

The same can be said for django.contrib.auth as well. As long as any
system which uses users ties into that, then they’ll all interopt
with each other. The same cannot be said for the registration system
since generally most pieces of a site do not interact with the
registration system, especially not at the level as they would for
the generic concept of users or database migrations.

--  
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" 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.53dc0fe4.6b8b4567.d5d9%40Thor.local.
For more options, visit https://groups.google.com/d/optout.

Re: use semantic versioning after 2.0?

[Donald Stufft]

Semver doesn’t require that a MAJOR increment be earth shattering, just that 
it’s used
to mark backwards incompat changes. Realstically dropping the 1. would make 
sense
for Django + Semver since every 1.x version is potentially backwards incompat 
since it
tends to remove something that was deprecated.

On Jul 14, 2014, at 2:59 PM, Collin Anderson <cmawebs...@gmail.com> wrote:

> > MAJOR version when you make incompatible API changes,MINOR version when you 
> > add functionality in a backwards-compatible manner
> 
> Although our changes are backwards compatible, they are only guaranteed to be 
> backwards compatible for the previous two versions. Instead, semver says that 
> code written for django 1.1 should run just fine on django 1.6.
> 
> > if it isn't earth-shattering, should be 1.10. Reasons to break things will 
> > pop up in due time (e.g. the death of python 2 in 2019). 
> 
> I'm also ok with django 1.10, though I also like incrementing the major 
> version regularly as a way of saying "we don't plan on making 
> earth-shattering changes". In retrospect, I think it would have been better 
> if python made the backwards-incompatible changes slowly, with warnings, over 
> the course of several releases instead of all at once. If we do ever make 
> earth-shattering changes, I think it would be smart to use a whole new module 
> and package name such as django2. That way you can easily have both installed 
> at the same time.
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5fab23be-1411-4813-bfbe-ef85d0025452%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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: DEPs: Django Enhancement Proposals

[Donald Stufft]

On Apr 14, 2014, at 1:51 PM, Adrian Holovaty <adr...@holovaty.com> wrote:

> Yesterday at PyCon, about a dozen people from the Django core team had a 
> lunch meeting to talk about various ideas we should implement. One idea was 
> to start doing a Django equivalent of Python's PEPs, which would serve as a 
> formal way to document large new features/changes in Django.
> 
> The goal would be to have "design documents" in a single place, rather than 
> relying on parsing dozens of micro-decisions made in mailing list threads, 
> Trac tickets, etc. And, importantly, we would only use this for 
> medium-to-large features, so as not to introduce too much inertia.
> 
> We also talked about doing it immediately, just using pull requests on 
> GitHub, to get some momentum going. No need to build any fancy systems, etc.
> 
> Today at the sprints, I went ahead and started drafting how this would work. 
> Here is a new GitHub repo for DEPs (Django Enhancement Proposals):
> 
> https://github.com/django/deps
> 
> And here is DEP 1, a draft attempt to document how the process works:
> 
> https://github.com/django/deps/blob/master/deps/0001.txt
> 
> Note the "TODO: Next steps" at the bottom. I'm not exactly sure what the best 
> process would be once a DEP is formally created. Can somebody with more 
> familiarity with Python's PEP process provide some suggestions?
> 
> Adrian
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CABm4ZCT1S1_ybYVe_0BGKvGAsQx3VDsD0KWZtBfR9fD6nOU7vQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Normally in the PEP process once you have a PEP you go through rounds of 
discussion on the mailing list. The PEP is responsible for documenting the 
solution the PEP suggests as well as any dissenting opinions. Once the PEP 
author believes there is no more discussion to be had they ask for 
pronouncement. This is where the BDFL or BDFL-Delegate (Guido doesn’t care 
about everything, so he can appoint someone to decide in his place) reads over 
the PEP and accepts it or rejects it. If it is accepted the status changes from 
Draft to Accepted and it stays that way until it gets implemented and 
committed. Then it changes from accepted to final and the PEP process is done.

One thing i’m not sure of, how is DEPs going to work without a BDFL? Generally 
they are used to get feedback and provide a clear concise argument to the BDFL 
in cases where there is not a good way to get a rough consensus amongst 
python-dev.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [GSoC] Switching to Jinja2 proposal

[Donald Stufft]

On Feb 16, 2014, at 4:23 PM, Carl Meyer <c...@oddbird.net> wrote:

> Hi Christopher,
> 
> On 02/15/2014 09:43 AM, Christopher Medrela wrote:
>> What I'm proposing now is more conservative proposal. Firstly, Django will
>> support Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
>> Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
>> include/inherit DTL template from Jinja2 one and vice versa).
>> 
>> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting
>> Django
>> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
>> Python code to Jinja2 templates.
> 
> This sounds reasonable to me.
> 
>> After that all, we could start again the war DTL vs Jinja2, but please focus
>> on the new proposal now.
>> 
>> Questions are:
>> 
>> 1) What do you think about the new proposal? Would it be useful?
> 
> Yes, as long as Jinja2 is a hard dependency, such that we can rely on
> its availability for internal Django use (form widgets).
> 
>> 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
> 
> Donald might be able to offer better hard numbers based on e.g. PyPI
> usage, but my impression is that usage of 3.2 is very low, and dropping
> it for 1.8 would not be a major problem.

These numbers are about a month old, but https://gist.github.com/dstufft/8455306

> 
>> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
>>   ready for this?
> 
> I think so, yes.
> 
> Carl
> 


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [GSoC] Switching to Jinja2 proposal

[Donald Stufft]

On Feb 15, 2014, at 11:43 AM, Christopher Medrela <chris.medr...@gmail.com> 
wrote:

> My last post was pretty long and the most important questions and statements
> have left unanswered, so I will repeat them.
> 
> What I'm proposing now is more conservative proposal. Firstly, Django will
> support Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
> Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
> include/inherit DTL template from Jinja2 one and vice versa).
> 
> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting Django
> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
> Python code to Jinja2 templates.
> 
> After that all, we could start again the war DTL vs Jinja2, but please focus
> on the new proposal now.
> 
> Questions are:
> 
> 1) What do you think about the new proposal? Would it be useful?
> 
> 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
> 
> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
>ready for this?

If we have Jinja2 I don’t see any reason to keep the DTL as the blessed option.

> 
> On Tuesday, February 11, 2014 2:07:19 PM UTC+1, Aymeric Augustin wrote:
> 2014-02-11 13:42 GMT+01:00 Christopher Medrela <chris@gmail.com>:
>  
> What did Armin said about Python 3 exactly?
> 
> He wrote an extensive argumentation about "why Python 2 [is] the better
> language for dealing with text and bytes" [1] as well as a number of tweets
> and a few other blog posts along the same lines.
> 
> While his arguments are technically correct, I disagree with his conclusions
> because he's speaking with the point of view of an expert maintaining
> libraries at the boundary between unicode and bytes (like werkzeug). However,
> most Python users aren't experts and aren't maintaining such libraries. In my
> experience working with Python programmers ranging from intern to veteran, the
> unicode model of Python 3 is a strict improvement over Python 2 in terms of
> pitfalls hit in day-to-day programming. YMMV.
> 
> [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
> 
> -- 
> Aymeric.
> 
> OK, so Armin finds Python 2 better than Python 3. But why is it at odds with
> Django? He didn't say that he is not going to support Python 3. So where is
> the risk that concerns you?
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/79dbbf71-6b70-48d1-8510-cef471812677%40googlegroups.com.
> 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: [GSoC] Switching to Jinja2 proposal

[Donald Stufft]

Crate had one, i’d have to pull it out but it was a pretty simple template. The 
sticking
point was it had a 30k item loop which was significantly faster in Jinja2.

On Feb 12, 2014, at 4:25 PM, Curtis Maloney <cur...@acommoncreative.com> wrote:

> At this point someone should start asking for real-world examples with 
> measurements.
> 
> I'm personally of the "let's see if we can improve DTL first, then revisit 
> the question" stance.
> 
> But in order to show any improvements, we must have timings for the current 
> tool.
> 
> Can people who've suffered slowness please donate fragments of template 
> they've found particularly slow?
> 
> 
> 
> On 12 February 2014 21:29, Gwildor Sok <gwildor...@gmail.com> wrote:
> There are a few problems with Christian's assumptions:
> 
> * Not everyone uses a JS Framework. Personally, we use a lot of static pages, 
> and when we do want to do some fancy stuff, we use pjax to replace content on 
> the page, but in the backend this is still done by rendering a full template 
> through a Django view.
> 
> We run a hybrid side, and fairly high traffic [7k req/min is a fairly 
> typical] and I've yet to find a major template performance issue that didn't 
> turn out to be a DB hit hiding in an object, or similar.
> 
> That's not to say I don't think it can be faster...
>  
> * The templating language is also used for small stuff, and the switch to 
> Jinja would enable using the templating language for even more stuff. The 
> biggest issue that comes to mind are template-based widgets.
> 
> Actually, django-sniplates and django-formulation both allow using another 
> template as a "bag of macros".  I'm also working on a "just macros" rework of 
> the idea.  formulation even has a "reuse" tag so you can define template 
> macros [using blocks] within your template.
>  
> Personally, I'm in favor of switching to Jinja. The speed bonus and the 
> ability to call functions with arguments are great features for me.
> 
> I guess it's time I finally write my "What should I pass in the Context" blog 
> post... to point out that your designers are [usually] not coders, and 
> shouldn't have to understand your data structures or schema.  Whilst in some 
> ways perhaps excessively, DTL does make you consider your data structures.
>  
> One downside I can think of is that Jinja does not escape variables by 
> default, which might become a XSS security issue.
> 
> That's quite a large downside!
>  
> --
> Curtis
> 
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAG_XiSBmOU%3D4orZnW13bw-ZLT_O416unynhtnQ9%3DhgPtL9Bbtw%40mail.gmail.com.
> 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: Using setuptools to make django-admin.py runnable on Windows (#21340)

[Donald Stufft]

On Dec 4, 2013, at 5:51 PM, Florian Apolloner <f.apollo...@gmail.com> wrote:

> On Wednesday, December 4, 2013 11:20:39 PM UTC+1, Donald Stufft wrote:
> entry points are kinda wonky with pip 1.4, pip 1.5 makes them sane. You would 
> not need a Windows specific Wheel with pip 1.5
> 
> Is there a test-pypi where I could upload Django packages to test this?

Yes, but it’s down right now :( 

> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/a0af4ac2-bff1-4b7f-af4a-31aa0dd9d120%40googlegroups.com.
> 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: Using setuptools to make django-admin.py runnable on Windows (#21340)

[Donald Stufft]

On Dec 4, 2013, at 4:31 PM, Florian Apolloner <f.apollo...@gmail.com> wrote:

> Oh, one last thing (a few actually):
> How does 'entry_points' work with wheels? 
> Do we need an extra wheel for windows just to get the wrappers right? 
> Can we generate a windows wheel from *nix, or do we need a windows box?
entry points are kinda wonky with pip 1.4, pip 1.5 makes them sane. You would 
not need a Windows specific Wheel with pip 1.5

> Cheers,
> Florian
> 
> 
> On Wednesday, December 4, 2013 10:24:09 PM UTC+1, Florian Apolloner wrote:
> 
> 
> On Wednesday, December 4, 2013 8:24:49 PM UTC+1, Remram wrote:
> December 4 12:43, Florian Apolloner
> To my understanding of 
> https://github.com/pypa/pip/blob/develop/pip/req.py#L633 pip will use 
> setuptools for installing -- so why do you need setuptools in Django itself?
> The point here is to use options that distutils doesn't offer, like 
> entry_points, if they are available.
> 
> Ah, I assumed that the workaround you mentioned would be setuptools just 
> wrapping everything in 'scripts' -- didn't know that you'll have to use 
> 'entry_points' then.
>  
> Also (refering to your first post), why is associating stuff with .py files a 
> bad idea?
> I personally have .py files associated with my text editor. Defaulting them 
> to the system-wide Python 2.7 might do the correct thing in some cases...
> 
> Oh, that makes sense I guess :) 
> 
> Associating .py files with Python is not enough -- only binaries are searched 
> for in the PATH when typing a path-less command name (.com, .exe, .bat and a 
> few others).
>  
> Okay, that's just horrible!
> 
> Which downsides does using 'entry_points' have for a *nix based system? I'd 
> rather not support disutils and setuptools; this just calls out for pain. My 
> last worry (probably needlessly) is that we might run into issues with one of 
> the hundred setuptools versions out there; all together there is distribute, 
> old setuptools, new setuptools and whatever distris like debian packaged 
> currently -- I don't think most users upgrade setuptools that often, so are 
> there any issues to be expected with stoneold setuptools? [Granted, that's 
> not really our problem, but if we know of some issues we could warn the users]
> 
> Cheers,
> Florian
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/f3195fb1-1505-41ce-b34a-0cf147f33e1f%40googlegroups.com.
> 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: Using setuptools to make django-admin.py runnable on Windows (#21340)

[Donald Stufft]

The recommended build tool at the moment is setuptools.

It's up to the individual project to decide if they think the install story for 
setutpools pre 3.4 is appropriate for them. This'll get better in general in 
the future with MSI installers for setuptools and pip



> On Nov 24, 2013, at 2:37 PM, Florian Apolloner  wrote:
> 
> Hi,
> 
> I am pretty much against setuptools and given that pip is somewhat becoming 
> the defacto-standard to install stuff; I'd ask Donald what can be done here 
> (cc'ed him). I don't think it's a good idea to fix this in Django since this 
> is imo a problem in Python itself.
> 
> Regards,
> Florian
> 
>> On Sunday, November 24, 2013 7:18:15 PM UTC+1, Remram wrote:
>> Hi developers, 
>> 
>> On Windows, running the django-admin.py tool is painful[1], because 
>> .py scripts are not "executable". You might be able to run it using 
>> the full path (if Python is the default handler for .py files, which 
>> it really shouldn't be). Most probably you'll need to copy it to your 
>> project directory and prefix it with "python " each time. 
>> 
>> setuptools has a neat workaround for scripts on Windows, which works 
>> great: it creates a wrapper binary that it puts on the PATH. I know 
>> from previous threads that Django chose to move away from setuptools 
>> and back to distutils, however it is easy to conditionally use this 
>> feature if setuptools are available. That way, Windows developers that 
>> have setuptools installed (which should be, like, all of them) will be 
>> able to run django-admin.py easily. 
>> 
>> I submitted a pull request on Github[2] a month ago, then opened a 
>> ticket[3] later on. Apart from an uncommented update from akaariai, I 
>> didn't get any feedback. 
>> 
>> I'd really like to see this small change accepted. It is fairly minor 
>> but would work towards restoring the portability that is a strength or 
>> Python. 
>> 
>> Thanks for your input/reviews/time, 
>> -- Remram 
>> 
>> [1] http://stackoverflow.com/q/19593404/711380 
>> [2] https://github.com/django/django/pull/1812 
>> [3] https://code.djangoproject.com/ticket/21340 
>> 
>> TL;DR: what happened to my patch? 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7AA51553-FDF5-4DD4-B083-FF13BA1451EE%40stufft.io.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BCrypt and PBKDF2 Password Hash Caching

[Donald Stufft]

Password hashing schemes are slow on purpose to prevent brute force.
Siphash wouldn't make sense because if you're switching for speed you
can just use any secure hash function.

crypt by default is much slower than PBKDF2 FWIW. You should tune the
work factor/iterations until it's fast enough that it doesn't negatively
impact your site but as slow as possible otherwise. The higher the work
factor/iterations the harder it is to brute force, but the more negative
impact each login has.

I would tune bcrypt or PBKDF2 down before I implemented this custom
scheme.

-- 
  Donald Stufft
  don...@stufft.io

On Tue, Nov 19, 2013, at 09:10 PM, Javier Guerra Giraldez wrote:
> On Tue, Nov 19, 2013 at 8:48 PM, Erik van Zijst
> <erik.van.zi...@gmail.com> wrote:
> > You make a good point.
> >
> > An obvious fix would seem to be to add the username to the cache key. This
> > way users cannot "use" another user's cache entry.
> 
> 
> right, that would fix it.  (i guess, i'm no security expert)
> 
> but still you get only SHA1-level strength, when the whole idea was to
> switch to stronger crypto.  if in your case SHA1 is enough, you can
> simply keep using it.  if it's not enough, then you shouldn't be using
> it.
> 
> of course, that's easy for me to say; i don't manage a big site like
> yours, so the switch to PBKDF2 doesn't cost me a cent.
> 
> i wonder if siphash is strong enough for paswords...
> 
> -- 
> Javier
> 
> -- 
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFkDaoSRRWFq6zNmYMtSOzPeTuoRQFN7ZbF72f5xeLda%3DQSG%3Dw%40mail.gmail.com.
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1384914021.7999.49670181.1381CCF1%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Performance Docs

[Donald Stufft]

On Sep 21, 2013, at 12:04 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:

> Hi all,
> 
> I didn't follow this PR as it was in progress, but I just sat down and read 
> them. I have to say I'm extremely saddened by 
> https://docs.djangoproject.com/en/dev/topics/performance/#alternative-software-implementations
>  . This seems like extremely bad advice to me.
> 
> In my work I've had the opportunity to do performance work across a huge 
> number of applications, and there is an amazing corrolation between people 
> who insist their application is strictly IO bound, and applications which I 
> find 30% wins in just by switching to PyPy.
> 
> PyPy is known to provide substantial performance gains on Django's template 
> engine 
> (http://speed.pypy.org/comparison/?exe=1%2BL%2Bdefault%2C2%2B472=3=1=true=none=normal+bars),
>  at the time of writing it's something like 10x.
> 
> Further, the claim that "Any gains are likely to be small, and compatibility 
> issues are common." is pure FUD, and unsubstantiated.
> 
> I'd strongly prefer we remove this from our docs, and if anything we should 
> be encouraging the opposite, people with performance issues should be 
> encouraged to consider things like PyPy, not hide from them.
> 
> 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
> GPG Key fingerprint: 125F 5C67 DFE9 4084
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.

I agree.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Default session data serializer doesn't support extended data types

[Donald Stufft]

On Sep 20, 2013, at 9:52 AM, Davide Rizzo <sor...@gmail.com> wrote:

> The examples you mentioned (forms, admin) were significant improvements 
> themselves, with big benefits to Django users. Switching the default session 
> serializer to JSONSerializer is providing no benefit to any user. It's 
> addressing a security problem (which is already documented) that only a few 
> users have (can you provide a big^H^H^H list of users who use signed cookies 
> but can't add a SESSION_SERIALIZER setting next to their 
> SESSION_COOKIE_HTTPONLY and SESSION_COOKIE_SECURE settings?).

This isn't exactly true. While it *is* true that the biggest risk to using 
pickle as the session serialization is if you're using the cookie storage 
engine, it is *not* true that it is the only place that it can be attacked. 
Particularly it can be used to daisy chain from a compromised database, 
memcache, redis, etc host (wherever you're storing your sessions) to exploiting 
the app server.

A basic tenant in securing systems is that you make each piece of the system 
responsible for it's own security and you don't have it depend on the security 
of another system. Moving away from pickle as the default serialization engine 
ensures this property for the storage of session data.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Idea about authentication

[Donald Stufft]

On Sep 15, 2013, at 2:59 PM, Florian Apolloner <f.apollo...@gmail.com> wrote:

> Hi Ram,
> 
> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
> Florian, I'm not sure that you read my message carefully enough. I'm not 
> proposing to reduce the time that PBKDF2  takes to hash.
> 
> By replacing the password with a hash before running it through PBKDF2 you 
> are reducing that time for every password longer than the hash… And given the 
> way PBKDF2 works you'll reduce it by quite a bit (note that all of this only 
> applies to passwords longer than the hash, so it's probably pretty 
> academical). Either way, we'd at least need a new hasher class since it would 
> be backwards incompatible. Independent of that we'd have to evaluate if 
> pre-hashing the password could make  PBKDF2 less secure (probably not to 
> likely, but who knows).

According to Thomas Porin in the context of bcrypt pre-hashing the password is 
fine (and we already do this in Django 1.6). I see no reason the same wouldn't 
hold true for PBKDF2.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Idea about authentication

[Donald Stufft]

We'd want to use SHA256 but that's an OK thing to do AFAIK. I wouldn't agree to 
it in a security patch because it breaks backwards compatibility in a much 
larger way than the patch we did does.

In fact we already do this with the bcrypt hasher in Django 1.6+ to solve a 
password truncation issue (Bcrypt truncates the input password before hashing 
it).

https://code.djangoproject.com/ticket/20138

http://security.stackexchange.com/questions/6623/pre-hash-password-before-applying-bcrypt-to-avoid-restricting-password-length


On Sep 15, 2013, at 5:45 AM, Ram Rachum <ram.rac...@gmail.com> wrote:

> Thanks Curtis!
> 
> I thought about my idea and realized it makes a brute-force attack easier, 
> and we'd have to make the hashing stronger to compensate... Making the 
> computation time longer for the real users logging in... So yeah, it won't 
> help.
> 
> But then I had another idea. So PBKDF2 takes a longer time to calculate for 
> longer passwords. Maybe the solution is to fix that? That would be more 
> elegant than limiting passwords to 4096 (because then dos attackers can still 
> attack using 4096-long passwords, and while not as slow as megabytes-long 
> password, it's still slow.)
> 
> What if instead of calculating the PBKDF2 hash of the password, we'll 
> calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking 
> passwords wouldn't depend on their length, and we wouldn't even have to place 
> a limit of 4096 characters on passwords-- An attacker could try a 1MB-long 
> password but it would slow us down the same amount as trying "123456" would. 
> 
> What do you think? 
> 
> On Sunday, September 15, 2013 12:25:32 PM UTC+3, Curtis Maloney wrote:
> Actually, you'd just speed up their attack, since most failed attempts would 
> be quicker than others.
> 
> If you look in the crypto utils, you'll see a "constant time compare" ... 
> this is a common thing in crypto circles to avoid leaking "how close" the 
> guess was by how quickly the mismatch was found.
> 
> This is a class of "side channel attach"... worth reading up on if you want 
> to get further into crypto: http://en.wikipedia.org/wiki/Side_channel_attack
> 
> --
> Curtis
> 
> 
> 
> On 15 September 2013 19:00, Ram Rachum <ram.r...@gmail.com> wrote:
> Hi guys,
> 
> I just saw the new release announcement and I had an idea.
> 
> What if, in addition to sorting the hard to compute hash for every password, 
> we will also store the sha 1 hash of the first 5 characters ofthe password's 
> sha1 hash? Wouldn't this allow us to quickly rule out 99% of passwords, 
> thereby defending against dos attacks, while atthe same time not letting an 
> attacker who obtained the hashes to get the passwords?
> 
> I'm not a security expert, just brainstorming.
> 
> Thanks,
> Ram.
> 
> --
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> 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.
> 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: Idiot makes mistake

[Donald Stufft]

On Aug 20, 2013, at 1:38 PM, "Daniele Procida" <dani...@vurt.org> wrote:

> I am so sorry, no sooner than I am entrusted with the commit bit I have 
> managed to push -f to django/django instead of my  own fork, and God knows 
> what kind of mess I have made.
> 
> I am covered in shame and swear never to use -f again.
> 
> So sorry, a million abject apologies.
> 
> Daniele
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.


If anyone made any commits in the last hour you should probably double check to 
make sure they are there. I'm pretty sure we got it restored but doesn't hurt 
to double check.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Deprecation a little harsh?

[Donald Stufft]

On Aug 13, 2013, at 11:34 AM, Michael Manfre <mman...@gmail.com> wrote:

> If there is interest in the community to backport security fixes to no longer 
> supported versions of Django, what is the likelihood that a core dev would 
> merge them in to the appropriate stable branch? This would not include 
> packaging an official release, but would provide a way for those stuck on 
> older versions a better way to help others who are similarly stuck. I realize 
> that it does require time to verify pull requests and "too much effort" is a 
> completely valid answer. 

Lack of CI is probably going to be one of the biggest blockers. Without CI it's 
up to the merging developers to run the tests on all the combinations of stuff 
we support which isn't the easiest or the quickest thing to setup and maintain.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: GZipMiddleWare documentation

[Donald Stufft]

On Aug 9, 2013, at 11:09 PM, Russell Keith-Magee <russ...@keith-magee.com> 
wrote:

> Historically, we haven't updated our documentation to point out bugs, but in 
> this case, given that there are ongoing security implications, I think it 
> might be worthwhile to draw attention to this.

I agree with documenting.

> 
> I also have a nagging feeling in the back of my head that there have been 
> questions raised about whether GZIPMiddleware should exist *at all* -- that 
> there's some niggling detail in the WSGI spec that says that GZip compression 
> should be applied at the web server level, not the WSGI level. Can anyone 
> confirm if I'm hallucinating on this point? And if I'm not, perhaps we should 
> just be deprecating GZipMiddlware?


This is an interesting question. You are right that the WSGI spec states that 
and historically I would have agreed with you. However in light of the recent 
BREACH vulnerability I have a sneaking suspicion that compression is going to 
move down the stack into the application layer. Unless a more generalized 
solution is created I believe that the ability to turn compression on and off 
at the application level is going to be important. The application knows what 
*kind* of data exists in a response body and wether or not it is safe to 
compress it. The web server does not (except by crude heuristics such as path).

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Security Advisory: BREACH and Django

[Donald Stufft]

On Aug 6, 2013, at 1:28 PM, mac...@framestart.com wrote:

> Am I correct that it is still safe to have compression enabled for static 
> files? Assuming you're not sending secrets inside CSS or JS files?
> 
> http://wiki.nginx.org/HttpGzipModule says that the gzip on directive can be 
> set in location.

Yes, any response which does not include secret data can be compressed.

---------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Security Advisory: BREACH and Django

[Donald Stufft]

On Aug 6, 2013, at 12:45 PM, Rob Yates <ryates...@gmail.com> wrote:

> This is a fascinating attack.  I scanned all of the information that I could 
> find and it wasn't clear how this could be used to breach CSRF protection.  
> Is there more detail somewhere on that specific attack vector?  


Essentially if you have a string "abcd" which represents your CSRF token in the 
body, compression will make it so that if you add the string "fghe" to the 
output the size of the response will be larger than if you added the string 
"abcd" to the output (because of compression). It's somewhat harder to attack 
than that because it also requires an "anchor". In terms of CSRF this likely 
requires an XSS as well (if your csrf token always has csrf_token=" in front of 
it you can use that as your anchor, but html escaping would escape it).

Anchoring is a lot simpler for other secrets which are displayed to the user, 
for instance if you're trying to steal a credit card number which appears on 
the site as "Credit Card: 1234", then "Credit Card: " could be your anchor, so 
you'd just need a way to influence the output of the page so that you can add 
"Credit Card: " to try various combinations until you find one that doesn't 
increase the size of the response.

> 
> -Rob
> 
> On Tuesday, August 6, 2013 10:42:01 AM UTC-4, Jacob Kaplan-Moss wrote:
> Hi folks --
> 
> At last week's Black Hat conference, researchers announced the BREACH attack 
> (http://breachattack.com/), a new attack on web apps that can recover data 
> even when secured with SSL connections. Given what we know so far, we believe 
> that BREACH may be used to compromise Django's CSRF protection. Thus, we're 
> issuing a security advisory so that our users can defend themselves.
> 
> You can read more details, including how the steps you can take to prevent 
> yourself against this attack, on our blog:
> 
> https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
> 
> We plan to take steps to address BREACH in Django itself, but in the meantime 
> we recommend that all users of Django understand this vulnerability and take 
> action if appropriate.
> 
> 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.
> 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: Security Advisory: BREACH and Django

[Donald Stufft]

On Aug 6, 2013, at 12:16 PM, Tom Scrace <t.scr...@gmail.com> wrote:

> On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss wrote:
> 
> We plan to take steps to address BREACH in Django itself, but in the meantime 
> we recommend that all users of Django understand this vulnerability and take 
> action if appropriate.
> 
> 
> Would randomizing the CSRF token on each request be the correct way to fix 
> this in Django?

This incurs the cost that every request to Django invalidates all existing CSRF 
tokens (meaning if you start filling out a form, and then open another form in 
a different tab the first form will send an error) OR requires you to store a 
separate CSRF token for each request and look up the submitted CSRF token in 
that set of stored tokens.

There are a few possible solutions each with their own drawbacks. Such as 
secret hiding or disabling compression only for pages that have CSRF (or other 
secret output).

> 
> 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.
> 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: Question about password salt and encryption

[Donald Stufft]

On Jun 15, 2013, at 5:24 PM, Luke Plant <l.plant...@cantab.net> wrote:

> On 15/06/13 14:17, Jon Dufresne wrote:
> 
>> I guess I need to decide which way to go. Either a custom password
>> hasher that uses a static salt, or use Django's existing password hasher
>> and not think about it.
> 
> There are two questions here:
> 
> 1) What should you do for your system?
> 
> 2) Should Django's security be improved by an additional salt that isn't
> stored in the database?
> 
> Regarding number 2, this is not likely to happen quickly, due to
> backwards compatibility issues, and the need to introduce a new setting
> etc. (That may help you to decide question 1).
> 
> It's definitely worth considering, of course. We would have to consider
> whether it is worth the work. For many installations, if an attacker has
> the database they are very likely to have the source code too. Of
> course, we should try to layer security so that it isn't all or nothing.
> But given the difficulties of changing things, we'd have to consider
> whether the increase in security, in a typical setup, would justify the
> change.
> 
> Regards,
> 
> Luke
> 
> -- 
> "Pessimism: Every dark cloud has a silver lining, but lightning
> kills hundreds of people each year trying to find it." (despair.com)
> 
> Luke Plant || http://lukeplant.me.uk/
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 

Backwards compatibility is easy. Just add a new hasher.

-
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

[Donald Stufft]

On Jun 8, 2013, at 12:48 PM, Hanne Moa <hanne@gmail.com> wrote:

> On 3 June 2013 18:09, <gavinw...@gmail.com> wrote:
> # `DecoratorMixin`
> 
> `DecoratorMixin` is a class factory that converts any view decorator into a 
> class-based view mixin. 
> 
> Using it is easy and intuitive:
> 
> LoginRequiredMixin = DecoratorMixin(login_required)
> 
> Now this, this feels pythonic. Bravo!  I'm so doing this in future 
> projects... (Though, class factories are spelled lowercase_with_underscores, 
> no? At least in Django. For instance formset_factory().)
> 
> I've had a look at various LoginRequiredMixins out there (everybody makes 
> their own it seems, including me). It is quite common that it doesn't cover 
> all the things that login_required covers (like supporting the new way of 
> doing users in 1.5) so in the case of  LoginRequiredMixin, I think the safest 
> solution is to include a mixin in core anyway.
> 
> 
> HM
> 
> -- 
> 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.
>  
>  

Part of the reasoning of my original Change to make decorators classes was that 
it enabled much easier customization of them. Currently you basically either 
hope there was an option for doing what you wanted, or you copy/paste the 
entire thing and modify it.

Using a class lets you override it.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Meta-Proposal: Write *above* quotations in mailing list replies

[Donald Stufft]

On Jun 4, 2013, at 1:14 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:

> If you're posting to this list by logging in to https://groups.google.com/ 
> rather than via email, I'd like to propose that you write your reply above 
> the quoted message to which you're replying. If you do this, the digest 
> emails that most subscribers get will be easily previewable from their email 
> client (e.g., iPhone's Mail app). The way it stands now, about half of the 
> messages that I can see (without clicking to the Google Groups website) are 
> just:
> 
> > So and So said:
> >> This that the other
> >> and the other
> 
> > So and So said:
> >> This that the other
> >> and the other
> 
> Thoughts?
> 
> -- 
> 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 trying to get anyone to change their posting habit is a futile effort.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

On May 21, 2013, at 12:11 PM, peter <peter.vo...@ff.com> wrote:

> +1 on pre_syncdb
> 
> On Tuesday, May 21, 2013 8:29:49 AM UTC-7, Shai Berger wrote:
> On Tuesday 21 May 2013, Donald Stufft wrote: 
> > I run migrations in test. How else will you know your db reflects reality 
> > :/ 
> > 
> 
> When you have a few hundred migrations, that's something you're willing to do 
> in your CI server, but not on your development machine. 
> 
> Shai. 
> 
> -- 
> 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.
>  
>  


So I just submitted a PR for the pre_syncdb signal: 
https://github.com/django/django/pull/1200

After I get an eye or two on it, assuming no one has any issues with it I'll 
merge it.

-
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: implement Postgres CLUSTER USING by default for MtM tables

[Donald Stufft]

On May 21, 2013, at 9:28 PM, bry...@obviously.com wrote:

> The tables created by django for MtM fields are unordered.  Loading all the 
> relationships may result in a number of I/O operations approaching the number 
> of relationships:
> 
> # select * from basetable;
>  id |basetable_id| mtm_id 
> ++--
>   6 |  3 |1
>   7 |  2 |2
>  15 |  1 |1
>  16 |  1 |2
>  18 |  3 |5
> 
> Postgres has a feature to 'defragment' such tables packing data that gets 
> accessed at the same time into the same disk blocks.  The number of I/O 
> operations can be as small as one:
> 
> # \pset pager off
> # cluster basetable using table_mem_id;
> # select * from basetable;
>  id |basetable_id| mtm_id 
> ++--
>  15 |  1 |1
>  16 |  1 |2
>   7 |  2 |2
>   6 |  3 |1
>  18 |  3 |5
> 
> On a large table this can put hundreds of MtM relationships sequentially on 
> disk.  This makes for less I/O operations and less cache space used.
> 
> 
> This feature is postgres specific.
> And it would involve django making a guess about the use pattern of the 
> relationship.  Either the forward or reverse is optimized.
> 
> -- 
> 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.
>  
>  



What do you mean by "clustering by default". CLUSTER is a one time operation. 
You use to to arrange the orders of the row in a table but after they have been 
arranged it has no long lasting affects past that.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Combine localflavor apps again

[Donald Stufft]

On May 21, 2013, at 8:51 AM, Jannis Leidel <lei...@gmail.com> wrote:

> Hi all,
> 
> I'd like propose to combine all the django-localflavor-* packages - that were 
> moved out of contrib a while ago - into a new "django-localflavor" package. 
> None of the current maintainers would lose the commit bit. I'm ready to do 
> the heavy lifting for that.
> 
> Ever since the localflavor apps were removed from contrib I've seen many 
> stale ones, lingering on Github, only collecting issues and pull requests, 
> without much guidance. We have been missing maintainers since the removal 
> from contrib, even if some of the core developers helped out every once in a 
> while. Recently we added a few more maintainers for each of those packages 
> since they asked for it, which is great. But frankly I think that's not 
> enough. Up until now only 7 of the 44 localflavor on github.com/django have 
> been re-released on PyPI as separate packages. In other words, we have a 
> success rate of handing over the maintainership of ~15%. I think that's 
> because there is a lot of maintenance friction for each package.
> 
> With the split in packages we also broke the maintenance of translations of 
> those localflavors, by removing those apps from the previously well 
> established workflow using Transifex and left it to the maintainers to find a 
> way. Especially for that kind of app a rather glaring mistake, IMO.
> 
> We also stopped being able to re-use code between localflavors, for example 
> cryptographic code about ID validation, which in my opinion is a security 
> liability that alone should be reason enough to have only one package.
> 
> There was also never a clear plan for releasing or deprecation of localflavor 
> packages, which is the opposite to what we've been doing in the past with our 
> release policy.
> 
> So what I propose to fix this is simple:
> 
> - combine the localflavor packages into one Python package again, call it 
> django-localflavor
> - give all the individual country maintainers also access to that package
> - have a central documentation, e.g. django-localflavor.readthedocs.org
> - update the Django docs to point to that package
> - ask the maintainers of the 7 already released packages to point to the 
> newly created django-localflavor
> 
> What do you think?
> 
> Jannis
> 
> -- 
> 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.
> 
> 


This sounds ok to me.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

I run migrations in test. How else will you know your db reflects reality :/

On May 20, 2013, at 10:58 AM, charettes <charett...@gmail.com> wrote:

> This makes me wonder if you're planing to introduce a `SOUTH_TEST_MIGRATE` 
> setting analog when moving migration handling to core.
> 
> I think most people with a huge south migration history will set this setting 
> to `False` to speedup testsuite execution and thus they couldn't be used for 
> database setup.
> 
> Maybe people should just lean toward rebasing their migrations instead?
> 
> Le lundi 20 mai 2013 03:20:32 UTC-4, Andrew Godwin a écrit :
>> 
>> Of course, the long-term solution for this is probably migrations. The 
>> post_syncdb signal already causes me problems - as there's no good 
>> definition for it with migrations around (you basically have to send it 
>> right at the end for every model you think you touched).
>> 
>> However, the patch Donald linked would be a lot easier to emulate, so I'm 
>> not that against it.
>> 
>> Andrew
>> 
>> 
>> On Sat, May 18, 2013 at 7:15 PM, Donald Stufft <don...@stufft.io> wrote:
>>> There's already a patch on the ticket tracker for a pre_syncdb signal, and 
>>> yesterday I started updating it and modifying it a bit as I needed this 
>>> signal.
>>> 
>>> https://github.com/dstufft/django/compare/pre-syncdb-signal
>>> 
>>> On May 18, 2013, at 1:06 PM, Karol Sikora <elekt...@gmail.com> wrote:
>>> 
>>>> I can try to implement approach with pre_syncdb signal tomorrow. I think 
>>>> that is quite enough solution before deeper diggling into new migrations 
>>>> framework.
>>>> 
>>>> Karol
>>>> 
>>>> 18 maj 2013 19:03, "Anssi Kääriäinen" <anssi.ka...@thl.fi> napisał(a):
>>>>> On 16 touko, 11:20, Danilo Bargen <gez...@gmail.com> wrote:
>>>>> > As a sidenote, there was a discussion about this on this mailing list a 
>>>>> > few
>>>>> > months ago:
>>>>> >
>>>>> > https://groups.google.com/forum/#!searchin/django-developers/16550/dj...
>>>>> 
>>>>> I think a pre_sync signal is best approach. The signal should be
>>>>> called either just after connecting to the (test) DB in syncdb
>>>>> command, or maybe just after existing tables have been introspected so
>>>>> that you know what tables are already there. Latter might be better as
>>>>> syncdb can be ran multiple times, and you only need to CREATE
>>>>> EXTENSION on initial sync. OTOH if you add one more model with
>>>>> JSONField it seems you would need to run another CREATE EXTENSION, or
>>>>> to investigate if some existing model has already ran CREATE
>>>>> EXTENSION. So, defensive coding (that is, CREATE EXTENSION IF NOT
>>>>> EXISTS) would be needed.
>>>>> 
>>>>> Another problem is that post_syncdb is called from flush command, too.
>>>>> This seems wrong. Could we just add post_flush signal and send that
>>>>> instead? Another option is to add a "for_flush" kwarg to the signal
>>>>> parameters, but it feels just so wrong to have post_syncdb signal with
>>>>> an argument that tells syncdb didn't happen after all. The reason for
>>>>> post_syncdb from flush is creation of ContentTypes and Permissions
>>>>> after truncation of those tables.
>>>>> 
>>>>> While the pre_syncdb signal approach has many shortcomings (how to
>>>>> include the output in sqlall?), I think it is enough to solve this
>>>>> problem for now. You can run CREATE EXTENSION IF NOT EXISTS and that
>>>>> seems already a big step forward. Also, distinguishing post_flush from
>>>>> post_syncdb seems like a good idea, but should be done in separate
>>>>> ticket.
>>>>> 
>>>>> Later on migrations framework could offer a much better solution to
>>>>> this. But pre_syncdb signal seems small enough to include already in
>>>>> 1.6. Maybe this could be done in the sprints?
>>>>> 
>>>>>  - Anssi
>>>>> 
>>>>> --
>>>>> 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

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

There's already a patch on the ticket tracker for a pre_syncdb signal, and 
yesterday I started updating it and modifying it a bit as I needed this signal.

https://github.com/dstufft/django/compare/pre-syncdb-signal

On May 18, 2013, at 1:06 PM, Karol Sikora <elektrr...@gmail.com> wrote:

> I can try to implement approach with pre_syncdb signal tomorrow. I think that 
> is quite enough solution before deeper diggling into new migrations framework.
> 
> Karol
> 
> 18 maj 2013 19:03, "Anssi Kääriäinen" <anssi.kaariai...@thl.fi> napisał(a):
> On 16 touko, 11:20, Danilo Bargen <gez...@gmail.com> wrote:
> > As a sidenote, there was a discussion about this on this mailing list a few
> > months ago:
> >
> > https://groups.google.com/forum/#!searchin/django-developers/16550/dj...
> 
> I think a pre_sync signal is best approach. The signal should be
> called either just after connecting to the (test) DB in syncdb
> command, or maybe just after existing tables have been introspected so
> that you know what tables are already there. Latter might be better as
> syncdb can be ran multiple times, and you only need to CREATE
> EXTENSION on initial sync. OTOH if you add one more model with
> JSONField it seems you would need to run another CREATE EXTENSION, or
> to investigate if some existing model has already ran CREATE
> EXTENSION. So, defensive coding (that is, CREATE EXTENSION IF NOT
> EXISTS) would be needed.
> 
> Another problem is that post_syncdb is called from flush command, too.
> This seems wrong. Could we just add post_flush signal and send that
> instead? Another option is to add a "for_flush" kwarg to the signal
> parameters, but it feels just so wrong to have post_syncdb signal with
> an argument that tells syncdb didn't happen after all. The reason for
> post_syncdb from flush is creation of ContentTypes and Permissions
> after truncation of those tables.
> 
> While the pre_syncdb signal approach has many shortcomings (how to
> include the output in sqlall?), I think it is enough to solve this
> problem for now. You can run CREATE EXTENSION IF NOT EXISTS and that
> seems already a big step forward. Also, distinguishing post_flush from
> post_syncdb seems like a good idea, but should be done in separate
> ticket.
> 
> Later on migrations framework could offer a much better solution to
> this. But pre_syncdb signal seems small enough to include already in
> 1.6. Maybe this could be done in the sprints?
> 
>  - Anssi
> 
> --
> 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: RFC: "universal" view decorators

[Donald Stufft]

> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 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: BCrypt + Python3

[Donald Stufft]

On May 18, 2013, at 5:15 AM, Aymeric Augustin 
<aymeric.augus...@polytechnique.org> 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: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

On May 15, 2013, at 9:01 PM, Jacob Kaplan-Moss <ja...@jacobian.org> 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: Ticket 13978: Allow inline js/css in forms.Media

[Donald Stufft]

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: Perception of attitude in tickets

[Donald Stufft]

On May 13, 2013, at 5:12 AM, Chris Wilson <ch...@aptivate.org> 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: BCrypt + Python3

[Donald Stufft]

On May 11, 2013, at 4:10 AM, Claude Paroz <cla...@2xlibre.net> 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

BCrypt + Python3

[Donald Stufft]

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: Perception of attitude in tickets

[Donald Stufft]

> 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: Recommending a Python 3-compatible MySQL connector

[Donald Stufft]

On May 10, 2013, at 11:49 AM, Luke Plant <l.plant...@cantab.net> wrote:

> On 10/05/13 14:12, Aymeric Augustin wrote:
>> Hi Mark,
>> 
>> On 10 mai 2013, at 10:16, Mark Hughes <m...@cyki.com> 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: test discovery

[Donald Stufft]

On May 8, 2013, at 5:00 PM, Carl Meyer <c...@oddbird.net> 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: Django 1.6 release timeline

[Donald Stufft]

On Apr 30, 2013, at 7:10 PM, Andrew Ingram <a...@andrewingram.net> wrote:

> On 30 Apr 2013, at 23:38, Shai Berger <s...@platonix.com> 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: Django 1.6 release timeline

[Donald Stufft]

On Apr 30, 2013, at 3:31 PM, Jacob Kaplan-Moss <ja...@jacobian.org> 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: Request method in urls.py

[Donald Stufft]

ter 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

Remove download_url from setup.py

[Donald Stufft]

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: Documenting lazy() and memoize()

[Donald Stufft]

On Mar 11, 2013, at 10:50 AM, Tom Evans <tevans...@googlemail.com> 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

Re: Proposal: deprecate and remove django.contrib.comments

[Donald Stufft]

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: Switch to database-level autocommit

[Donald Stufft]

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: use SQLAlchemy Core for query generation

[Donald Stufft]

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: Proposal: use SQLAlchemy Core for query generation

[Donald Stufft]

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

[Donald Stufft]

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: post-collectstatic signal

[Donald Stufft]

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: 1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note

[Donald Stufft]

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: Updating default errors in contrib.auth.forms.PasswordResetForm

[Donald Stufft]

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: How to test patch

[Donald Stufft]

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: The key of permissions model

[Donald Stufft]

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: #3011 - Custom User Models -- Call for final review

[Donald Stufft]

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: #3011 - Custom User Models -- Call for final review

[Donald Stufft]

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: Django 1.5 release plans

[Donald Stufft]

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: Improve Django markdown rendering.

[Donald Stufft]

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: Testing multidb with TEST_MIRROR

[Donald Stufft]

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: Backporting some Python 3 support features to 1.4.x?

[Donald Stufft]

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: Breaking out localflavor

[Donald Stufft]

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: Django's CVB - Roadmap?

[Donald Stufft]

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 <donald.stu...@gmail.com 
> (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 functions in Python are complet

Re: Django's CVB - Roadmap?

[Donald Stufft]

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?

[Donald Stufft]

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?

[Donald Stufft]

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 <donald.stu...@gmail.com 
> (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 <marc.tam...@gmail.com 
> > (mailto:marc.tam

Re: Django's CVB - Roadmap?

[Donald Stufft]

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 git guidelines

[Donald Stufft]

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 <donald.stu...@gmail.com 
> (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 <donald.stu...@gmail.com 
> > (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 
&

Re: Django git guidelines

[Donald Stufft]

On Friday, May 18, 2012 at 12:30 PM, Anssi Kääriäinen wrote:
> On May 18, 6:08 pm, Donald Stufft <donald.stu...@gmail.com 
> (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

[Donald Stufft]

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: Djangopeople.net status

[Donald Stufft]

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
> >  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: GitHub migration done!

[Donald Stufft]

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 Meyer 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: GitHub migration planning

[Donald Stufft]

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 <donald.stu...@gmail.com 
> (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 planning

[Donald Stufft]

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: auth.user refactor: the profile aproach

[Donald Stufft]

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" <tevans...@googlemail.com 
> > > > (mailto:tevans...@googlemail.com)> wrote:
> > > > > On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis <ianmle...@gmail.com 
> > > > > (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 co