Re: Should user passwords be more strict?

[schinckel]

Attached is a post that requires all passwords to be:

'correct horse battery staple'

:)

-- 
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/-/GBAQF7IoHhYJ.
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 test-runner annoyances

[mvr]

On Sep 14, 4:16 pm, Carl Meyer  wrote:
>
> I'm generally in favor of updating Django's test runner to be more
> consistent with what the rest of the Python testing world does. Being
> able to reference test files, suites, and tests by
> fully-qualified-dotted-path rather than magical-applabel-path would be a
> good start, IMO.

I'll cut a ticket and submit a patch.

> Another piece would be adding support for unittest2 test discovery, to
> lift the requirement that all tests have to live directly in tests.py or
> models.py. It's not that I think putting tests inside a tests package is
> a bad convention, but if you have a lot of tests it's unfortunate that
> you currently have to manually import all the suites into tests/__init__.py.

We kind of have a fix for this too, and although it is not in the test-
runner itself or the management command it easily could be.

It involves adding one line to tests/__init__.py and never touching it
again.. that line looks like this:

__all__ = import_test_classes(__file__, __name__)

The implementation, which leverages unittest2 test loading magic, is
detailed here: http://dpaste.com/615679/

(Not sure whether dpaste or code in messages is worse form, but the
formatting on my first email looked bad..)

Regarding Swicegood's remarks about app-refactor, Yes, the first part
of what motivates full dotpaths for us is duplicate app names.  Second
is stuff like being able to run tests locally that the build process
won't discover (ie things defined in tests/some_file.py but not
imported in tests/__init__.py).  Third is running a very specific test
to save time iterating during TDD.

I also have a stand-alone workaround (as in, works with django 1.3 out
of the box) so that "dad test " still loads all tests even with
duplicate app names.  I didn't intend to open that can of worms here
since I'm not sure it's of interest with the app refactor up-and-
coming.  If anyone IS interested let me know.. it does require
modifying the test runner itself and not just patching some little
helper.

-- 
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: CSRF protection and cookies

[Paul McMillan]

