Re: DoS using POST via hash algorithm collision

2012/1/20 Łukasz Rekucki > We all know browsers won't crash and they will render the page exactly > the same. I volunteer to fix any issues in the test suite (considering > the hash changes also between 32-bit/64-bit Python, i'm not sure there > are even any or we would get a

Re: "Current" timezone in admin

c one at this point. Maybe when we have more hindsight... Best regards, -- Aymeric Augustin. -- 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 unsubsc

Re: End-user defined fields, how would you approach it?

. Thanks, -- Aymeric Augustin. -- 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-developer

Re: Contract Django Developer Required - London

2012/2/9 BAC > I hope the group does not mind my posting this but thought it would be > of value to the community. > This mailing list is dedicated to the development of Django and job offers are off-topic. Thanks for your understanding. You may be interested in

Re: ticket/15926, advice

2012/2/7 Jonathan Paugh > I think this patch deserves some attention. I'd also appreciate some > guidance on contributing, as needed. > Hi Jonathan, You're on the right track. I've added some comments on the ticket. Thanks for your contribution! -- Aymeric. -- You received

Re: Django 1.4 beta 1 released

Hi Reinout, > I'm pretty sure that "beta" means "nope, you won't get any changes that > aren't bug fixes in", but I cannot find the page that says that. I assume I'm > right? That's true. > Related, a suggestion for the next release cycle: send an email to the > mailinglist that there's a

Re: Django 1.4 beta 1 released

On 16 févr. 2012, at 23:35, Reinout van Rees wrote: > I didn't realize that I could mark it "ready for check-in" myself. (But there > are 35 tickets ready for check-in, so I guess I still need to bug people to > get it to be actually checked in). That's mostly the consequence of a sprint that

Django 1.4: call for release blockers

Hello, 1.4 beta arrived a bit late, but we'd like to catch up and release RC1 before the end of the month. Until then, we're going to focus on: 1 - Release blockers: https://code.djangoproject.com/query?status=!closed=Release%20blocker 2 - RFC tickets -- unless they're new features:

Re: auto_now=True fields aren't updated on QuerySet.update()

On 20 févr. 2012, at 19:52, Yo-Yo Ma wrote: > On a related note, the new timezone.now() functionality is used for > ``DateTimeField.pre_save`` when ``auto_now=True``, but it isn't used > for ``DateField.pre_save`` or ``TimeField.pre_save``. Is this a bug I > should report, or is there something

Should the settings.py template include USE_TZ = True?

