Re: proposal: abstract file upload/download handling
How often should I ping, so my patch won't be forgotten? :) On Thu, Aug 19, 2010 at 9:38 AM, Jannis Leidel wrote: > Am 19.08.2010 um 01:50 schrieb Waldemar Kornewald: > >> No comments means it's still not good enough and I'll never get it >> into an acceptable shape? :) > > No, in that case we would tell you :) It's much more likely that nobody had > time yet (in the last 3 days) to look at your patch thoroughly. > > Jannis > > >> On Sun, Aug 15, 2010 at 7:13 PM, Waldemar Kornewald >> wrote: >>> On Sat, Aug 14, 2010 at 1:45 PM, Waldemar Kornewald >>> wrote: On Thu, Jul 22, 2010 at 4:30 AM, Russell Keith-Magee wrote: > I accept the need for this, but this seems like a bit of a wart. This > method wouldn't be required at all if the Form took a request > argument. This isn't an unusual requirement, either -- perhaps we > should introduce a RequestForm/RequestModelForm that formalizes the > availability of the request object during form processing. OK, I've now added a Request(Model)Form. The tag is based on ., so you don't have to manually specify it. FileField takes an optional parameter to override this. Forms currently only allow to set the tag by subclassing. Not sure if this is sufficient. http://code.djangoproject.com/attachment/ticket/13960/filetransfers.3.diff >>> >>> Now I've finished admin UI support for the proposed API: >>> http://code.djangoproject.com/attachment/ticket/13960/filetransfers.4.diff >>> >>> If you want to see a more practical example, the following >>> demonstrates an async upload process (like with S3 or App Engine): >>> http://bitbucket.org/wkornewald/upload-sample-trunk-filetransfers >>> >>> The same async upload process is used in the admin UI. If you submit a >>> file from within the admin UI the file first gets sent to a view at >>> /upload and then the request gets forwarded to the actual admin view. >>> Also, the backend changes the file download URLs (even in the admin >>> UI) to point to the download view at /download. >>> >>> BTW, if you're too busy/lazy to apply the patch you can just clone my >>> Django development branch: >>> http://bitbucket.org/wkornewald/django-trunk-filetransfers >>> >>> Bye, >>> Waldemar Kornewald >>> >>> -- >>> Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: >>> http://www.allbuttonspressed.com/blog/django >>> >> >> >> >> -- >> Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: >> http://www.allbuttonspressed.com/blog/django >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-develop...@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-develop...@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-develop...@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: Inline template rendering in admin shouldn't silence errors
Russell,
Sorry, we didn't understand each other,
You're talking about additional problems for templates with variable names.
However main point that George made was that he wanted template
rendering to break when including templates fails, no matter if that
was in the parse time or rendering time.
To address your "original point -- that runtime template errors are
considered unacceptable" I suggested that we have 2 different template
tags instead of include, one that will break, another one that will
not, because me and George wanted to have not the current version of
include tag but one that breaks on errors.
Implementation could look like the following: wrapper in the render()
part of include node, that uses some internal "current template"
variable. Another variable in the parser for this purpose.
P.S. This improvement is also related to my syntax coloring feature,
since I wanted to improve template errors display as well.
On Thu, Sep 2, 2010 at 1:41 PM, Russell Keith-Magee
wrote:
> On Thu, Sep 2, 2010 at 2:30 PM, burc...@gmail.com wrote:
>> Hi Russell,
>>
>> I'd define
>>> {% for templ in template_list %}
>>> {% include templ %}
>>> {% endfor %}
>> as a special case, for which special command or pattern should exist.
>>
>> Should it be
>> {% for templ in template_list %}
>> {% try-include template %}
>> {% endfor %}
>> or the opposite to be called
>> {% require template %} instead of include,
>> or maybe this whole pattern should be written as
>> {% include-first templ %}
>>
>> But in most cases {% include %} is used as "require", so in my
>> opinion it should raise errors!
>>
>> I'd also consider a require-once pattern to fix common widget chrome
>> problems (i.e. different parts of the page might include jquery in
>> headers).
>
> Either I'm completely missing the point you're trying to make, or
> you've completely missed the point I was making.
>
> Template rendering is a two step process:
> 1. Parse the template
> 2. Render the template.
>
> The point I was trying to make is that at step 1, we *can't* know the
> name of the subtemplate used in an {% include %}. This isn't a matter
> for negotiation or something we are in a position to design -- it's
> simply the way that the tag is implemented.
>
> I don't see how changing the name of the include tag to "require" or
> "try-include" changes anything, or how an alternate tag with those
> names would behave differently.
>
> Yours
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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-develop...@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.
Tahoe-LAFS, Django, RAIC
Dear Tahoe-LAFS hackers, Django developers, Anders Pearson, and Jakob Pagter: I guess it is a sign that your Free Software project is succeeding when you have more users than you know that you have. Today I was reading this article about Zope vs. Django persistence strategies: http://blog.mozilla.com/webdev/2010/08/30/from-zope-import-django-persistence/ It mentioned that although Django's native persistence language has always been SQL that there was recent interest in porting it to "NoSQL databases". On a whim, I searched the web for "django tahoe-lafs" and what do you know! Someone named Anders Pearson has written code to make Django use Tahoe-LAFS as a storage backend: http://github.com/thraxil/django-tahoestorage The README.txt warns of performance issues. I'm not surprised! It would be interesting to see if the performance could be improved in various ways. For one thing, Kevan Carstensen just finished his Google Summer of Code project which makes the directories a lot more scalable, directly helping with the "what happens when you have too many items in a directory" problem that the README.txt mentions. Anders has also written "a django frontend for Tahoe-LAFS": http://github.com/thraxil/canopy What is "a django frontend of Tahoe-LAFS"? Is it a user interface, so basically an alternative to the Tahoe-LAFS Web User Interface (http://pubgrid.tahoe-lafs.org/ )? Then I searched twitter for mention of Tahoe-LAFS and found this tweet in Danish by Jakob Pagter: http://twitter.com/pagter/status/22616015915 It is hard for me to understand Danish, even with the help of modern free on-line machine translation services. But, the hyperlink leads to this good article (in English): http://alexandrasikkerhed.wordpress.com/2010/08/31/the-tahoe-least-authority-file-system/ It says among other things that the authors are interested in layering a different access control model on top of Tahoe-LAFS and that they are interested in using existing cloud storage providers as backends. All very interesting! I would encourage the authors of such interesting hacks to write to the tahoe-dev list and see if the Tahoe-LAFS hackers there can help with their projects. For one thing, Kevan Carstensen has written up a design document about how to connect Tahoe-LAFS storage servers with extant cloud storage providers. We call it "RAIC" -- Redundant Array of Inexpensive Clouds. :-) For a picture of RAIC, see slide 17 of http://tahoe-lafs.org/trac/tahoe-lafs/raw-attachment/wiki/News/tahoe-RSA-slides.pdf . Kevan's design document: http://tahoe-lafs.org/pipermail/tahoe-dev/2010-April/004233.html Regards, Zooko -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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 Middleware/SSL/Firefox 3.6.8 bug
On Fri, Aug 27, 2010 at 7:53 PM, Luke Plant wrote: > > Finally, the only time we need Referer headers sent is for same origin > requests (POST requests to be exact). Sending the Referer header in > this case is virtually never a privacy concern, since the site will > already be able to track what other pages you have visited on their > site. So, if this turns out to be a problem, we could possibly ask > Mozilla (and other browsers) to add special casing for this (e.g. make > the 'sendRefererHeader' option only apply to cross domain requests). > > By the way, we are not the only ones doing this. Other people have > suggested that strict Referer checking under HTTPS is a very effective > and simple way to combat CSRF [1]. > > Luke > > [1] http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf > Any sort of Referer checking is broken by design, since that header is clearly optional. RFC 2616 makes explicitly clear that applications should not rely on Referer being sent. Any argument that sending it "is virtually never a privacy concern" is moot; you must not rely on the existence of that header, even if it is a useful tool in 99% of cases. Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Actions in popups
Users regularly get confused when you present them with a raw_id popup window which shows action checkboxes beside the list of items they are selecting from -- they try to click the checkboxes, and wonder why the window isn't closing. IMHO it really doesn't make much sense to be performing actions within the context of a popup selection window anyway, though I'm no UXpert. A search on trac revealed [1]. Opinions? [1] http://code.djangoproject.com/ticket/11700 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Inline template rendering in admin shouldn't silence errors
On Thu, Sep 2, 2010 at 5:04 PM, burc...@gmail.com wrote: > Russell, > > Sorry, we didn't understand each other, > > You're talking about additional problems for templates with variable names. > > However main point that George made was that he wanted template > rendering to break when including templates fails, no matter if that > was in the parse time or rendering time. > > To address your "original point -- that runtime template errors are > considered unacceptable" I suggested that we have 2 different template > tags instead of include, one that will break, another one that will > not, because me and George wanted to have not the current version of > include tag but one that breaks on errors. First off, I'm not about to add a second template tag for including subtemplates. One is more than sufficient. Secondly, I still don't see how what you're describing is possible. The name of the template to be included is not determined until the template is *rendered*. This is a completely to when the template is *parsed*, and it is the *parsing* process that generates TemplateSyntaxErrors. If we can't work out which subtemplate is to be used until rendering, we can't raise a syntax error when the parent template is parsed. > Implementation could look like the following: wrapper in the render() > part of include node, that uses some internal "current template" > variable. Another variable in the parser for this purpose. At this point, you're going to need to show me a patch. I can't see how what you're describing is possible without violating the stateless nature of the parsed template tree and/or doing some sort of template pre-rendering. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Inline template rendering in admin shouldn't silence errors
Dear Russ, I still don't quite get why "runtime template errors are unacceptable". My understanding is that if user has DEBUG=True, and TEMPLATE_DEBUG=True, then clearly (at least to me) the user does want to see all of the errors. DEBUG flags should be off in the production environment, right? Alternatively, the simplest solution that comes to my mind is to have a third flag CAN_I_REALLY_HAVE_TEMPLATE_DEBUG_PLZ_K_THX (I am not good at making up naming conventions) and if that one is set to True then do not silence _any_ errors at all during template rendering. George On Sep 2, 9:27 pm, Russell Keith-Magee wrote: > On Thu, Sep 2, 2010 at 5:04 PM, burc...@gmail.com wrote: > > Russell, > > > Sorry, we didn't understand each other, > > > You're talking about additional problems for templates with variable names. > > > However main point that George made was that he wanted template > > rendering to break when including templates fails, no matter if that > > was in the parse time or rendering time. > > > To address your "original point -- that runtime template errors are > > considered unacceptable" I suggested that we have 2 different template > > tags instead of include, one that will break, another one that will > > not, because me and George wanted to have not the current version of > > include tag but one that breaks on errors. > > First off, I'm not about to add a second template tag for including > subtemplates. One is more than sufficient. > > Secondly, I still don't see how what you're describing is possible. > The name of the template to be included is not determined until the > template is *rendered*. This is a completely to when the template is > *parsed*, and it is the *parsing* process that generates > TemplateSyntaxErrors. If we can't work out which subtemplate is to be > used until rendering, we can't raise a syntax error when the parent > template is parsed. > > > Implementation could look like the following: wrapper in the render() > > part of include node, that uses some internal "current template" > > variable. Another variable in the parser for this purpose. > > At this point, you're going to need to show me a patch. I can't see > how what you're describing is possible without violating the stateless > nature of the parsed template tree and/or doing some sort of template > pre-rendering. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: contrib/admin/validation.py
Would you accept the patch that would simply allow functions as well as iterables? On Sep 1, 10:35 pm, Russell Keith-Magee wrote: > On Wed, Sep 1, 2010 at 6:41 PM, Gregor Müllegger wrote: > > I ran into the same problem as George before. And it always hits when I try > > to > > modify my admin pages in undocumented ways. So I would also be for some > > changes in this area. > > > But I think we cannot simply remove it. Most constraints make much sense and > > usually help avoiding problems in your admin pages. I'm also quite sure that > > all these validation things help Django beginners to not run into errors > > with > > messages that cannot be understand. > > > I've not looked into the validation code yet, but I assume that the > > validation > > takes place as soon as you register your ModelAdmin with > > admin.site.register. > > > Maybe its worth to introduce a parameter here to disable the sanity checks: > > > admin.site.register(ModelAdmin, Model, validate=False) > > I'm not really in favor of removing validation. The validation serves > a very useful purpose for the vast majority of users, and duck typing > doesn't mean you can't (or shouldn't) check that the argument that has > been provided actually can quack in the appropriate way on demand. > > I'm also not wild about the idea of a simple flag to disable > validation -- that seems like a very big hammer to use when the > problem is ultimately with a couple of attributes on any given > ModelAdmin. > > However, I can see the benefit in: > > * Improving the existing validation checks so that they are more > tolerant of data that presented as a properties instead of attributes > > * Refactoring the validation code so that end-users can easily write > their own validators (or overwrite existing validators) on a > per-attribute basis. I haven't given much thought to what this would > look like, but analogies with clean_FOO() on forms would seem > appropriate. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Actions in popups
On Thu, Sep 2, 2010 at 7:08 PM, Simon Meers wrote: > Users regularly get confused when you present them with a raw_id popup > window which shows action checkboxes beside the list of items they are > selecting from -- they try to click the checkboxes, and wonder why the > window isn't closing. IMHO it really doesn't make much sense to be > performing actions within the context of a popup selection window anyway, > though I'm no UXpert. A search on trac revealed [1]. > > Opinions? > > [1] http://code.djangoproject.com/ticket/11700 I'm guessing by the date that my comments on the ticket were driven by the fact that I was triaging hundreds of tickets at the time. On reflection, what you're describing makes sense to me -- I can't seen any obvious reason why list_editable or edit actions should be available on a selection popup (raw_id or otherwise). Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Inline template rendering in admin shouldn't silence errors
On Thu, Sep 2, 2010 at 7:40 PM, George Karpenkov wrote: > Dear Russ, > > I still don't quite get why "runtime template errors are > unacceptable". My understanding is that if user has DEBUG=True, and > TEMPLATE_DEBUG=True, then clearly (at least to me) the user does want > to see all of the errors. DEBUG flags should be off in the production > environment, right? It's not quite as simple as that, for reasons that should be clear if you read the rest of my responses on this thread. > Alternatively, the simplest solution that comes to my mind is to have > a third flag CAN_I_REALLY_HAVE_TEMPLATE_DEBUG_PLZ_K_THX (I am not good > at making up naming conventions) and if that one is set to True then > do not silence _any_ errors at all during template rendering. 1. Added settings to control behavior like this is a very bad idea, and not one that I'm going to add to core. 2. This wouldn't work anyway; again, read the rest of my comments on this thread. Yours Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: contrib/admin/validation.py
On Thu, Sep 2, 2010 at 7:43 PM, George Karpenkov wrote: > Would you accept the patch that would simply allow functions as well > as iterables? Possibly, yes. Specifically, I'd be happy with any proposal that put ModelAdmin into alignment with other parts of Django, like the Syndication framework, allowing a function with no arguments (other than self) as an alternative to a class attribute. For example, this: class MyFeed(Feed): link = 'foobar' ... is the same as this: class MyFeed(Feed): def link(self): return 'foobar' in the syndication framework. Any other analogies with syndication would also potentially be welcome (e.g., richer interfaces for configuration via functions). Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Inline template rendering in admin shouldn't silence errors
On Thu, Sep 2, 2010 at 6:27 PM, Russell Keith-Magee wrote: > On Thu, Sep 2, 2010 at 5:04 PM, burc...@gmail.com wrote: >> Russell, >> >> Sorry, we didn't understand each other, >> >> You're talking about additional problems for templates with variable names. >> >> However main point that George made was that he wanted template >> rendering to break when including templates fails, no matter if that >> was in the parse time or rendering time. >> >> To address your "original point -- that runtime template errors are >> considered unacceptable" I suggested that we have 2 different template >> tags instead of include, one that will break, another one that will >> not, because me and George wanted to have not the current version of >> include tag but one that breaks on errors. > > First off, I'm not about to add a second template tag for including > subtemplates. One is more than sufficient. > > Secondly, I still don't see how what you're describing is possible. > The name of the template to be included is not determined until the > template is *rendered*. This is a completely to when the template is > *parsed*, and it is the *parsing* process that generates > TemplateSyntaxErrors. If we can't work out which subtemplate is to be > used until rendering, we can't raise a syntax error when the parent > template is parsed. Russell, Sorry. One more try. We don't need a error to be raised exactly on parsing stage, it's enough if parse error is raised on rendering. Do you mean we can't raise a syntax error when the included template is *rendered*? How to do this: If error was raised on parsing: Parser instruments parsed tree with a *raise error here* node to be raised on rendering this node later. If error was raised on rendering but you inserted current template into parent one: Included template is guarded with special node that saves the included template name for debugging purposes and re-raises parse error. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.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-develop...@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: Inline template rendering in admin shouldn't silence errors
On Thu, Sep 2, 2010 at 8:47 PM, burc...@gmail.com wrote:
> On Thu, Sep 2, 2010 at 6:27 PM, Russell Keith-Magee
> wrote:
>> On Thu, Sep 2, 2010 at 5:04 PM, burc...@gmail.com wrote:
>>> Russell,
>>>
>>> Sorry, we didn't understand each other,
>>>
>>> You're talking about additional problems for templates with variable names.
>>>
>>> However main point that George made was that he wanted template
>>> rendering to break when including templates fails, no matter if that
>>> was in the parse time or rendering time.
>>>
>>> To address your "original point -- that runtime template errors are
>>> considered unacceptable" I suggested that we have 2 different template
>>> tags instead of include, one that will break, another one that will
>>> not, because me and George wanted to have not the current version of
>>> include tag but one that breaks on errors.
>>
>> First off, I'm not about to add a second template tag for including
>> subtemplates. One is more than sufficient.
>>
>> Secondly, I still don't see how what you're describing is possible.
>> The name of the template to be included is not determined until the
>> template is *rendered*. This is a completely to when the template is
>> *parsed*, and it is the *parsing* process that generates
>> TemplateSyntaxErrors. If we can't work out which subtemplate is to be
>> used until rendering, we can't raise a syntax error when the parent
>> template is parsed.
> Russell,
>
> Sorry. One more try.
>
> We don't need a error to be raised exactly on parsing stage, it's
> enough if parse error is raised on rendering.
>
> Do you mean we can't raise a syntax error when the included template
> is *rendered*?
You managed to peak my curiosity, so I took a quick look at the
implementation of {% include %}. I'm now completely confused as to the
problem you're having.
The current Django 1.2 implementation of the {% include %} tag *does*
raise a TemplateSyntaxError during rendering if the subtemplate has an
error -- but only if TEMPLATE_DEBUG=True. If you have a syntax error
in an included subtemplate, and you're in TEMPLATE_DEBUG mode, you
*should* be getting template syntax errors for an invalid included
template.
My comments so far have all been based on trying to explain the
behavior George originally described in terms of the broader
philosophy behind Django's template language, but I didn't actually
verify that problem as described. So - I went back to George's
original report and tried to reproduce the problem. I've added a
custom template to an inline ModelAdmin class. If I put a syntax error
in that file (I tried both an {%extends%} of a non-existing template,
and a missing {% endfor %} tag), I get a TemplateSyntaxError.
However, if I set TEMPLATE_DEBUG=False, I get the behavior George
described -- non-rendering of the inline, rather than the error.
So - what exactly is the problem here? Is this just a case of not
having DEBUG turned on?
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
python 3.x
bumping an already old question, is django going to run on python 3.x ? I found a few discussions talking about this, eg. and http://groups.google.com/group/django-developers/browse_thread/thread/f8c747a26aa5d8ed/0749bfa67b47c802 and http://groups.google.com/group/django-developers/browse_thread/thread/bf9d8808ee5aadb4/40fc62ffdfc551ff?q=%22python+3%22&lnk=nl&; as well as this page: http://wiki.python.org/moin/PortingDjangoTo3k So this question is not about the technical difficulties, rather about the existance of an official planning for supporting python 3.x. I guess i could formulate my question as: is there any url that tracks plans and difficulties for django supporting python 3.x? I am finding myself more an more interested into moving over python 3 - it brings several answers to some of my problems... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.x
On Thu, Sep 2, 2010 at 9:34 PM, stefanoC wrote: > bumping an already old question, is django going to run on python > 3.x ? > > I found a few discussions talking about this, eg. and > http://groups.google.com/group/django-developers/browse_thread/thread/f8c747a26aa5d8ed/0749bfa67b47c802 > and > http://groups.google.com/group/django-developers/browse_thread/thread/bf9d8808ee5aadb4/40fc62ffdfc551ff?q=%22python+3%22&lnk=nl&; > as well as this page: http://wiki.python.org/moin/PortingDjangoTo3k > > So this question is not about the technical difficulties, rather about > the existance of an official planning for supporting python 3.x. The short answer: http://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3 The longer answer: We haven't published a formal plan -- mostly because in volunteer projects, long term formal plans aren't worth the paper they aren't printed on :-) However, we are aware of the need to transition, and we do have an informal plan to do so. In practical terms, it means dropping support for Python 2.4 and 2.5 in successive releases of Django. Once we're at a Django 2.6 minimum supported version, using 2to3 to maintain parallel implementations becomes a lot easier. The factor slowing progress is the rate at which we can deprecate Python versions. This is largely driven by the Python versions that are in the field and are commercially supported. At the moment, RedHat Enterprise Linux is the laggard of the bunch; in order to support RHEL, we need to support Python 2.4. Our own deprecation policy is governed by the deprecation policies of the underlying operating system platforms. Effectively, this means that official support for Django under Python 3 is still a couple of years away. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.x
On Thu, Sep 2, 2010 at 9:03 AM, Russell Keith-Magee wrote: ... > Effectively, this means that official support for Django under Python > 3 is still a couple of years away. Fortunately, there is plenty to do preparing for this glorious day -- many commonly-used libraries which Django depends on directly, or which are commonly used in Django apps (like feedparser, BeautifulSoup, dateutils, etc.) need porting to python3. This is an active need serving the larger Python community. Please consider helping there. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.x
And let's not forget the ol' Python Imaging Library. By the way, does it bother anybody else that the home page of PIL says "A version of 1.1.7 for 3.X will be released later" and the date for 1.1.7 is November 15, 2009? On Sep 2, 9:45 am, Jeremy Dunck wrote: > On Thu, Sep 2, 2010 at 9:03 AM, Russell Keith-Magee > wrote: > > ... > > > Effectively, this means that official support for Django under Python > > 3 is still a couple of years away. > > Fortunately, there is plenty to do preparing for this glorious day -- > many commonly-used libraries which Django depends on directly, or > which are commonly used in Django apps (like feedparser, > BeautifulSoup, dateutils, etc.) need porting to python3. This is an > active need serving the larger Python community. Please consider > helping there. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
