Re: Switch to database-level autocommit

On 2 mars 2013, at 16:18, Shai Berger wrote: > -1. Make it easier (and cross-backend) to set db-level-autocommit on. Put the > setting for it in the default template for new projects. Don't change > existing > code from "fragile" to "subtly broken". This isn't simply about

Re: Switch to database-level autocommit

On 2 mars 2013, at 15:50, Shai Berger wrote: > There is an issue you seem to be ignoring: An "ORM Write" is, in many cases, > more than a single query against the backend. The most obvious example is > models with inheritance -- trying to do these with database-level

Re: Switch to database-level autocommit

On 1 mars 2013, at 14:38, Javier Guerra Giraldez <jav...@guerrag.com> wrote: > On Fri, Mar 1, 2013 at 7:48 AM, Aymeric Augustin > <aymeric.augus...@polytechnique.org> wrote: >> To alleviate the pain, Django commits after each ORM write. > > just curious: why is

Switch to database-level autocommit

Hello, I'd like to improve transactions handling in Django. The first step is the current emulation of autocommit with database-level autocommit. ** Rationale ** PEP249 says that any SQL query opens a transaction and that it's the application's job to commit (or rollback) changes. This model

Re: Database pooling vs. persistent connections

On 28 févr. 2013, at 22:05, Christophe Pettus wrote: > It would be helpful to have a backend method that performers the "restore > connection between uses" function, rather than just use connection.abort() > (of course, the default implementation can use that). For example,

Re: Database pooling vs. persistent connections

On 28 févr. 2013, at 20:09, David Cramer wrote: > Can we please change this so it defaults to off, and just document how to > turn it on and in what situations you should turn it on? > > In my opinion this default-on feature caters to a very specific audience, and > will

Persistent connections, take 2

Hello, I've integrated the feedback received on my initial proposal in a new pull request: https://github.com/django/django/pull/733 and I think it's ready for review. I'm just wondering if 10 minutes is a good default value for CONN_MAX_AGE. I chose it randomly. Would "unlimited" be better?

Re: first() and last(), earliest() and latest()

On 27 févr. 2013, at 23:34, Wim Feijen wrote: > Therefore, my proposal is, if we are going to implement the earliest and > latest method, we should definitely rename them to: first and latest. I believe that latest() was introduced with dates in mind, and then earliest()

Re: Moving from PIL to Pillow

On 27 févr. 2013, at 21:40, Marijonas Petrauskas wrote: > Why isn't Pillow the recommended Django image library yet? PIL has > been unmaintained for almost 3 years and has a number of annoying bugs > (e.g. fails to open some valid JPEG files, maybe has some security > issues

DatabaseError wrapping

Hello, A pre-requisite for persistent database connections in Django [1] is robust error handling, especially for transaction commits and rollbacks. Currently, Django wraps and re-raises database exceptions [2] raised by queries, but not those raised by transaction-related operations [3]. To fix

Re: How to post multiple items of complicated data?

Please ask usage question on django-users. This mailing list is dedicated to the development of Django itself. Thanks! -- Aymeric. On 24 févr. 2013, at 17:35, Onsite <1943@gmail.com> wrote: > Hi, > > I know how to post data to django. However, now I need to post multiple items > in

Re: Database pooling vs. persistent connections

Hi Shai, Thanks for compiling this list ! My answers below. > First -- the very mention of this topic reminded me of > https://code.djangoproject.com/ticket/9964, which was my pet bug for about > two > years. The point of that bug, though, was to make sure that transactions are > properly

Re: clarification of API backwards-compatibility policy

On 19 févr. 2013, at 22:56, Carl Meyer wrote: > I was just about to tell someone on IRC that Django's > backwards-compatibility policy only applies to documented methods and > attributes (which is how I'd always understood it), but when I actually > went to look at the

Re: Database pooling vs. persistent connections

On 19 févr. 2013, at 11:04, Anssi Kääriäinen wrote: > Maybe we need another setting for what to do in request.start. It does > seem somewhat likely that users could do SET SEARCH_PATH in middleware > to support multitenant setups for example, and expect that set to go >

Re: Database pooling vs. persistent connections

On 18 févr. 2013, at 23:30, Karen Tracey wrote: > Will persistent connections be able to ensure that "bad connections" (e.g. > those in state "current transaction is aborted, commands ignored until end of > transaction block") don't leak from one request to another? I'm

Re: Database pooling vs. persistent connections

On 18 févr. 2013, at 14:47, Jacob Kaplan-Moss wrote: > This fix represents a cheap and easy performance improvement. Let's get it in. After working on a few iterations of the patch, I have identified two problems worth discussing. Problem #1: Is it worth re-executing the

Re: Database pooling vs. persistent connections

On 18 févr. 2013, at 19:51, Michael wrote: > I was just alerted to this by the reopening of ticket #18135. My initial analysis is incomplete. I'll comment on the ticket in a few minutes. > I will argue, however, that the AWS use case is a reason we need this to be > an

Re: Database pooling vs. persistent connections