> The applications I have in mind (where the "subdomain can set cookies
> for other subdomains" could hurt) use django.contrib.auth and thus
> sessions as well. Thus, they already have to do a session lookup for the
> auth check, haven't they? Could that be reused for the CSRF check?

Yes. Unfortunately, the cookie model (and thus your browser) are not
really designed to protect you in this situation. We work around it as
best we can, but it's an uphill struggle.

Yes, it's very possible to tie CSRF to sessions, and the new signing
bits make that even better. Django doesn't currently support this
feature out of the box, and is unlikely to do so in 1.4. I've put some
thought into the design for this, but it's not something I want to
rush into, and it's not something that is easy to just tell someone
else how to do and let them go implement it. I don't have the time to
really turn this into a solid feature before we freeze 1.4.

In the meantime, if you use SSL on each of your subdomains, you get
strict checking of the Referer header for CSRF, which mitigates that
particular avenue of attack. Since you're using sessions and auth, you
should be using SSL, and so the protection is mostly free.

> Just so I am not missing a class of attacks here: how important is CSRF
> protection for non-session applications? I have always viewed CSRF
> chiefly as an attack where you try to fool somebody who is authenticated
> (and therefore has privileges in the system) to ask the system to
> do a bad thing by doing the cross-site POST.

Those are the worst sorts of CSRF. CSRF protection also helps prevent
spamming, and can discourage reflected DoS attacks. Additionally, CSRF
protection can help mitigate the effects of XSS in some cases.

> If you would like help with testing etc for this, I hope I can offer
> some time.

Thanks, I'll take you up on that when I do get a chance to start
drafting things.

I went ahead and created #16859 to help keep track of these issues.
https://code.djangoproject.com/ticket/16859

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: "universal" view decorators

[Łukasz Rekucki]

On 15 September 2011 23:27, Donald Stufft  wrote:
> Gonna add this in here as well as ticket #14512
> I think using decorators to modify the way a CBV behaves is the wrong way to
> go about it, my reasoning is:
> 1) Decorators on functions make sense, since the only way to modify a
> function is to wrap it, so decorators provide a shortcut to do so.
> 2) There's already a standard way to add functionality to a class that has
> existed for a long time, is well tested, and as a bonus is something that
> people new to python but not new to programming will understand immediately.
> 3) Decorating a class is different to how adding any other kind of
> functionality to a CBV is done.
> 4) Customizability. Currently your only options to change the way one of the
> current decorators work is to rewrite it, unless the original author of the
> decorator thought of your use case, thought it was valid, and added a
> flag/option for it.
>     - This can be alleviated by using Object based decorators instead of
> function based, but that becomes uglier too because then you end up having
> to first subclass the decorator, then decorate the class.
> 5) Conceptually all the decorator really is doing is mixing in one method
> anyways, it's just hiding this away and adding more code and complexity, and
> reducing customizability and readability for the sole purpose of being able
> to use an @ symbol.
> 6) Forwards compatibility. The function based generic views have been
> deprecated. While function based views will probably always be supported,
> personally I think CBV's are the way forward, and it makes sense to have
> them be first class citizens as regards to adding in things like requiring
> logins, with the function based views having the helper code.
> 7) Backwards compatibility. With a (much simpler) bit of wrapper code, the
> decorators can easily still be supported (login_required etc) and can
> internally use the classes and present the same interface as they used to.
> The major difference being, now they'll be able to subclass them and
> customize tiny bits of it as well.
>
> To just expand a little more in general on this
> @login_required
> class ProtectedView(TemplateView):
>     template_name = "secret.html"
> vs
> class ProtectedView(LoginRequired, TemplateView):
>     template_name = "secret.html"
> In the first, the "things" defining how this CBV behaves are in two
> locations, which makes it harder to read, additionally you end up with a
> function that wraps a function that wraps a function (to some degree of
> wrapping) to actually get all of this to work. Each layer of wrapping adds
> another layer of indirection, and adds another layer of confusion for
> someone attempting to read the code.
> I really dumbed down example would be https://gist.github.com/1220512 .
> Obviously that isn't working code, but it gives a general idea of what I
> mean. Obviously if that is the path that is chosen it will need to be
> cleaned up and made to actually work.
> Hopefully this email makes sense. I just hope that since CBV's are new we
> can use this as an opportunity to do things in a cleaner, consistent and
> more generic way instead of continuing the old way (that made sense for
> functions) for the sake of doing it the same way.
> tl;dr; Using Mixins to add in functionality to a CBV makes way more sense
> then using a decorator which is essentially going to be doing the same thing
> as a mixing would, it just makes finding what is going on harder, makes
> customizing the decorator harder and/or uglier, and goes against the way
> functionality is currently added to a CBV.
>
> On Thursday, September 15, 2011 at 4:44 PM, Jacob Kaplan-Moss wrote:
>
> Hi folks --
>
> I'd like to convert all the view decorators built into Django to be
> "universal" -- so they'll work to decorate *any* view, whether a
> function, method, or class. I believe I've figured out a technique for
> this, but I'd like some feedback on the approach before I dive in too
> deep.
>
> Right now view decorators (e.g. @login_required) only work on
> functions. If you want to use a decorator on a method then you need to
> "convert" the decorator using method_decorator(original_decorator).
> You can't use view decorators on class-based views at all. This means
> making a class-based view require login requires this awesomeness::
>
> class MyView(View):
> @method_decorator(login_required)
> def dispatch(self, *args, **kwargs):
> return super(MyView, self.dispatch(*args, **kwargs)
>
> This makes me sad. It's really counter-intuitive and relies on a
> recognizing that functions and methods are different to even know to
> look for method_decorator.
>
> #14512 proposes a adding another view-decorator-factory for decorating
> class-based views, which would turn the above into::
>
> @class_view_decorator(login_required)
> class MyView(View):
> ...
>
> This makes me less sad, but still sad. Factory functions. Ugh.
>
> I want 

Re: RFC: "universal" view decorators

[Łukasz Rekucki]

2011/9/16 Łukasz Rekucki :
> Hi,
>> I believe, however, I've figured out a different technique to make
>> this work: don't try to detect bound versus unbound methods, but
>> instead look for the HttpRequest object. It'll either be args[0] if
>> the view's a function, or args[1] if the view's a method. This
>> technique won't work for any old decorator, but it *will* work (I
>> think) for any decorator *designed to be applied only to views*.
>
> +1 on this. I would be a bit concerned about this vs. future
> implementation of generator-based-views that allow some kind of
> response streaming (is someone working on that?).

