Re: mark_safe(media) in django admin

On 14 nov. 2011, at 23:15, Ric wrote: > a minor bug in django admin. Could you open a ticket in our bug tracker? https://code.djangoproject.com/newticket Thanks, -- Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups "Django developers&qu

Re: add view_permission

maller issues and tackle this when you're more at ease with our development process. Best regards, -- Aymeric Augustin. On 16 nov. 2011, at 17:47, Ric wrote: > i've been thinking about a new django admin feature, that could be > backward implemented > > it's abou

Re: add view_permission

FreeNode. Thanks for your understanding! -- Aymeric Augustin. On 16 nov. 2011, at 20:51, Ric wrote: > at a first look, the big file to patch is django.contrib.admin.options > > i need also to add a method to django.db.models.options > > def get_view_permission(self): >

Re: models.IPAddressField not saved as NULL

2011/11/17 rihad > Probably this simple fix breaks some core design principle badly, and > that's why 17 months haven't been enough time to get it right? Come > on, this one can't be that harder than implementing multi-key PKs? :) Just read the comments and you'll see why the patch wasn't commi

Re: Request for review / Multiple time zone support for datetime representation

Hi Anssi, 2011/11/18 Anssi Kääriäinen > So, at least according to this simple test there is nothing to > worry about performance-wise. > Thanks for the performance tests! They were still on my TODO list. > This part of the documentation raises one question: > """ > Unfortunately, during DST

Re: Request for review / Multiple time zone support for datetime representation

2011/11/18 Anssi Kääriäinen > My point is that it would be very useful to know you are actually > using aware datetimes internally. Especially when migrating an old > project to use this feature, it is easy to miss some places that do > not use aware datetimes. And you might find it out when you

Re: Django 1.4 roadmap

.4 didn't get a formal roadmap. So it will contain the features currently listed in the release notes [1], plus those that will be added before the release. Best regards, -- Aymeric Augustin. [1] https://docs.djangoproject.com/en/dev/releases/1.4/ -- You received this message b

Re: Django 1.4 roadmap

On 28 nov. 2011, at 21:33, Adrian Holovaty wrote: > And that someone will be me. See my post here: > http://www.holovaty.com/writing/back-to-django/ Awesome! > Is there a list somewhere of what needs to get done? > If not, I can make it, but obviously it'd be great if that already existed. I d

Re: Django 1.4 roadmap

2011/11/29 Luke Plant > 2) Broken tests: > > http://ci.djangoproject.com/builds > > It looks like tests are failing on Oracle and spatialite. I guess any > failing tests need to be added to the release blockers. > I don't think there are any reproducible failures under Oracle: http://ci.djangopr

Re: Improving test data experience

y_boy, we've dropped all but the most trivial fixtures (sites, languages, an admin user), and we haven't looked back. Best regards, -- Aymeric Augustin -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this g

Re: Django-nonrel patches

On 3 déc. 2011, at 23:36, Jonas H. wrote: > On Jacob's suggestion in this thread [1] back in April, I split the diff > between Django trunk and Django-nonrel into logically separated patches. > > I uploaded most of them to the ticket tracker (a few things are still missing > but these are the mo

Re: Python 3 port - all PostgreSQL tests now pass on 2.7.2 and 3.2.2 with the same codebase

On 10 déc. 2011, at 09:03, Vinay Sajip wrote: > Is Oracle XE (Express Edition) a valid platform for Django's Oracle tests? Yes, it is. > Does anyone here have experience installing it on Ubuntu 64-bit? Yes, I documented the procedure here: https://code.djangoproject.com/wiki/OracleTestSetup wh

Django 1.4 alpha on December 22nd

Hey folks, We're planning to release the alpha for 1.4 on December 22nd. If you're working on non-trivial new features for 1.4, please try to make them ready for checkin by next weekend. Before you ask -- we're aiming for a beta early in February and final in March. Best regard

Re: Python 3 port - all Oracle tests (bar one) now pass on 2.7.2 and 3.2.2 with the same codebase

.backends: postgis, spatialite, mysql, oracle. Postgis isn't too hard to set up; spatialite is; I never tried to use GIS with MySQL or Oracle. Given that the tests pass on the non-GIS versions of these backends, I don't expect too many new problems on this front. Best regards, -- Aymeric

Re: Django 1.4 alpha on December 22nd

attempts to port popular third-party apps first. 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 unsubscribe from th

Re: #16630: Support for HTML5 input types

tation: - in the widgets reference; - in the release notes, under backwards-incompatible changes. 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 emai

What you can do to improve the upcoming 1.4 release

verything else is in your hands! If you're interested in contributing to Django, you'll find a wealth of information here: https://docs.djangoproject.com/en/dev/internals/contributing/ Finally, there are always a few core devs hanging out in #django-dev on FreeNode. If you have questio

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 report on that, woul

Re: "Current" timezone in admin

on't believe we can come up with a sufficiently generic 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,

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

h a smiley. 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

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 https://docs.djangoproject.com/e

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 this message bec

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 bet

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 h

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&severity=Release%20blocker 2 - RFC tickets -- unless they're new features: h

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 I'

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, he

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 foobar

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 timezones

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

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 somethi

Re: Converting aware datetimes in cursor adapters

Hi Anssi, On 22 févr. 2012, at 22:16, Anssi Kääriäinen wrote: > There was some short discussion in ticket #17728 about doing timezone > conversions for aware datetimes using cursor adapters. The design > decision was that it should not be done because conversions are > already done by field class

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 you

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 > Please go ahead, create a ticket and set its severity to "release blocker". > > Assuming a proper test was added

Re: Newline stripping in templates: the dnl way

2012/2/24 mjl Martin J. Laubach > For this (avoiding newlines) the currently discussed multiline > tags > would work pretty well too without adding more cruft to the template > language: > > foo bar {# > #}baz > > > Martin,

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 DateTimeField timestamp. > Inde

Re: USE_TZ related warnings caused by fixture loading

2012/3/1 Jacob Kaplan-Moss > 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 seeing that warni

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

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 beca

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 wrappers are needed is

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 t

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 RC, and it turns out those > pe

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 Pyt

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 to get this fix in 1.4

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 isn

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 an "improve error handling" G

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 feel your feedback is

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 advis

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

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 regressi

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 "Dj

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 instanc

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 some

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 rig

Re: Django use of stdlib HTMLParser "internals"

On 28 avr. 2012, at 00:49, Vinay Sajip wrote: > From the discussion on python-dev, it seems possible that an optimal > fix might require changes both in Python and in Django. Before > creating a ticket about this for Django, I would like to get an > opinion about this from the Django committers - s

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 int

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 manager

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 are subscribed to the

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 projects—started using the web-fr

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 on

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 could be random data instea

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 a écrit : > On Wed, May 16, 2012 at 4:38 PM, Aymeric Augustin > wrote: >> 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? >> >>

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 into a consistent, backwards c

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 be expressed with tzinfo

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 a

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 a

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 sprinters have a m

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

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 synta

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 focu

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

Hello, Thanks for all your answers. A decorator will indeed be the cleanest solution. This idea was suggested on IRC too but withdrawn because "you can't bind back to the class". Well, as far as I can tell, the code below works. Please let me know if you see any issues with this implementation.

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

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&stage=Unreviewed How to: https://docs

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 modu

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, this point is moot as f

Re: Yak shaving the test framework on the way to pluggable user models (#3011)

On 25 août 2012, at 10:15, Russell Keith-Magee wrote: > We *could* just mark the affected tests that require auth.User as > "skipUnless(user model == auth.User)", but that would mean some > projects would run the tests, and some wouldn't. That seems like an > odd inconsistency to me -- the tests e

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 plugga

Re: Backporting some Python 3 support features to 1.4.x?

Given the positive replies, I'll commit this patch (with suitable docs). Thank you all for your feedback. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com

Re: Is there any plan to improve the performance of "render"?

Le 12 sept. 2012 à 18:56, 富弘刘 a écrit : > I use django-debug-toolbar to analyze my website and noticed a lot of time is > consumed by template render. In my each page, I have about 10ms in database > queries, and about 100 ms in render. Hi Fuhong, Yes, the Django Template Language is known t

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 a écrit : >

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 just like a link),

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 the

Re: ``models.BooleanField`` fields default to ``False`` when missing from fixtures

2012/9/24 Yo-Yo Ma > This may be the intended behavior, but I couldn't find docs on it. My > recommendation would defer to "The Zen of Python" > > In the face of ambiguity, refuse the temptation to guess. > > I would rather see the typical IntegrityError: Problem installing > fixture... Hel

Re: ``models.BooleanField`` fields default to ``False`` when missing from fixtures

2012/9/24 Florian Apolloner > I don't see how that could corrupt stuff in the current situation, I'd > rather argue that fixing the bug will cause more issues since people > probably (I am sure I do) do unknowingly rely on the current behavior. As > such we will exercise caution here and won't co

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 a

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 > project and am using

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 stuff). Is it OK > to use

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 problems. -- Aymeric. -- You re

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 provides advances features such

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 destroys the application, and

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

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

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: - https://code.djangoproject.co

  1   2   3   4   5   6   7   8   9   10   >