(subject changed because I'm forking the discussion) On 20 févr. 2012, at 21:29, Anssi Kääriäinen wrote: > Another question I have meant to ask is if 1.4 is too early to have > USE_TZ = True as default setting? I am afraid there are still some > bugs to iron out, some documentation to improve,

Re: django-admin.py startproject creating duplicate settings.py files

On 21 févr. 2012, at 04:31, Yo-Yo Ma wrote: > I have trunk installed from last night, and this is actual terminal > output (except for the stuff omitted on the left of the $): > > (my_venv) myusername$ django-admin.py startproject foobarz > (my_venv) myusername$ ls foobarz/ > __init__.py

Re: Should the settings.py template include USE_TZ = True?

On 20 févr. 2012, at 23:52, Jacob Kaplan-Moss wrote: > But I do think we should have some help for people transitioning -- > perhaps a timezone FAQ would be in order? Jacob, That's a good idea. I've created a ticket: https://code.djangoproject.com/ticket/17738 Everyone, If you think

Re: Should the settings.py template include USE_TZ = True?

On 21 févr. 2012, at 08:49, Anssi Kääriäinen wrote: > Some information about how hard this is can be gotten by updating the > tutorial part I to correctly use timezone aware datetimes. This is a good point and I will ensure that the tutorial works properly (there's a ticket about that).

Re: auto_now=True fields aren't updated on QuerySet.update()

On 21 févr. 2012, at 10:49, Anssi Kääriäinen wrote: >>> I can't see any point why the time zone for the process >>> should be something else? What is gained by that? Isn't using Europe/ >>> Helsinki for the process timezone downright dangerous due to daylight >>> saving times? Am I missing

Re: django 1.4b + mysql + boolean fields

Please go ahead, create a ticket and set its severity to "release blocker". Assuming a proper test was added with the fix for #13293, that test should fail on the geographic version of mysql. Unfortunately we don't have this engine on the CI server at this time. I'll try to add it. Thanks for

Re: django 1.4b + mysql + boolean fields

I just noticed that #17747 was reopened for this purpose, so there's no need for another ticket. Best regards, -- Aymeric. 2012/2/24 Aymeric Augustin <aymeric.augus...@polytechnique.org> > Please go ahead, create a ticket and set its severity to "release blocker". > &g

Re: USE_TZ related warnings caused by fixture loading

2012/3/1 Yo-Yo Ma > django/db/models/fields/__init__.py:808: RuntimeWarning: DateTimeField > received a naive datetime (2012-01-01 00:00:00) while time zone support is > active. > > The above warning is caused by a JSON fixture having "2012-01-01 00:00:00" > for a

Re: USE_TZ related warnings caused by fixture loading

2012/3/1 Jacob Kaplan-Moss <ja...@jacobian.org> > Aymeric Augustin wrote: > > Indeed, a fixture that was generated with USE_TZ = False (or before time > > zone support existed) will raise warnings when it's loaded with USE_TZ = > > True. > > Ahha - I've been see

Re: USE_TZ related warnings caused by fixture loading

On 1 mars 2012, at 18:12, Aymeric Augustin wrote: > Sure, I'll take care of this. See https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#fixtures Feel free to comment on #17738 or open a new ticket if you have more questions. Best regards, -- Aymeric. -- You received this mess

Re: Django participation in Google Summer of Code 2012

PEP 414 was accepted a few days ago. It's designed to make it easier to support 2.6, 2.7, 3.3+ on the same codebase. I hope we'll take advantage of this new feature in Django; however, that means a large update (if not a reboot) of the py3k branch. -- Aymeric. -- You received this message

Re: Django participation in Google Summer of Code 2012

2012/3/8 Carl Meyer > Note that the current version of Vinay's port (since it was updated to > account for dropping Python 2.5 support post-1.4) does not use u() and > b() functions, it uses "from __future__ import unicode_literals". This > means that the only place string

Re: ANN: Django 1.4 string freeze and translation updates needed

Hello, A second RC was just released [2]; it includes translations contributed until yesterday (roughly 2012-03-14 08:50:00 UTC). If everything goes according to plan, the final 1.4 release will happen on March 21st. We'll probably pull the translations from Transifex on March 20th. I'd like

Re: Custom permissions on proxy model no longer created in 1.4

Le 15 mars 2012 10:27, koenb a écrit : > this could very well be one of those "don't do that" things, but here is > my problem. > > I have been using some specific permissions concerning the auth user model (... snip ...) Now I was testing my project with the 1.4

Re: auth.User refactor: reboot

Hello, I wanted to support the idea of the pluggable User model, but Russell just sent an excellent argumentation, saving me the effort :) I agree very much with his proposal. Subclassing, or writing an API-compatible class (duck typing) is the canonical way to alter a built-in behavior in

Re: Status of issue 17758: dict ordering bugs

Le 22 mars 2012 13:22, Łukasz Rekucki a écrit : > If the whole patch can't be merged, lets at least fix that bug[2]. Is > there any work I can do to make it happen? > [2]: > https://github.com/lqc/django/commit/84dc450ec861e34de068fde891537f0481342ef7 Hi Łukasz, Let's try

Re: suggestion: Don't make the tag "url" dirty in Django1.5

On 27 mars 2012, at 10:22, gs412 wrote: > In Django1.5 > > {% url app_views.client %} > will change to > {% "url app_views.client" %} > > I think it is a stupid idea > Why so many people use django? becouse of 'DRY', but now django become more > and more 'dirty' Hello, django-developers

Re: #18003: New policy: preserving originating call stacks for exceptions raised in a naked except block.

Le 29 mars 2012 09:51, Glenn Washburn a écrit : > So I feel strongly that django should have as a matter of > policy that originating call stacks should be preserved for raised > exceptions in naked or overly broad except blocks. That's one of the reasons why we have

Re: Django is not a serious framework, really

Hi Jason, Le 11 avril 2012 14:10, Jason Ma a écrit : > I heavily doubted that whether the writers have tested that carefully. As one of the many people who replayed the tutorial from A to Z, checked every little detail, updated screenshots, etc. before the release of 1.4, I

Re: extra files in startproject

On 12 avr. 2012, at 21:16, Carl Meyer wrote: > The open question is just how this situation occurs in the first place. > In other words, which particular buggy installer or installation > technique is causing an overlaid installation like that, so we can warn > people away from it and better

Re: extra files in startproject

On 12 avr. 2012, at 23:16, Aymeric Augustin wrote: > Some people who had the habit of running "setup.py install" from a git clone > to keep up-to-date with the development version reported the problem. > (Just to be 100% clear — this technique doesn't work because it do

Re: Django 1.4: session_key is None when calling a view with the test client

On 13 avr. 2012, at 18:42, Kai Diefenbach wrote: > Now my questions: Is this by intention? Can I get around that? Has this any > meaning for the application in production? Hello Kai, This is most likely a consequence of r17155 [1]. I'd like to understand if it's possible to trigger a

Re: QuerySet filtering weirdness for dates with 3-digit years

On 15 avr. 2012, at 00:28, Andy McKay wrote: > Which is this bug: http://bugs.python.org/issue1777412 FYI Django uses the django.utils.datetime_safe module to work around this problem when necessary. -- Aymeric. -- You received this message because you are subscribed to the Google Groups

Re: QuerySet filtering weirdness for dates with 3-digit years

On 14 avr. 2012, at 21:25, Evan Carmi wrote: > >>> Poll.objects.filter(pub_date__year=1) #We should get the poll p (but we > >>> don't) > [] The docs [1] say that the __year lookup "takes a four digit year". I'm not sure what this means exactly for years < 1000! It looks like it's possible to

Re: Implementation of Object Permissions

Hi Moritz, Thanks for your proposal! Here's my feedback. On 14 avr. 2012, at 01:56, Moritz S. wrote: > I found out about GenericRelations from the contenttypes framework. So you > could possibly use a single model called 'ObjectPermissions' or something and > link users, permissions and

Re: Problems with date-based generic views when USE_TZ=True

Hi Mike, On 27 avr. 2012, at 14:51, Mike Yumatov wrote: > I wrote a ticket about time zone warnings in date-based generic views: > https://code.djangoproject.com/ticket/18217 It isn't necessary to notify django-developers when you create a ticket; that's the job of django-updates. > After

Re: Problems with date-based generic views when USE_TZ=True

On 28 avr. 2012, at 07:56, Mike Yumatov wrote: >> They are in local time in the default time zone. > Are you sure? Because if so, YearArchiveView is broken: it uses year lookup > (https://docs.djangoproject.com/en/1.4/ref/models/querysets/#year), which is > performed in UTC. Indeed, you're

Re: GitHub migration done!

On 28 avr. 2012, at 05:08, Adrian Holovaty wrote: > * We're going to keep using Trac for tickets, but pull requests on > GitHub are also welcome. Hi everyone, For extra safety, I recommend you still create Trac tickets for each suggested change, until we work out how pull requests integrate

Re: GitHub migration done!

On 28 avr. 2012, at 21:46, Yuval Adam wrote: > I think this issue should be dealt with sooner rather than later. > > Django will start getting lots of orphan pull requests with no > matching trac ticket, and a policy of how community members should > contribute via github should be in place. >

Re: timezone.override() doesn't play well with template response views, by default

On 1 mai 2012, at 19:28, Yo-Yo Ma wrote: > This is because the context manager returns control after dispatch is called, > but the lazy response isn't rendered to a string until later on Hello, This behavior isn't specific to `timezone.override`. It would also happen with other context

Re: Test suite for session backend

2012/5/2 jgc31416 : > I am new to Django development and I would like to know if there is a test > for the session backend Hi, The tests for django.contrib.sessions are in django/contrib/sessions/tests/ Best regards, -- Aymeric. -- You received this message because you

Re: Multi-tenant Django

Hi Alec, This is tracked in https://code.djangoproject.com/ticket/15089, isn't it? Best regards, -- Aymeric. Le 9 mai 2012 à 05:02, Alec Taylor a écrit : > Dear Django-developers, > > I've been using Django for a few months now, and recently—for > different

Re: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``

Hello, On 15 mai 2012, at 21:36, Yo-Yo Ma wrote: > I've attached a diff in the ticket I created, and I resolved the > ticket as "fixed" (as habit, I'm used to doing this for work, allowing > QA to change the status to "closed" after testing). Is this correct? We resolve tickets as "fixed" only

Re: Possible session key creation regression in 1.4

2012/5/16 Tom Evans : > So, is the session key being available part of the API, or is relying > on the session key existing incorrect? Hi Tom, Accessing the session key before saving the session is incorrect. Previously, it used to return something, but that something

Re: Possible session key creation regression in 1.4

Hi Tom, On 16 mai 2012, at 19:22, Tom Evans wrote: > Even with this optimization, if I access the session_key of a session > object, it should be apparent that I want the session id of the > current session. If that means that the session must be saved in order > to determine what that session id

Re: Possible session key creation regression in 1.4

Le 18 mai 2012 à 11:51, Tom Evans <tevans...@googlemail.com> a écrit : > On Wed, May 16, 2012 at 4:38 PM, Aymeric Augustin > <aymeric.augus...@polytechnique.org> wrote: >> 2012/5/16 Tom Evans <tevans...@googlemail.com>: >>> So, is the session key being a

Re: Possible session key creation regression in 1.4

Le 18 mai 2012 à 16:29, Tom Evans a écrit : > That may be fine for open source code, it's not appropriate here. Tom, I'm sorry, I can't follow your logic here. Also, given my experience in the area of sessions, I don't believe I could translate your requirements

Re: timezone.now() when USE_TZ=true

2012/6/1 Artem Andreev : > May be it will be more practical/comfortable for django users if > timezone.now() will return localetime? > What do you think about this? Hi Artem, In fact this problem isn't limited to timezone.now(): any datetime returned by the database will

Re: timezone.now() when USE_TZ=true

On 1 juin 2012, at 20:56, Artem Andreev wrote: > seems as a lot of systems expect datetime naive Yes, that's unfortunate. All hope is not lost. 10 years ago, lots of systems expected ASCII and choked on UTF-8; some have improved since then. > I should converts a lot of manually, which increases

Re: Django git guidelines

On 6 juin 2012, at 21:09, Anssi Kääriäinen wrote: > I am sure there is still a lot to polish. I might have tried to change > too big portion of the docs in one go. Still, I would like to commit > what I have tomorrow, so that the sprinters at djangocon have the > possibility to use the guidelines

Re: QuerySet refactoring

Hello Anssi, I'm familiar with the topic since I tried to review some of your refactoring patches (before you gained the ability to commit them yourself). I'm convinced that this refactoring is useful, because it is likely to fix some bugs, especially in features that were added to the ORM long

Re: When to close pull requests

Hi Anssi, That's pretty much the conclusion we reached when we discussed how to handle PRs at DjangoCon Europe (at least, if memory serves). When you review a pull request, you should either commit it or close it. -- Aymeric. On 15 juil. 2012, at 11:07, Anssi Kääriäinen wrote: > I am going

Re: Upcoming sprint to update Django's tutorial

2012/7/16 Jeremy Dunck : > On August 4, PyLadies SF will collaborate with Django sprinters in San > Francisco to improve the Django tutorial. Hi Jeremy, This is an excellent idea! Some people have worked on new tutorials but the patches weren't reviewed and committed. Groups of

Re: Django git guidelines

On 18 juil. 2012, at 11:46, Jeremy Dunck wrote: > I noticed this hasn't made it to master yet. Could it? I'm running > sprints and there's a bit of confusion on how to contribute to git. Hi Jeremy, This was committed. It's under Docs > How to get involved > Working with Git and GitHub.

Python 3: new coding guidelines

Hello, The core team decided to implement Python 3 support with a single codebase, unicode_literals, and six. (I don't think we ever announced it.) I've just pushed a series of changes that make Django's code base more compatible with Python 3. They are the first steps of a long path. The

Re: Python 3 port status

On 24 juil. 2012, at 19:43, Vinay Sajip wrote: > Since the update of Django to use Benjamin Peterson's six package for > single code-base compatibility, I've updated my port [1] to do > likewise. > [1] https://github.com/vsajip/django Hi Vinay, Since Django's test suite isn't exhaustive, we

Python 3 - style question

Hello, One of the first lessons in the tutorial is to define a __unicode__ method. In Python 3, __unicode__ is replaced by __str__ (and __str__ by __bytes__, but that method won't be needed in general). Writing these methods in a way works on both Python 2 and 3 proves surprisingly messy. I'd

Re: Python 3 - style question

On 11 août 2012, at 11:00, Aymeric Augustin wrote: > Thanks for all your answers. A decorator will indeed be the cleanest solution. Given the large number of existing __unicode__ methods (66 in django, 375 in the tests) I've written a custom 2to3 fixer to perform the transformation. ht

Re: Help review tickets, get a prize!

Hi everyone, The offer described below hasn't been used for some time, but it still stands! The unreviewed queue is quite high at the moment, so it's a good time to get your feet wet :) **tl;dr** Tickets: https://code.djangoproject.com/query?status=!closed=Unreviewed How to:

Python 3: should we apply unicode_literals everywhere?

Hello, The first steps of porting Django to Python 3 was to switch on unicode_literals, as explained here [1]. This change was discussed in ticket #18269 [2] and committed in changeset 4a103086d5 [3]. This changeset added `from __future__ import unicode_literals` only where necessary, ie. in

Re: Python 3: should we apply unicode_literals everywhere?

> 2012/8/22 VernonCole : > > On Tuesday, August 21, 2012 4:03:57 PM UTC-6, DrMeers wrote: >> >> It's a shame we couldn't skip straight to Python 3.3 and take >> advantage of PEP414... > > That seems to me (in my dark status as a lurker here) to be a brilliant > idea. Well,

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

Hi Tai, Thanks for your work and sorry for the late answer. I just had the time to review the discussion. In my opinion, option 2 is reasonable. I'm -0 on a stream_content keyword argument for HttpResponse. I +1 on adding a separate HttpStreamingResponse class, because it better reflects the

Backporting some Python 3 support features to 1.4.x?

Hello, Several people have started porting their apps for Python 3, but they're running into trouble when they try to support both Django 1.4 and master. They end up with regrettable patterns such as: try: from django.utils.six import PY3 except ImportError: PY3 = False Authors of

Re: Create a new Django object with 'using' kyword in multi database application

Hi Laxmikant, This is a question is about using Django; please post such questions to django-users. The topic of django-developers is the development of Django itself. Thanks! -- Aymeric. PS: look at database-level replication. Le 21 sept. 2012 à 09:11, Laxmikant Gurnalkar

Re: Logging Out with POST by Default?

Le 20 sept. 2012 à 20:03, Carl Meyer a écrit : > FWIW I agree, and I think #7989 should be reopened. I do logout-via-POST > on all my projects nowadays to avoid logout CSRF, and it's really quite > simple. You can easily style a form button to look however you want > (including

Re: Migration to Django 1.4.1 : nothing about auth.message in Backward incompatibilities CHANGELOG.

Hi Stanislas, Since the user message framework was deprecated in Django 1.2, its deprecation is documented in the 1.2 release notes: https://docs.djangoproject.com/en/1.4/releases/1.2/#user-messages-api The features deprecated in Django 1.2 and eventually removed in Django 1.4 are listed in

Re: Http handler may assign urlresolver-related data to request

Hi Benoît, Thanks for the suggestion. It's tracked in https://code.djangoproject.com/ticket/15695. This ticket hasn't seen much activity, but I've heard this feature request several times. I don't see much harm in adding the ResolverMatch as an attribute of the request. ResolverMatch is already

Re: django 1.3 google3 statics files not found

Hello, Please post questions about using Django to django-users. The topic of this list is the development of Django itself. Thanks! -- Aymeric. Le 28 sept. 2012 à 21:36, sandeez a écrit : > Hi I am newbie to django in google3 app engine. I am currently working on a >

Re: django.test.client.Client tests in Django development?

Le 30 sept. 2012 à 10:57, Mateusz Haligowski a écrit : > I wanted to contribute to Django and decided to fix #18998. Starting with > writing tests, is seems to me that the easiest to write and read the test > would be using django.test.client.Client tool (sessions and

Re: Optimization request - give ``request.session`` lazy read

2012/10/2 jdetaeye > > If the query is a problem for you that requires optimization, you're > probably better off using cookie-based sessions. Either that, or the cache backend. Sessions are the easiest thing to move out of the database when you have scaling

Re: URL dispatcher slow?

2012/10/10 Moonlight > Here is an article comparing various URL dispatchers: > > http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html > > What cause django URL dispatcher that much... slow? Django's URL dispatcher is more complex than others. It

Re: URL dispatcher slow?

2012/10/11 Tom Evans > Now that I've looked in detail at the test, it is because the test is > nonsensical. Each time it tests the URLs, it constructs a fresh WSGI > application. Each fresh application has to compile each URL in the > urlconf before using it. It then

Re: Update on localflavor move

Hi Adrian, Thanks for taking the lead on this! I reviewed related tickets in Trac and I have a few suggestions. 1) Can we move the fields defined in django.contrib.localflavor.generic.forms to django.forms? Currently the US-biased fields are in django.forms and the non-biased ones in

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

Hello, I've just written a (final?) proposal on the ticket: https://code.djangoproject.com/ticket/7581#comment:36 If you still want to weigh on this issue or issue a veto (there were several -1 over the last 4 years), now is the time. Otherwise I'll update the patch and try to commit it in

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

Hello, I just added StreamingHttpResponse and closed #7581. There've been many contributions to this ticket over the years; I committed the simplest thing that could possibly work. If I missed something important, please let me know. The yak shaving goes on with: -

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

Hello, While I'm working on HttpResponse, I'd like to resolve two related tickets. Here's my plan for discussion. #6527 is about normalizing how HttpResponse deals with iterators. For more background, see part 1 of the first email of this thread. Let's take an HttpResponse instantiated with

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

Le 22 oct. 2012 à 23:50, Aymeric Augustin <aymeric.augus...@polytechnique.org> a écrit : > There's encoding information available both in self._charset and in the > Content-Encoding header. I was confused — Content-Encoding is typically "gzip" of "defl

Re: How to test patch

We tried moving Django's CI to Travis about 6 months ago. Unfortunately, Travis' time limit is too low for Django's test suite. We contacted them, but as of August 6th, we were still waiting for them to increase the limit. I haven't had any news since then. Over the last months I've had mixed

Re: #16779 - a tutorial for first time Django contributors

Le 11 nov. 2012 à 06:53, Shai Berger a écrit : > On Sunday 11 November 2012, Tim Graham wrote: >> >> I think the part that has the most potential to confuse new contributors is >> the introduction of PYTHONPATH. Claude suggested we could simply instruct >> users to run the

Re: Django 1.5 release plans

The beta is released when there aren't any release blockers left, or when the remaining ones are considered sufficiently benign to be fixed later on. https://dashboard.djangoproject.com/metric/blockers/ -- Aymeric. -- You received this message because you are subscribed to the Google Groups

Re: GitHub migration

Hello, Django's development moved to GitHub 7 months ago, and it's a success! No guidelines for pull requests were published, but usage patterns have emerged. Here's what I've observed. 550 pull requests have been opened: - 20% of them are still open. This figure is a slightly above

Re: django.forms.DateTimeField and timezones

2012/11/27 Ion Scerbatiuc > The datetimes in the POST are created using timezone.now() (and I have > USE_TZ = True) > The POST data simulates the values entered by the user in the form. It should contain naive datetimes in local time. Actually, to be realistic, it should

Re: django.forms.DateTimeField and timezones

2012/11/27 Ion Scerbatiuc > Actually, to be realistic, it should contain strings representing naive >> date times, because that's what will be POST-ed by a HTML form. But using a >> datetime object works too. >> > > I'm not 100% sure that the datetimes received in the POST

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

2012/11/28 Gavin Wahl > I would like to avoid having two code paths, one with streaming and one > without, in new middleware. > Hi Gavin, Could you give an example of a middleware that: - needs to alter the content, - will work identically both on regular HttpResponses

Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

Hi Gavin, The whole point of the HttpStreamingResponse API to access the content is to be incompatible with HttpResponse. Otherwise it's too easy to consume streamed content accidentally. Re-introducing a common API ("streaming_content") would remove that benefit, it would be confusing in the

Blocker for 1.5 - representation of filesystem paths in Django

Hello, Django 1.5 beta 1 contains a regression for users who install Django or their projects under non-ASCII paths: https://code.djangoproject.com/ticket/19357 Unfortunately, the patch isn't going to be trivial. I'd like to have some feedback before making changes. In order to add

Re: Blocker for 1.5 - representation of filesystem paths in Django

Hi Russell, > I've had a look at the patches for (1) and (2), and to me, the look like > mirror images of the same patch -- it's just a matter of whether we convert > everything to bytes or unicode when we have the opportunity. > My immediate reaction is that (2) -- keeping everything in

Re: testing tutorial feedback needed! (was: Testing documentation)

Hi Tim, I just reviewed the online version at http://techytim.com/django/9962/intro/tutorial05.html and I found it very clear. Here are a few suggestions to make it even better. Some don't fit well in inline comments, so I wrote an email instead; I hope you don't mind. The "Why you need to

Re: testing tutorial feedback needed! (was: Testing documentation)

Le 1 déc. 2012 à 09:19, James Pic a écrit : > - would it be useful to mention that if the app lives in a separate (ie. open > source) repo, it will need the repo to contain a test_project to run > `./manage.py test theapp` in CI systems ? Yes, it's a good practice to

Re: Proposal: Django Admin Site and "pretty" app name

FYI the latest efforts on this topic are here: https://github.com/ptone/django/compare/app-loading http://code.djangoproject.com/ticket/3591 -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

SVG images in docs

Hello, Since all major browsers now support SVG [1], I've replaced two images in the docs with SVG versions [2] [3]. This isn't a new idea [4]. [1] http://caniuse.com/#feat=svg [2] https://docs.djangoproject.com/en/dev/topics/http/middleware/#hooks-and-application-order [3]

Charset for URL decoding (#19468)

Hello, #19468 sparked an interesting debate; Claude and I would like some feedback before making a decision. Here's a summary of the problem. Django must decode environ['PATH_INFO'] to obtain request.path, where decoding means : 1 - URL-decoding to a bytestring 2 - "charset-decoding" to an

Charset for URL decoding (#19468)

(complete version follows) Hello, I'm looking for some feedback on #19468 before making a decision. It's one of the tickets that currently block the 1.5 release. Here's a summary of the problem. Django must decode environ['PATH_INFO'] to obtain request.path, where decoding means : 1 -

Re: Charset for URL decoding (#19468)

2012/12/18 Karen Tracey > https://code.djangoproject.com/ticket/5738 > > Comment #10 notes that utf-8 is what Django will use but with the last fix > noted against that ticket it is easier for the request class to be > subclassed to change things for an installation where a

Re: Charset for URL decoding (#19468)

2012/12/18 Łukasz Rekucki > > I wonder if UTF-8 with "surrogates escape" error mode makes sense here. > Python 3 uses it for decoding file-system paths, where it's not always > possible to determine the charset. I think it's pretty much the same case. > After all, the

Request for review: removal of deprecated features for 1.6

Hello, Since we forked the 1.5.x branch from master when we released 1.5 alpha, we can work on 1.6 while we finalize 1.5. I've created a branch that removes all deprecated code. Here's a pull request for inline comments: https://github.com/django/django/pull/605 Specifically, I'd love a

Re: Django 1.5 release plans

2012/9/11 Jacob Kaplan-Moss > > Oct 1: Feature freeze, Django 1.5 alpha. > Nov 1: Django 1.5 beta. > Nov 26: Django 1.5 RC 1 > Dec 10: Django 1.5 RC 2 > Dec 17: Django 1.5 RC 3, if needed > Dec 24 (or earlier): Django 1.5 final > > (All dates are "week of" - we'll do the

Re: python_2_unicode_compatible pitfalls

Hi Mikhail, Thanks for your feedback! Your email touches many topics; can we try to extract the most important ones and identify what really needs fixing before the 1.5 release? > 1) @python_2_unicode_compatible doesn't handle __repr__. Indeed, this decorator isn't designed to handle __repr__ —

Re: python_2_unicode_compatible pitfalls

2012/12/28 Karen Tracey <kmtra...@gmail.com> > On Thu, Dec 27, 2012 at 7:15 PM, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > >> 2) under Python 2.x __str__ is implemented as __unicode__ >>encoded to utf8. >> >> >> Yes,

Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)

A modern Django project is a collection of apps. Files are looked up under conventional paths within apps. Modules (especially the settings module) can live anywhere on $PYTHONPATH. Actually, there's not such thing as a project root. For instance, instead of using TEMPLATE_DIRS, project-wide

Re: new contributor

Le 17 janv. 2013 à 16:00, Michael Lauria a écrit : > Hi, I'd like to get involved, but I have no idea where to start. Could anyone > suggest something? Thanks in advance. Hi Michael, The documentations contains a wealth of information about getting involved:

  1   2   3   4   5   6   7   8   9   10   >