Omit this part, It's late and I read HttpResponse by mistake ;), which
of course doesn't make any sense.

-- 
Ł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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: "universal" view decorators

[Łukasz Rekucki]

Hi,

On 15 September 2011 22:44, Jacob Kaplan-Moss  wrote:
>
> #14512 proposes a adding another view-decorator-factory for decorating
> class-based views, which would turn the above into::
>
>    @class_view_decorator(login_required)
>    class MyView(View):
>        ...
>
> This makes me less sad, but still sad. Factory functions. Ugh.

As the ticket creator I feel obligated to reply :)

Thinking about it now, it does look kinda ugly. It's mainly because I
was focus on how to reuse existing decorators in CBV context. It
shouldn't be to hard  to make the "view_decorator" a meta-decorator
(or a factory function as you call it) that turns login_required to
something that is both a class and function decorator. Methods are
still out-of-bounds for non-runtime introspection, but after almost 1
year of using CBV, I never needed to decorate a method.

I would like to also comment on the new approach in that ticket.
Making a shallow copy of a class is *MAGIC* to me. It breaks the basic
invariant "issubsclass(decorator(A), A) == True". This is important if
you're planing to use this as "B = decorator()(A)" (and you are,
'cause the whole point of not modifying the original class is to allow
safely doing this), as you quickly end up with weird alternate
hierarchies. So, please don't do that :)

>
> I believe, however, I've figured out a different technique to make
> this work: don't try to detect bound versus unbound methods, but
> instead look for the HttpRequest object. It'll either be args[0] if
> the view's a function, or args[1] if the view's a method. This
> technique won't work for any old decorator, but it *will* work (I
> think) for any decorator *designed to be applied only to views*.

+1 on this. I would be a bit concerned about this vs. future
implementation of generator-based-views that allow some kind of
response streaming (is someone working on that?).

>
> I've written a proof-of-concept patch to @login_required (well,
> @user_passes_test, actually):
>
>    https://gist.github.com/1220375
>

Did I already mention creating a subclass in the class decorator
breaks super ;) [https://gist.github.com/643536]


> Can I get some thoughts on this technique and some feedback on whether
> it's OK to apply to every decorator built into Django?
>

It would be great to have that meta-decorator, so everyone else could
upgrade their decorators just by decorating them.

-- 
Ł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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: "universal" view decorators

[Donald Stufft]

Gonna add this in here as well as ticket #14512

I think using decorators to modify the way a CBV behaves is the wrong way to go 
about it, my reasoning is:

1) Decorators on functions make sense, since the only way to modify a function 
is to wrap it, so decorators provide a shortcut to do so.

2) There's already a standard way to add functionality to a class that has 
existed for a long time, is well tested, and as a bonus is something that 
people new to python but not new to programming will understand immediately.

3) Decorating a class is different to how adding any other kind of 
functionality to a CBV is done.

4) Customizability. Currently your only options to change the way one of the 
current decorators work is to rewrite it, unless the original author of the 
decorator thought of your use case, thought it was valid, and added a 
flag/option for it.
 - This can be alleviated by using Object based decorators instead of function 
based, but that becomes uglier too because then you end up having to first 
subclass the decorator, then decorate the class.

5) Conceptually all the decorator really is doing is mixing in one method 
anyways, it's just hiding this away and adding more code and complexity, and 
reducing customizability and readability for the sole purpose of being able to 
use an @ symbol.

6) Forwards compatibility. The function based generic views have been 
deprecated. While function based views will probably always be supported, 
personally I think CBV's are the way forward, and it makes sense to have them 
be first class citizens as regards to adding in things like requiring logins, 
with the function based views having the helper code.

7) Backwards compatibility. With a (much simpler) bit of wrapper code, the 
decorators can easily still be supported (login_required etc) and can 
internally use the classes and present the same interface as they used to. The 
major difference being, now they'll be able to subclass them and customize tiny 
bits of it as well.


To just expand a little more in general on this

@login_required
class ProtectedView(TemplateView):
 template_name = "secret.html"

vs