Le 17 févr. 2013 à 19:31, Anssi Kääriäinen a écrit : > I am not yet convinced that poolers implemented inside Django core are > necessary. In case I wasn't clear enough — I agree that Django core shouldn't provide connection pooling, because it'll be simplistic and

Database pooling vs. persistent connections

**tl;dr** I believe that persistent database connections are a good idea. Please prove me wrong :) Since I didn't know why the idea of adding a connection pooler to Django was rejected, I did some research before replying to the cx_Oracle SessionPooling thread. The best

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

Le 13 févr. 2013 à 20:54, Ian Kelly a écrit : > I only meant that the final SQL should use '0:00' instead of > 'UTC' to guard against databases that for whatever reason do not have > a UTC time zone definition, such as the one that I found. Otherwise > the query would

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

Le 12 févr. 2013 à 23:12, Ian Kelly a écrit : > On Tue, Feb 12, 2013 at 3:06 PM, Ian Kelly wrote: >> >> I encounter the same bug in Oracle 10g XE. I tried it also on an 11.2 >> database, and it seemed to work, but I ran into a different issue: >>

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

I spent the better part of the day struggling with Oracle and unsurprisingly nothing works :( Given this model: class Event(models.Model): dt = models.DateTimeField() I'm trying to implement this query with time zone support enabled: Event.objects.filter(dt__month=1) That's a

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

Le 1 nov. 2011 à 15:58, Aymeric Augustin <aymeric.augus...@polytechnique.org> a écrit : > > There is only one outstanding issue that I know of. `QuerySet.dates()` > operates in the database timezone, ie. UTC, while an end user would expect it > to take into account its

Re: TIMEZONE default

Alex' answer is correct — and "later on" is actually a few days ago :) UTC isn't a best practice as much as a country-agnostic practice. You're supposed to put your own time zone there. There are a few other discrepancies between global_settings.py and the default project template, notably

Maintenance on djangoproject.com tomorrow

Hi folks, We've scheduled maintenance operations on djangoproject.com tomorrow, starting at 09:00 UTC. The website and the docs may be temporarily unavailable. Please use the mirror of the docs at Read The Docs in the meantime: http://django.readthedocs.org/ Thanks, -- Aymeric. -- You

Re: ModelForms and the Rails input handling vulnerability

Le 4 févr. 2013 à 14:35, Luke Plant a écrit : > I like Alex Ogier's solution of a sentinel "__all__" flag. This would be > introduced for ModelForm and UpdateView using a deprecation process, so > that a form without one of 'fields' or 'exclude' will raise a >

Re: Internationalization not working

Please ask questions about using Django on django-users. The topic of this list is the development of Django itself. Thanks, -- Aymeric. Le 4 févr. 2013 à 07:35, Satendra Tiwari a écrit : > Hi all, > > Language translation is not working for me, I want translation

Re: cycle in nested loops

Hi Wim, Le 21 janv. 2013 à 18:01, Wim Feijen a écrit : > Actually, the current behaviour is not to reset between loops. Is that > intentional? Yes, this behavior is intentional. See Malcolm's comment (#4) on the ticket. > A patch to ticket 5908 adds a reset_cycle tag,

Re: Simplify the default project template

Le 31 janv. 2013 à 17:46, Josh Cartmell a écrit : > I think a little more explanation regarding it's unsuitability would > make it a lot less scary. In line with what you have done here it > might make sense to add a new section to the docs describing how to > make the

Re: Simplify the default project template

Hello, I took into account the feedback received here and on IRC (thanks everyone!) and I now have a branch ready for review: https://github.com/aaugustin/django/compare/simplify-project-template The commit messages give some hints about the reasoning behind each change. I'll be glad to

Simplify the default project template

Hello, I know I'm treading in contentious territory, but -- I figured I'd try anyway :) We regularly hear complaints about the default settings file. I've noticed the following patterns: 1) Beginners a) Frustration. They skim the comments, tweak the settings and it doesn't work as

Re: Ticket #17093 -- quarantine global state in django.template

Hi Christopher, Some feedback below. > 2. This package has two kinds of global state. The first one are global > attributes defined at module level of template package. These are > base.builtins, base.libraries, loader.template_source_loaders and > base.templatetags_modules. The second one

Re: A New Django Release Cycle

Le 25 janv. 2013 à 11:59, Abdullah Esmail a écrit : > I realize that it's hard to follow a release schedule like this especially > for open source software, but I believe it's very doable. I agree that it should be doable in theory, and I strongly support

Re: [New feature] What do you guys thinks about an automatizated ER model drawer?

Le 25 janv. 2013 à 03:15, Vitor Lima a écrit : > I was thinking in something like a feature to django-admin that will make an > automatic ER(entity-relationship) model of the entire database. Hi Vitor, In order to keep Django maintainable in the free time of

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:

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

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

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

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 -

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

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]

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

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

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

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: 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: 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: 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 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: #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: 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: 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: 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 :)

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

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

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,

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

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

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

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

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

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

<    5   6   7   8   9   10   11   >