Re: Should user passwords be more strict?
All you need to know about implementing your own policy: http://xkcd.com/936/ On Sep 14, 1:17 pm, Paul McMillanwrote: > I'm happy you're concerned about this, but suggest you search the > archives for similar material so that new threads can contribute new > content. > > This search is probably a fantastic starting point for your reading > pleasure:http://groups.google.com/group/django-developers/search?group=django-... > > Regards, > -Paul > > > > > > > > On Tue, Sep 13, 2011 at 3:52 PM, Wim Feijen wrote: > > Having just finished a discussion on security, I'd like to raise a > > concern of mine. > > > By default, users can have a one-character password. > > > When their accounts get hacked, we suffer the consequences as well. > > > Should we be more strict in that? > > > Wim > > > -- > > 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 > > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, 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
Hello; I second all of what Carl said and would like to point out the app-refactor. I believe the most current code still lives in the app-loading branch on jezdez's repository on GitHub[1]. The reason I point this out is because the current testing structure is a legacy of the way Django internally finds out what "apps" are tested. I've gone down this rabbit hole before and the solution I ended up with was modifying the way loading apps worked which has all manner of side-effects. One of the first steps down that path is the app-loading branch which makes referring to an app by it's full name possible. -T [1]: https://github.com/jezdez/django/tree/app-loading On Wed, Sep 14, 2011 at 3:16 PM, Carl Meyerwrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/13/2011 08:46 AM, mvr wrote: > > Why doesn't the django test management command / test builder allow > > fully-qualified package names instead of just app-relative ones? > > > > At work we've been using the method below to monkey-patch the test > > builder, so that > > > > $ django-admin.py test my_module.my_app.tests.some_test_file > > > > always works as expected. We'd like to get rid of this monkey-patch, > > and since this functionality can be added in such a way that it's > > completely backwards compatible, where is the harm? I'm also willing > > to submit a diff that modifies django in-place, but the monkey patch > > below should be easy to read and first I wanted to hear if anyone has > > any thoughts on why the existing behaviour really is exactly what it > > should be. > > 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. > > 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. > > But I'm getting off-track -- these should be separate tickets anyway. If > you'd like to file the first one and upload a backwards-compatible > patch, I'm +1 on the concept. > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk5xC54ACgkQ8W4rlRKtE2eNFgCg7gVEkO6Y+tmXcsWlidmh67ge > SQwAn0PqFg74dy1yLsSPDYab1Jj+jNZ+ > =bAbE > -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/13/2011 08:46 AM, mvr wrote: > Why doesn't the django test management command / test builder allow > fully-qualified package names instead of just app-relative ones? > > At work we've been using the method below to monkey-patch the test > builder, so that > > $ django-admin.py test my_module.my_app.tests.some_test_file > > always works as expected. We'd like to get rid of this monkey-patch, > and since this functionality can be added in such a way that it's > completely backwards compatible, where is the harm? I'm also willing > to submit a diff that modifies django in-place, but the monkey patch > below should be easy to read and first I wanted to hear if anyone has > any thoughts on why the existing behaviour really is exactly what it > should be. 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. 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. But I'm getting off-track -- these should be separate tickets anyway. If you'd like to file the first one and upload a backwards-compatible patch, I'm +1 on the concept. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5xC54ACgkQ8W4rlRKtE2eNFgCg7gVEkO6Y+tmXcsWlidmh67ge SQwAn0PqFg74dy1yLsSPDYab1Jj+jNZ+ =bAbE -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. 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
> 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. 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. -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: Python 3 and you
On Wed, Sep 14, 2011 at 8:42 PM, Jannis Leidelwrote: > > > Anybody knows somebody who started a django/py3 port already? We should > unify our efforts. > > As I said earlier in this thread, there is now a Python 3 branch in the > Django SVN. > Thank you! Really good to see that. > > > If core team doesn't like the py3 idea, we should start with a patch > which follows always the latest devel version. I strongly anticipate a > project fork (see what happened with the plone & blue bream). > > The core team likes the idea, there is no fork required. > Thank you! Really good to see that. > > > 2to3 (3to2), etc are good start for an initial port, but I think they > aren't enough to do this on day-to-day base. Their conversion algo isn't > enough, some handwork is needed. > > Could you be a bit more specific about what the algorithm can't do? From > what I saw in Martin von Löwis' patch (which is now in the Python 3 branch) > we haven't hit any problem with 2to3. That said, it's of course a long way > to go. > As I remember, it maked errors in the unicode handling of some *lazy* decorators in the django core. It isn't a wonder, because the functionality of these decorators contain a sophisticated functionality for the generalized unicode / ascii handling which in py3 is not needed. I think, the good fix is trivial for the core team and possibly it is done already in the official py3 branch (if not, I feel some urge to do this :-) ) bye, MaXX -- 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
On 14.09.2011, at 19:19, Cal Leeming [Simplicity Media Ltd] wrote: > Can I ask, have the django core team already accepted that Django will > eventually be a 3.x framework, or will it be un-officially forked? Yes, the core team has identified the port to Python 3 as a needed step which is why I've posted the first mail in this thread earlier today. So this is not about forking Django, but a specific branch in the SVN which at some point in the distant future might be merged with trunk [1]. Jannis 1: https://code.djangoproject.com/browser/django/branches/features/py3k/ > 2011/9/14 Ákos Péter Horváth> Another vote to python3 :-) > > Really, I started to port that with a recursive 2to3. It is not too far from > good working. There are no big magic things, altough I think a py2 and py3 > support isn't possible from a common source tree. Some deep core improvement > is needed too, mostly on the unicode line, but nothing really hard. > > Anybody knows somebody who started a django/py3 port already? We should unify > our efforts. > > If core team doesn't like the py3 idea, we should start with a patch which > follows always the latest devel version. I strongly anticipate a project fork > (see what happened with the plone & bluebream). > > 2to3 (3to2), etc are good start for an initial port, but I think they aren't > enough to do this on day-to-day base. Their conversion algo isn't enough, > some handwork is needed. > > thank you > > MaXX > > > On Wed, Sep 14, 2011 at 5:55 PM, Daniel Lindsley wrote: > Jannis, > > > I wasn't trying to suggest we leave anyone behind, far from it. I > was suggesting move the code to Python 3 now, while there's less code > there (than some future date) but using 3to2[1] to help others on > Python 2.X. Since Django still supports 2.5, it's possible that this > isn't even an option, as I don't know if 3to2 can translate back that > far reliably. Simply getting the question out there for others to mull > over. > > > Daniel > > > > On Sep 14, 10:36 am, Jannis Leidel wrote: > > Daniel, > > > > > "You have my sword." I want to see this happen & would love to be a > > > part of it. > > > > Huzzah! > > > > > A couple questions: > > > > > * How should patches be provided? Trac? BitBucket? > > > > For now via Trac, that's why we've moved the changes into a SVN branch. > > Unless anyone has a better idea I could create a Trac component "Python 3" > > so we can track the tickets easily. > > > > > * Where should feedback go? This mailing list? Somewhere else? > > > > Feedback should go here, on the developers mailing list, to get as many > > eyes on it as possible. > > > > > * This is further off, but once we have a ported Django, how do get > > > the community (specifically pluggable apps) onboard? I'm assuming the > > > docs are meant to do this but wondering if there's anything else we > > > can be doing (like perhaps a Django-specific 2to3 (extension?) to > > > cover common Django conventions). > > > > Very good question, I'm uncertain as to how the "helpers" I mentioned > > will look like in the end. Whether they will be part of Django (e.g. > > a management command to run 2to3 on an app) or if we "only" provide the > > necessary compatibility library (e.g. "six") so that 3rd party app > > authors would still keep writing apps with Python 2 but would allow > > their apps to be translated to Python 3 automatically. Documenting ways > > of how to write a setup.py to do the conversion during install time > > is *in* the scope of what we need to provide, IMO. Whether we need > > Django-specific 2to3 fixers isn't clear at this time as the porting > > has only just begun. > > > > > * Do we have a target date? I know this is hard with a volunteer-only > > > effort, but if we setup some sort of timeline, we'd at least have a > > > metric & something to shoot/push for. > > > > 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]. > > > > > Finally, a philosophical question on approach: Should we really be > > > doing 2to3 (leaving the Django codebase in Python 2.X for a long time) > > > 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. > > > > 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"
Re: Python 3 and you
On 14.09.2011, at 18:57, Ákos Péter Horváth wrote: > Really, I started to port that with a recursive 2to3. It is not too far from > good working. There are no big magic things, altough I think a py2 and py3 > support isn't possible from a common source tree. Some deep core improvement > is needed too, mostly on the unicode line, but nothing really hard. > > Anybody knows somebody who started a django/py3 port already? We should unify > our efforts. As I said earlier in this thread, there is now a Python 3 branch in the Django SVN. > If core team doesn't like the py3 idea, we should start with a patch which > follows always the latest devel version. I strongly anticipate a project fork > (see what happened with the plone & blue bream). The core team likes the idea, there is no fork required. > 2to3 (3to2), etc are good start for an initial port, but I think they aren't > enough to do this on day-to-day base. Their conversion algo isn't enough, > some handwork is needed. Could you be a bit more specific about what the algorithm can't do? From what I saw in Martin von Löwis' patch (which is now in the Python 3 branch) we haven't hit any problem with 2to3. That said, it's of course a long way to go. Jannis > I wasn't trying to suggest we leave anyone behind, far from it. I > was suggesting move the code to Python 3 now, while there's less code > there (than some future date) but using 3to2[1] to help others on > Python 2.X. Since Django still supports 2.5, it's possible that this > isn't even an option, as I don't know if 3to2 can translate back that > far reliably. Simply getting the question out there for others to mull > over. > > > Daniel > > > > On Sep 14, 10:36 am, Jannis Leidelwrote: > > Daniel, > > > > > "You have my sword." I want to see this happen & would love to be a > > > part of it. > > > > Huzzah! > > > > > A couple questions: > > > > > * How should patches be provided? Trac? BitBucket? > > > > For now via Trac, that's why we've moved the changes into a SVN branch. > > Unless anyone has a better idea I could create a Trac component "Python 3" > > so we can track the tickets easily. > > > > > * Where should feedback go? This mailing list? Somewhere else? > > > > Feedback should go here, on the developers mailing list, to get as many > > eyes on it as possible. > > > > > * This is further off, but once we have a ported Django, how do get > > > the community (specifically pluggable apps) onboard? I'm assuming the > > > docs are meant to do this but wondering if there's anything else we > > > can be doing (like perhaps a Django-specific 2to3 (extension?) to > > > cover common Django conventions). > > > > Very good question, I'm uncertain as to how the "helpers" I mentioned > > will look like in the end. Whether they will be part of Django (e.g. > > a management command to run 2to3 on an app) or if we "only" provide the > > necessary compatibility library (e.g. "six") so that 3rd party app > > authors would still keep writing apps with Python 2 but would allow > > their apps to be translated to Python 3 automatically. Documenting ways > > of how to write a setup.py to do the conversion during install time > > is *in* the scope of what we need to provide, IMO. Whether we need > > Django-specific 2to3 fixers isn't clear at this time as the porting > > has only just begun. > > > > > * Do we have a target date? I know this is hard with a volunteer-only > > > effort, but if we setup some sort of timeline, we'd at least have a > > > metric & something to shoot/push for. > > > > 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]. > > > > > Finally, a philosophical question on approach: Should we really be > > > doing 2to3 (leaving the Django codebase in Python 2.X for a long time) > > > 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. > > > > 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 :) > > > > I don't dare to
Re: Python 3 and you
Can I ask, have the django core team already accepted that Django will eventually be a 3.x framework, or will it be un-officially forked? Personally - I'd love to see people ride the 2.x train until its last dying breath, but that's just me ;) Cal 2011/9/14 Ákos Péter Horváth> Another vote to python3 :-) > > Really, I started to port that with a recursive 2to3. It is not too far > from good working. There are no big magic things, altough I think a py2 and > py3 support isn't possible from a common source tree. Some deep core > improvement is needed too, mostly on the unicode line, but nothing really > hard. > > Anybody knows somebody who started a django/py3 port already? We should > unify our efforts. > > If core team doesn't like the py3 idea, we should start with a patch which > follows always the latest devel version. I strongly anticipate a project > fork (see what happened with the plone & bluebream). > > 2to3 (3to2), etc are good start for an initial port, but I think they > aren't enough to do this on day-to-day base. Their conversion algo isn't > enough, some handwork is needed. > > thank you > > MaXX > > > On Wed, Sep 14, 2011 at 5:55 PM, Daniel Lindsley wrote: > >> Jannis, >> >> >> I wasn't trying to suggest we leave anyone behind, far from it. I >> was suggesting move the code to Python 3 now, while there's less code >> there (than some future date) but using 3to2[1] to help others on >> Python 2.X. Since Django still supports 2.5, it's possible that this >> isn't even an option, as I don't know if 3to2 can translate back that >> far reliably. Simply getting the question out there for others to mull >> over. >> >> >> Daniel >> >> >> >> On Sep 14, 10:36 am, Jannis Leidel wrote: >> > Daniel, >> > >> > > "You have my sword." I want to see this happen & would love to be a >> > > part of it. >> > >> > Huzzah! >> > >> > > A couple questions: >> > >> > > * How should patches be provided? Trac? BitBucket? >> > >> > For now via Trac, that's why we've moved the changes into a SVN branch. >> > Unless anyone has a better idea I could create a Trac component "Python >> 3" >> > so we can track the tickets easily. >> > >> > > * Where should feedback go? This mailing list? Somewhere else? >> > >> > Feedback should go here, on the developers mailing list, to get as many >> > eyes on it as possible. >> > >> > > * This is further off, but once we have a ported Django, how do get >> > > the community (specifically pluggable apps) onboard? I'm assuming the >> > > docs are meant to do this but wondering if there's anything else we >> > > can be doing (like perhaps a Django-specific 2to3 (extension?) to >> > > cover common Django conventions). >> > >> > Very good question, I'm uncertain as to how the "helpers" I mentioned >> > will look like in the end. Whether they will be part of Django (e.g. >> > a management command to run 2to3 on an app) or if we "only" provide the >> > necessary compatibility library (e.g. "six") so that 3rd party app >> > authors would still keep writing apps with Python 2 but would allow >> > their apps to be translated to Python 3 automatically. Documenting ways >> > of how to write a setup.py to do the conversion during install time >> > is *in* the scope of what we need to provide, IMO. Whether we need >> > Django-specific 2to3 fixers isn't clear at this time as the porting >> > has only just begun. >> > >> > > * Do we have a target date? I know this is hard with a volunteer-only >> > > effort, but if we setup some sort of timeline, we'd at least have a >> > > metric & something to shoot/push for. >> > >> > 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]. >> > >> > > Finally, a philosophical question on approach: Should we really be >> > > doing 2to3 (leaving the Django codebase in Python 2.X for a long time) >> > > 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. >> > >> > 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.
Re: Python 3 and you
Hi, On Wed, Sep 14, 2011 at 10:03 AM, Jannis Leidelwrote: > Hi all, > > After last week's sprint I wanted to get you up-to-speed about the > current state of porting Django to Python 3. > I'm very happy with this news. > As some may be aware Martin von Löwis has been working on a port for > a while [1] but only recently I've had the chance to meet with him and > talk through the porting process. > I already started a django port to python3 in following MvL way, using 2to3 but I had steel problems with tests. I think that you already fix this using python3k test. I want help with this. I will get the branch code and help fixing some tests ok? -- Andrews Medina www.andrewsmedina.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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
Daniel, > I wasn't trying to suggest we leave anyone behind, far from it. I > was suggesting move the code to Python 3 now, while there's less code > there (than some future date) but using 3to2[1] to help others on > Python 2.X. Since Django still supports 2.5, it's possible that this > isn't even an option, as I don't know if 3to2 can translate back that > far reliably. Simply getting the question out there for others to mull > over. Apologies for the misunderstanding. This is definitely an option which should be tried out instead of forward porting with 2to3. That said, it seems like there are a few technical limitations: "However, there is no Distribute support for 3to2 and also Python 2.5 or earlier also do not include the required lib2to3 package. Therefore 3to2 currently remains only an interesting experiment, although this may change in the future." -- http://python3porting.com/strategies.html#using-3to2 Besides that, I could also think that missing Python 3 expertise in the community would prevent a smooth direct transition to Python 3. There is no doubt that it needs to happen eventually but we just need to figure out if we're ready for it. Jannis > On Sep 14, 10:36 am, Jannis Leidelwrote: >> Daniel, >> >> >> Huzzah! >> >> >> >> For now via Trac, that's why we've moved the changes into a SVN branch. >> Unless anyone has a better idea I could create a Trac component "Python 3" >> so we can track the tickets easily. >> >> >> Feedback should go here, on the developers mailing list, to get as many >> eyes on it as possible. >> >> >> Very good question, I'm uncertain as to how the "helpers" I mentioned >> will look like in the end. Whether they will be part of Django (e.g. >> a management command to run 2to3 on an app) or if we "only" provide the >> necessary compatibility library (e.g. "six") so that 3rd party app >> authors would still keep writing apps with Python 2 but would allow >> their apps to be translated to Python 3 automatically. Documenting ways >> of how to write a setup.py to do the conversion during install time >> is *in* the scope of what we need to provide, IMO. Whether we need >> Django-specific 2to3 fixers isn't clear at this time as the porting >> has only just begun. >> >> >> 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]. >> >> >> 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 :) >> >> 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. >> >> Jannis >> >> 1:http://docs.python.org/py3k/howto/pyporting.html#try-to-support-pytho... -- 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
Help to cite appropriately. [1] was http://pypi.python.org/pypi/3to2. On Sep 14, 10:55 am, Daniel Lindsleywrote: > Jannis, > > I wasn't trying to suggest we leave anyone behind, far from it. I > was suggesting move the code to Python 3 now, while there's less code > there (than some future date) but using 3to2[1] to help others on > Python 2.X. Since Django still supports 2.5, it's possible that this > isn't even an option, as I don't know if 3to2 can translate back that > far reliably. Simply getting the question out there for others to mull > over. > > Daniel > > On Sep 14, 10:36 am, Jannis Leidel wrote: > > > > > > > > > Daniel, > > > > "You have my sword." I want to see this happen & would love to be a > > > part of it. > > > Huzzah! > > > > A couple questions: > > > > * How should patches be provided? Trac? BitBucket? > > > For now via Trac, that's why we've moved the changes into a SVN branch. > > Unless anyone has a better idea I could create a Trac component "Python 3" > > so we can track the tickets easily. > > > > * Where should feedback go? This mailing list? Somewhere else? > > > Feedback should go here, on the developers mailing list, to get as many > > eyes on it as possible. > > > > * This is further off, but once we have a ported Django, how do get > > > the community (specifically pluggable apps) onboard? I'm assuming the > > > docs are meant to do this but wondering if there's anything else we > > > can be doing (like perhaps a Django-specific 2to3 (extension?) to > > > cover common Django conventions). > > > Very good question, I'm uncertain as to how the "helpers" I mentioned > > will look like in the end. Whether they will be part of Django (e.g. > > a management command to run 2to3 on an app) or if we "only" provide the > > necessary compatibility library (e.g. "six") so that 3rd party app > > authors would still keep writing apps with Python 2 but would allow > > their apps to be translated to Python 3 automatically. Documenting ways > > of how to write a setup.py to do the conversion during install time > > is *in* the scope of what we need to provide, IMO. Whether we need > > Django-specific 2to3 fixers isn't clear at this time as the porting > > has only just begun. > > > > * Do we have a target date? I know this is hard with a volunteer-only > > > effort, but if we setup some sort of timeline, we'd at least have a > > > metric & something to shoot/push for. > > > 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]. > > > > Finally, a philosophical question on approach: Should we really be > > > doing 2to3 (leaving the Django codebase in Python 2.X for a long time) > > > 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. > > > 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 :) > > > 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. > > > Jannis > > > 1:http://docs.python.org/py3k/howto/pyporting.html#try-to-support-pytho... > > > > On Sep 14, 8:03 am, Jannis Leidel wrote: > > >> Hi all, > > > >> After last week's sprint I wanted to get you up-to-speed about the > > >> current state of porting Django to Python 3. > > > >> As some may be aware Martin von Löwis has been working on a port for > > >> a while [1] but only recently I've had the chance to meet with him and > > >> talk through the porting process. > > > >> I'm not going to hide the fact that it'll be a long process, but I'm > > >> also convinced it's an important step for Django to make. I'm writing > > >> this in the hope to find volunteers to join the porting efforts. > > > >> Goals > > >> - > > > >> To allow Django to run on Python 3 there are several goals to achieve, > > >> some of which are our respsonsibility, some depend on 3rd party libraries > > >> we use internally and some left to
Re: Python 3 and you
Jannis, I wasn't trying to suggest we leave anyone behind, far from it. I was suggesting move the code to Python 3 now, while there's less code there (than some future date) but using 3to2[1] to help others on Python 2.X. Since Django still supports 2.5, it's possible that this isn't even an option, as I don't know if 3to2 can translate back that far reliably. Simply getting the question out there for others to mull over. Daniel On Sep 14, 10:36 am, Jannis Leidelwrote: > Daniel, > > > "You have my sword." I want to see this happen & would love to be a > > part of it. > > Huzzah! > > > A couple questions: > > > * How should patches be provided? Trac? BitBucket? > > For now via Trac, that's why we've moved the changes into a SVN branch. > Unless anyone has a better idea I could create a Trac component "Python 3" > so we can track the tickets easily. > > > * Where should feedback go? This mailing list? Somewhere else? > > Feedback should go here, on the developers mailing list, to get as many > eyes on it as possible. > > > * This is further off, but once we have a ported Django, how do get > > the community (specifically pluggable apps) onboard? I'm assuming the > > docs are meant to do this but wondering if there's anything else we > > can be doing (like perhaps a Django-specific 2to3 (extension?) to > > cover common Django conventions). > > Very good question, I'm uncertain as to how the "helpers" I mentioned > will look like in the end. Whether they will be part of Django (e.g. > a management command to run 2to3 on an app) or if we "only" provide the > necessary compatibility library (e.g. "six") so that 3rd party app > authors would still keep writing apps with Python 2 but would allow > their apps to be translated to Python 3 automatically. Documenting ways > of how to write a setup.py to do the conversion during install time > is *in* the scope of what we need to provide, IMO. Whether we need > Django-specific 2to3 fixers isn't clear at this time as the porting > has only just begun. > > > * Do we have a target date? I know this is hard with a volunteer-only > > effort, but if we setup some sort of timeline, we'd at least have a > > metric & something to shoot/push for. > > 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]. > > > Finally, a philosophical question on approach: Should we really be > > doing 2to3 (leaving the Django codebase in Python 2.X for a long time) > > 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. > > 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 :) > > 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. > > Jannis > > 1:http://docs.python.org/py3k/howto/pyporting.html#try-to-support-pytho... > > > > > > > > > > > On Sep 14, 8:03 am, Jannis Leidel wrote: > >> Hi all, > > >> After last week's sprint I wanted to get you up-to-speed about the > >> current state of porting Django to Python 3. > > >> As some may be aware Martin von Löwis has been working on a port for > >> a while [1] but only recently I've had the chance to meet with him and > >> talk through the porting process. > > >> I'm not going to hide the fact that it'll be a long process, but I'm > >> also convinced it's an important step for Django to make. I'm writing > >> this in the hope to find volunteers to join the porting efforts. > > >> Goals > >> - > > >> To allow Django to run on Python 3 there are several goals to achieve, > >> some of which are our respsonsibility, some depend on 3rd party libraries > >> we use internally and some left to the users that use Django to build > >> their websites. It's my understanding that we can't solve everything > >> at once, so take this with a grain of salt: > > >> - get Django to run on Python 3 > >> - provide helpers and docs for porting Django-based projects > >> - help out 3rd party projects we
Re: Python 3 and you
Daniel, > "You have my sword." I want to see this happen & would love to be a > part of it. Huzzah! > A couple questions: > > * How should patches be provided? Trac? BitBucket? For now via Trac, that's why we've moved the changes into a SVN branch. Unless anyone has a better idea I could create a Trac component "Python 3" so we can track the tickets easily. > * Where should feedback go? This mailing list? Somewhere else? Feedback should go here, on the developers mailing list, to get as many eyes on it as possible. > * This is further off, but once we have a ported Django, how do get > the community (specifically pluggable apps) onboard? I'm assuming the > docs are meant to do this but wondering if there's anything else we > can be doing (like perhaps a Django-specific 2to3 (extension?) to > cover common Django conventions). Very good question, I'm uncertain as to how the "helpers" I mentioned will look like in the end. Whether they will be part of Django (e.g. a management command to run 2to3 on an app) or if we "only" provide the necessary compatibility library (e.g. "six") so that 3rd party app authors would still keep writing apps with Python 2 but would allow their apps to be translated to Python 3 automatically. Documenting ways of how to write a setup.py to do the conversion during install time is *in* the scope of what we need to provide, IMO. Whether we need Django-specific 2to3 fixers isn't clear at this time as the porting has only just begun. > * Do we have a target date? I know this is hard with a volunteer-only > effort, but if we setup some sort of timeline, we'd at least have a > metric & something to shoot/push for. 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]. > Finally, a philosophical question on approach: Should we really be > doing 2to3 (leaving the Django codebase in Python 2.X for a long time) > 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. 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 :) 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. Jannis 1: http://docs.python.org/py3k/howto/pyporting.html#try-to-support-python-2-6-and-newer-only > > > On Sep 14, 8:03 am, Jannis Leidelwrote: >> Hi all, >> >> After last week's sprint I wanted to get you up-to-speed about the >> current state of porting Django to Python 3. >> >> As some may be aware Martin von Löwis has been working on a port for >> a while [1] but only recently I've had the chance to meet with him and >> talk through the porting process. >> >> I'm not going to hide the fact that it'll be a long process, but I'm >> also convinced it's an important step for Django to make. I'm writing >> this in the hope to find volunteers to join the porting efforts. >> >> Goals >> - >> >> To allow Django to run on Python 3 there are several goals to achieve, >> some of which are our respsonsibility, some depend on 3rd party libraries >> we use internally and some left to the users that use Django to build >> their websites. It's my understanding that we can't solve everything >> at once, so take this with a grain of salt: >> >> - get Django to run on Python 3 >> - provide helpers and docs for porting Django-based projects >> - help out 3rd party projects we rely only to make the jump (if needed) >> >> Porting strategies >> -- >> >> As you can imagine there are still quite a few open questions at >> the moment about specific porting problems but taking from the >> experience in the Python community I think we have a good general >> strategy. >> >> There are a few assumptions we're applying either because it's >> unrealistic or impossible to maintain as long as Python 2.X is in >> use for the forseeable future; so these strategy *don't* work: >> >> - Create a Python 3 only port ("burning the bridges") >> >> This is outright a no-go since it would leave all the Python 2.X
Re: Python 3 and you
Jannis, "You have my sword." I want to see this happen & would love to be a part of it. A couple questions: * How should patches be provided? Trac? BitBucket? * Where should feedback go? This mailing list? Somewhere else? * This is further off, but once we have a ported Django, how do get the community (specifically pluggable apps) onboard? I'm assuming the docs are meant to do this but wondering if there's anything else we can be doing (like perhaps a Django-specific 2to3 (extension?) to cover common Django conventions). * Do we have a target date? I know this is hard with a volunteer-only effort, but if we setup some sort of timeline, we'd at least have a metric & something to shoot/push for. Finally, a philosophical question on approach: Should we really be doing 2to3 (leaving the Django codebase in Python 2.X for a long time) 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. Regardless, I'm excited & will see what I can do to help. Daniel On Sep 14, 8:03 am, Jannis Leidelwrote: > Hi all, > > After last week's sprint I wanted to get you up-to-speed about the > current state of porting Django to Python 3. > > As some may be aware Martin von Löwis has been working on a port for > a while [1] but only recently I've had the chance to meet with him and > talk through the porting process. > > I'm not going to hide the fact that it'll be a long process, but I'm > also convinced it's an important step for Django to make. I'm writing > this in the hope to find volunteers to join the porting efforts. > > Goals > - > > To allow Django to run on Python 3 there are several goals to achieve, > some of which are our respsonsibility, some depend on 3rd party libraries > we use internally and some left to the users that use Django to build > their websites. It's my understanding that we can't solve everything > at once, so take this with a grain of salt: > > - get Django to run on Python 3 > - provide helpers and docs for porting Django-based projects > - help out 3rd party projects we rely only to make the jump (if needed) > > Porting strategies > -- > > As you can imagine there are still quite a few open questions at > the moment about specific porting problems but taking from the > experience in the Python community I think we have a good general > strategy. > > There are a few assumptions we're applying either because it's > unrealistic or impossible to maintain as long as Python 2.X is in > use for the forseeable future; so these strategy *don't* work: > > - Create a Python 3 only port ("burning the bridges") > > This is outright a no-go since it would leave all the Python 2.X > projects in dead water. Instead we need to provide a migration > path for them. > > - Maintaing a separate Python 3 branch ("dual releases") > > While this would allow for new projects to use Python 3, I'm > convinced this has the potential to split the community. It'd > also be a major burden for the core team to maintain both > branches. Instead we need a combined effort. > > So as a result of that the only viable option is to support both major > versions of Python at the same time, with the same code base. > > Fortunately the Python community gained lots of experience in the past > years to make this happen (e.g. Lennart Regebro's book [4]). There are > also tools to ease the transition of Django and the Django-based > projects. Some of which are: > > - six [3] -- a compatibility library that includes many (if not all) > needed import proxies and utilities to prepare Django and Django-based > projects to be ported to Python 3.X. This only applies to API that > isn't syntactically changed, but only moved or enhanced in 3.X. > > - 2to3 [2] -- an extensible library which is able to translate the rest > of the Python 2 code to the Python 3 equivalent. For every Django > specific feature that isn't covered by the default 2to3 "fixers" we can > write our own if needed. It integrates with distutils (in Python 3.X) > and is able to convert Django at installation time. Installing Django > with Python 2 wouldn't trigger the translation process, of course. > > Code status > --- > > During the sprint we've moved Martin's code from a Bitbucket clone to > an own SVN branch: > > https://code.djangoproject.com/browser/django/branches/features/py3k/ > > Some notable changes: > > - a modified ``setup.py`` which automatically calls 2to3 during installation > > - a ``py3ktest`` helper bash script which -- for now -- installs Django in > a directory called "3k" in the same directory to trigger the translation >
Python 3 and you
Hi all, After last week's sprint I wanted to get you up-to-speed about the current state of porting Django to Python 3. As some may be aware Martin von Löwis has been working on a port for a while [1] but only recently I've had the chance to meet with him and talk through the porting process. I'm not going to hide the fact that it'll be a long process, but I'm also convinced it's an important step for Django to make. I'm writing this in the hope to find volunteers to join the porting efforts. Goals - To allow Django to run on Python 3 there are several goals to achieve, some of which are our respsonsibility, some depend on 3rd party libraries we use internally and some left to the users that use Django to build their websites. It's my understanding that we can't solve everything at once, so take this with a grain of salt: - get Django to run on Python 3 - provide helpers and docs for porting Django-based projects - help out 3rd party projects we rely only to make the jump (if needed) Porting strategies -- As you can imagine there are still quite a few open questions at the moment about specific porting problems but taking from the experience in the Python community I think we have a good general strategy. There are a few assumptions we're applying either because it's unrealistic or impossible to maintain as long as Python 2.X is in use for the forseeable future; so these strategy *don't* work: - Create a Python 3 only port ("burning the bridges") This is outright a no-go since it would leave all the Python 2.X projects in dead water. Instead we need to provide a migration path for them. - Maintaing a separate Python 3 branch ("dual releases") While this would allow for new projects to use Python 3, I'm convinced this has the potential to split the community. It'd also be a major burden for the core team to maintain both branches. Instead we need a combined effort. So as a result of that the only viable option is to support both major versions of Python at the same time, with the same code base. Fortunately the Python community gained lots of experience in the past years to make this happen (e.g. Lennart Regebro's book [4]). There are also tools to ease the transition of Django and the Django-based projects. Some of which are: - six [3] -- a compatibility library that includes many (if not all) needed import proxies and utilities to prepare Django and Django-based projects to be ported to Python 3.X. This only applies to API that isn't syntactically changed, but only moved or enhanced in 3.X. - 2to3 [2] -- an extensible library which is able to translate the rest of the Python 2 code to the Python 3 equivalent. For every Django specific feature that isn't covered by the default 2to3 "fixers" we can write our own if needed. It integrates with distutils (in Python 3.X) and is able to convert Django at installation time. Installing Django with Python 2 wouldn't trigger the translation process, of course. Code status --- During the sprint we've moved Martin's code from a Bitbucket clone to an own SVN branch: https://code.djangoproject.com/browser/django/branches/features/py3k/ Some notable changes: - a modified ``setup.py`` which automatically calls 2to3 during installation - a ``py3ktest`` helper bash script which -- for now -- installs Django in a directory called "3k" in the same directory to trigger the translation from Python 2 to Python 3 code and then run the tests from the build directory directly because they are not part of the installation in "3k" because we don't include it. This script should be seen a temporary workaround till we've found a better way to run the tests (Could we use tox instead? [5]). - a new django.utils.py3 module which contains some helpers that are used throughout the code as a common API to ease the pain of maintaining a project that runs on both Python 2 and 3. I expect it to grow in size while we port Django, but even then it may not be complete enough to be useful for Django-based user projects. Which is why I think Django should ship the "six" library [3] instead, on the long run ("six" has the advantage of being maintained by a Python core developer). A good overview of the current changes can be seen on Bitbucket: https://bitbucket.org/django/django/compare/features/py3k..default Right now it's mostly changes to how byte and unicode strings are handled by using a b() and u() function instead of the 'u' prefix. That said, this is far from complete. How to help --- We have multiple big pieces of the puzzle to solve: - Try out the branch by running the tests with the ``py3ktest`` script and fix the failed tests (needs an installed ``python3`` binary), one by one. This may be repetitive work, but could also be the chance for you to dive into the internals of Django. - Write a tutorial to prepare a Django app to for Python 3 by using one of the
CSRF protection and cookies
Hi, > Today we've released Django 1.3.1 and Django 1.2.6 to deal with > several security issues reported to us. Details of these issues and > the releases, along with several important advisory notes, are > available in the blog post on djangoproject.com: > > https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/ I've been thinking about the problems caused by the CSRF cookies being settable by other servers sharing the same domain name, as mentioned at the URL above: > Advisory: Cross-subdomain CSRF attacks > > Due to the nature of HTTP cookies, a cookie can be set from a subdomain > which will be valid for the entire domain. This means that an attacker > who controls a subdomain can, for example, set a CSRF cookie which will > be valid for the entire domain. If I understand it correctly, our CSRF protection works by putting the same random nonce in a form field and a cookie. The protection comes from the fact that the bad guy can only control the form field but not the cookie. But in the case above, he can control the cookie too and the protection fails. Is that correct? 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? / 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.