class ProtectedView(LoginRequired, TemplateView):
 template_name = "secret.html"

In the first, the "things" defining how this CBV behaves are in two locations, 
which makes it harder to read, additionally you end up with a function that 
wraps a function that wraps a function (to some degree of wrapping) to actually 
get all of this to work. Each layer of wrapping adds another layer of 
indirection, and adds another layer of confusion for someone attempting to read 
the code.

I really dumbed down example would be https://gist.github.com/1220512 . 
Obviously that isn't working code, but it gives a general idea of what I mean. 
Obviously if that is the path that is chosen it will need to be cleaned up and 
made to actually work.

Hopefully this email makes sense. I just hope that since CBV's are new we can 
use this as an opportunity to do things in a cleaner, consistent and more 
generic way instead of continuing the old way (that made sense for functions) 
for the sake of doing it the same way.

tl;dr; Using Mixins to add in functionality to a CBV makes way more sense then 
using a decorator which is essentially going to be doing the same thing as a 
mixing would, it just makes finding what is going on harder, makes customizing 
the decorator harder and/or uglier, and goes against the way functionality is 
currently added to a CBV. 


On Thursday, September 15, 2011 at 4:44 PM, Jacob Kaplan-Moss wrote:

> Hi folks --
> 
> I'd like to convert all the view decorators built into Django to be
> "universal" -- so they'll work to decorate *any* view, whether a
> function, method, or class. I believe I've figured out a technique for
> this, but I'd like some feedback on the approach before I dive in too
> deep.
> 
> Right now view decorators (e.g. @login_required) only work on
> functions. If you want to use a decorator on a method then you need to
> "convert" the decorator using method_decorator(original_decorator).
> You can't use view decorators on class-based views at all. This means
> making a class-based view require login requires this awesomeness::
> 
>  class MyView(View):
>  @method_decorator(login_required)
>  def dispatch(self, *args, **kwargs):
>  return super(MyView, self.dispatch(*args, **kwargs)
> 
> This makes me sad. It's really counter-intuitive and relies on a
> recognizing that functions and methods are different to even know to
> look for method_decorator.
> 
> #14512 proposes a adding another view-decorator-factory for decorating
> class-based views, which would turn the above into::
> 
>  @class_view_decorator(login_required)
>  class MyView(View):
>  ...
> 
> This makes me less sad, but still sad. Factory functions. Ugh.
> 
> I want @login_required to work for anything::
> 
>  @login_required
>  class MyView(View):
>  ...
> 
>  class Something(object):
>  @login_required
> 

RFC: "universal" view decorators

[Jacob Kaplan-Moss]

Hi folks --

I'd like to convert all the view decorators built into Django to be
"universal" -- so they'll work to decorate *any* view, whether a
function, method, or class. I believe I've figured out a technique for
this, but I'd like some feedback on the approach before I dive in too
deep.

Right now view decorators (e.g. @login_required) only work on
functions. If you want to use a decorator on a method then you need to
"convert" the decorator using method_decorator(original_decorator).
You can't use view decorators on class-based views at all. This means
making a class-based view require login requires this awesomeness::

class MyView(View):
@method_decorator(login_required)
def dispatch(self, *args, **kwargs):
return super(MyView, self.dispatch(*args, **kwargs)

This makes me sad. It's really counter-intuitive and relies on a
recognizing that functions and methods are different to even know to
look for method_decorator.

#14512 proposes a adding another view-decorator-factory for decorating
class-based views, which would turn the above into::

@class_view_decorator(login_required)
class MyView(View):
...

This makes me less sad, but still sad. Factory functions. Ugh.

I want @login_required to work for anything::

@login_required
class MyView(View):
...

class Something(object):
@login_required
def my_view(self, request):
...

@login_required
def my_view(request):
...


Now, back in the day we somewhat had this: decorators tried to work
with both functions and methods. The technique turned out not to work
(see #12804) and was removed in [12399]. See
http://groups.google.com/group/django-developers/browse_thread/thread/3024b14a47f5404d
for the discussion.

I believe, however, I've figured out a different technique to make
this work: don't try to detect bound versus unbound methods, but
instead look for the HttpRequest object. It'll either be args[0] if
the view's a function, or args[1] if the view's a method. This
technique won't work for any old decorator, but it *will* work (I
think) for any decorator *designed to be applied only to views*.

I've written a proof-of-concept patch to @login_required (well,
@user_passes_test, actually):

https://gist.github.com/1220375

The test suite passes with this, with one exception:
https://code.djangoproject.com/browser/django/trunk/tests/regressiontests/decorators/tests.py#L87.
I maintain that this test is broken and should be using RequestFactory
instead.

Can I get some thoughts on this technique and some feedback on whether
it's OK to apply to every decorator built into Django?

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Should I split ticket #16502 in three tickets or not?

[Aymeric Augustin]

Hello,

Yes, I think ticket #16502 should focus on the problem of CreateView: why 
doesn't it have a default template and does it need one?

The other issues you discovered while investigating that problem should go into 
separate tickets.

Best regards,

-- 
Aymeric Augustin.

On 15 sept. 2011, at 09:12, Silver_Ghost wrote:

> There is a comment to ticket ticket #16502 from ptone.  He recommends to 
> create two new tickets, one for get_model patch and one for select_template 
> patch.  In my opinion separating select_template patch is a good idea while 
> separating get_model patch isn't.  This is because adding get_model method 
> fully fixes ticket #16502.
> 
> What should I do?  If creating two new tickets as ptone suggests is a right 
> way then how to show relation between this three tickets?
> 
> -- 
> 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/-/zQT8_CaxmyUJ.
> 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.

-- 
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: CSRF protection and cookies

[Kent Engström]

Paul, thanks for your reply! Comments inline:

Paul McMillan  writes:
>> Would it not be possible to move the second instance of the nonce (that
>> will be compared to the form field) from a cookie to a session variable
>> (at least when a session is available)?  Would that result in other
>> problems instead?
>
> Yes it's possible, and that's how our CSRF protection worked at first.
> However, it has the disadvantage of being tied to sessions, and so our
> last revision of the framework specifically decoupled the two.

> One reason you may not want it tied to sessions is if you have a
> public comment form on an unencrypted page, but also want to have
> SESSION_COOKIE_SECURE, so sessions are never sent unencrypted. Another
> is that the extra session lookup for every form submitted may be a
> performance problem, depending on how you store your sessions and what
> your traffic profile looks like. Another reason is that you may not be
> using the sessions framework at all, and still want forms with CSRF
> protection.

The applications I have in mind (where the "subdomain can set cookies
for other subdomains" could hurt) use django.contrib.auth and thus
sessions as well. Thus, they already have to do a session lookup for the
auth check, haven't they? Could that be reused for the CSRF check?

I think it would be OK to have to specify something like a
SessionBasedCsrfMiddleware instead of the normal CsrfMiddleware, if the
choice between "session" and "cookie" cannot be made dynamically by the
framework.

Just so I am not missing a class of attacks here: how important is CSRF
protection for non-session applications? I have always viewed CSRF
chiefly as an attack where you try to fool somebody who is authenticated
(and therefore has privileges in the system) to ask the system to
do a bad thing by doing the cross-site POST.

> Improving the CSRF in this fashion is on my list of things to do, but
> it's a bit of a tricky problem, and so it hasn't happened yet. We can
> do better than we do now, but not without somewhat changing the
> properties of the system.

If you would like help with testing etc for this, I hope I can offer
some time. 

BTW, should I submit a ticket about this to the Django ticket database
or is there a more general ticket that already covers this?

/ Kent Engström

-- 
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: Python 3 and you

[Waylan Limberg]

I'm not going to rehash everything Vernon says below, but I will say
that as someone who maintains a module which installs and runs on
Python 2.4 - 3.2, Vernon's comments are spot on.

We first started supporting Python 3.0 almost immediately after its
release and we had a few misconceptions going in - some of the same
misconceptions I'm seeing here by people who have not done this yet.
But after working with it for a while now, those misconceptions are
gone (for me). You really do maintain one codebase to run in the
lowest version of python you support (with forward thinking code) and
have setup.py automagically run 2to3 when installing on Python 3+.
That is the only workable solution.

I realize there are various articles/tutorials out there which talk
about how to write code which runs on both 2.x and 3.x without
conversion. While it is possible, it is a bear to maintain and IMO
should only apply to the setup.py file itself (this means you need to
test setup.py in 2.x & 3.x every time you make a change to it - not
something we're used to testing regularly). The exception may be a
small one file module, which Django certainly is not.

On Thu, Sep 15, 2011 at 5:42 AM, VernonCole  wrote:
>
>> One assumption of the strategy I outlined was the fact that Django is
>> as close to 3.X as possible. Django 1.4 will require Python 2.5 or
>> higher, but I'm not sure how quick we can do the jump to 2.6, which
>> is recommended by the Python porting docs [1].
>>
> Don't confuse "recommended" with "necessary."  I maintain a module
> which installs and runs very nicely on any version of Python >= 2.3.
> The automatic operation of 2to3 during the install is like magic.  It
> really works very well.
>
>> >   Finally, a philosophical question on approach: Should we really be
>> > doing 2to3 (leaving the Django codebase in Python 2.X for a long time)
>
> Yes, that's exactly what you do -- just like you code everything in
> Python 2.4 until everyone is ready (or able) to jump to 2.5.  You
> simply avoid using new language features until that point.  If
> fortunate people have a later version, then they can use new language
> features in their code, just us module authors cannot use them.  But
> we plan for them.  For example, we add __enter__() and __exit__()
> methods to objects where that makes sense.  If the programmer is using
> an older compiler, then they will never get called, but they will be
> present when someone with a new compiler uses a "with" statement.  We
> cannot use "with" in module code, though, until all python 2.4 users
> have disappeared.
>
> Same thing when moving to Python 3.x -- you cannot use any new
> features, but you have to refactor your old code in such a way that
> 2to3 can do the right thing when it installs.  Mostly this means
> cleaning up old code which was probably due for a maintenance pass
> anyway.  Get rid of string exceptions.  Make all class definitions
> into new style classes.  Things like that.
>
>> > or would it be better to port Django over to Python 3 & use 3to2 for
>> > existing Python 2.X installs? I confess I don't know much about the
>> > current state of 3to2 (nor how most other Python libraries are
>> > handling the transition). But I do know Django will continue to grow
>> > over time & I worry that, at some point in the future we'll be making
>> > more even more work for someone else to do the 3-only work.
>
> N!   There is no 3-only work until the last 2.7.n user upgrades.
> When that glorious day happens, we will make an archive copy of the
> old version, and then run 2to3 for the last time.  After that, code
> would be maintained in the oldest supported 3.x version.
>>
>> I personally haven't ported a 2.X library completely to 3.X yet, so I
>> can also only guess. But from what I've seen in the community I'm afraid
>> of a "clean cut" port because it has a high risk of leaving many projects
>> and apps behind. In that sense it seems more sensible to me to see the
>> port to Python 3 just as another step of our Python version deprecation
>> policy, which we at some point take with a complete conversion. Basically
>> a "burn bridges as soon as everyone is safe" approach :)
>
> Yes, that is exactly correct -- and I HAVE ported a 2.x library. I'm
> guessing that the jump will be from 2.7 to  about 3.3.    No sense
> supporting obsolete 3.x versions..
>>
>> I don't dare to guess when that moment could be though, but it would probably
>> happen after a potential Python 2.7 only release of Django -- whenever that 
>> is.
>>
> Years  lots of years, before 2.7 disappears.  Hopefully, by then,
> others will have been running 3.x versions for years, and will have
> long since worked out the kinks.
> --
> Vernon
>
> --
> 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 

Re: django test-runner annoyances

[Filip Dupanović]

Like Carl and Travis said, Django's test runner supports the notion that a 
Django app has all it's test cases collected in the `models` and `tests` 
module.

Most of the time, If your app's `tests` module gets too crowded, fracturing 
the app into smaller apps works. However, if you have to go for the test 
package approach to maintain sanity, your missing the necessary tools to 
manage a growing number of test cases; for instance, if you organize your 
test cases into several modules, there's really no way you can run test 
cases from a specific module only, without providing a custom test runner or 
somehow passing arguments to a `suite()` implementation.

-- 
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/-/76JePQ022ZEJ.
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.

Should I split ticket #16502 in three tickets or not?

[Silver_Ghost]

There is a comment to 
ticket ticket 
#16502  from *ptone*.  He 
recommends to create two new tickets, one for get_model patch and one for 
select_template patch.  In my opinion separating select_template patch is a 
good idea while separating get_model patch isn't.  This is because adding 
get_model method fully fixes ticket #16502.

What should I do?  If creating two new tickets as *ptone* suggests is a 
right way then how to show relation between this three tickets?

-- 
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/-/zQT8_CaxmyUJ.
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: Python 3 and you

[VernonCole]

> One assumption of the strategy I outlined was the fact that Django is
> as close to 3.X as possible. Django 1.4 will require Python 2.5 or
> higher, but I'm not sure how quick we can do the jump to 2.6, which
> is recommended by the Python porting docs [1].
>
Don't confuse "recommended" with "necessary."  I maintain a module
which installs and runs very nicely on any version of Python >= 2.3.
The automatic operation of 2to3 during the install is like magic.  It
really works very well.

> >   Finally, a philosophical question on approach: Should we really be
> > doing 2to3 (leaving the Django codebase in Python 2.X for a long time)

Yes, that's exactly what you do -- just like you code everything in
Python 2.4 until everyone is ready (or able) to jump to 2.5.  You
simply avoid using new language features until that point.  If
fortunate people have a later version, then they can use new language
features in their code, just us module authors cannot use them.  But
we plan for them.  For example, we add __enter__() and __exit__()
methods to objects where that makes sense.  If the programmer is using
an older compiler, then they will never get called, but they will be
present when someone with a new compiler uses a "with" statement.  We
cannot use "with" in module code, though, until all python 2.4 users
have disappeared.

Same thing when moving to Python 3.x -- you cannot use any new
features, but you have to refactor your old code in such a way that
2to3 can do the right thing when it installs.  Mostly this means
cleaning up old code which was probably due for a maintenance pass
anyway.  Get rid of string exceptions.  Make all class definitions
into new style classes.  Things like that.

> > or would it be better to port Django over to Python 3 & use 3to2 for
> > existing Python 2.X installs? I confess I don't know much about the
> > current state of 3to2 (nor how most other Python libraries are
> > handling the transition). But I do know Django will continue to grow
> > over time & I worry that, at some point in the future we'll be making
> > more even more work for someone else to do the 3-only work.

N!   There is no 3-only work until the last 2.7.n user upgrades.
When that glorious day happens, we will make an archive copy of the
old version, and then run 2to3 for the last time.  After that, code
would be maintained in the oldest supported 3.x version.
>
> I personally haven't ported a 2.X library completely to 3.X yet, so I
> can also only guess. But from what I've seen in the community I'm afraid
> of a "clean cut" port because it has a high risk of leaving many projects
> and apps behind. In that sense it seems more sensible to me to see the
> port to Python 3 just as another step of our Python version deprecation
> policy, which we at some point take with a complete conversion. Basically
> a "burn bridges as soon as everyone is safe" approach :)

Yes, that is exactly correct -- and I HAVE ported a 2.x library. I'm
guessing that the jump will be from 2.7 to  about 3.3.No sense
supporting obsolete 3.x versions..
>
> I don't dare to guess when that moment could be though, but it would probably
> happen after a potential Python 2.7 only release of Django -- whenever that 
> is.
>
Years  lots of years, before 2.7 disappears.  Hopefully, by then,
others will have been running 3.x versions for years, and will have
long since worked out the kinks.
--
Vernon

-- 
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: class based views: object instead of dictionary as context?

[Roald de Vries]

On Sep 13, 2011, at 9:28 PM, Reinout van Rees wrote:


On 13-09-11 20:33, Tobias McNulty wrote:

   I love it when problems solve themselves :-)


That's a good point.  Are there *any* methods in the CBVs that don't
take arguments, that also modify data?  The only one that I found  
in the

list I'd initially proposed that can be called without arguments is
as_view(), and I'm not sure that really even needs protection.  Maybe
there's no need to protect anything with alters_data / proxying?


There's not really anything useful you can do with as_view in your  
template, should you attempt it. I also don't think you can do  
anything destructive with it.


as_view() is a classonlymethod, which gives an AttributeError when  
called on an instance, so putting an instance of the cbv in the  
context seems fine for as far as this is concerned.


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