Re: request for API review of streaming responses additions

Hello, 2015-09-07 10:00 GMT+02:00 Yann Fouillat : > First I will say that most of this pull request is a port of > https://github.com/django/django/pull/1037 which I ported more or less > blindly. > As far as I can tell, this previous PR was never discussed on django-developers. Someone threw th

Re: Making the test suite run faster

Le 8 sept. 2015 à 18:42, Michael Manfre a écrit : > > I agree with Shai. The database backend needs to be able to control this > feature. Yes, I'm implementing that. The feature will be opt-in for database backends. -- Aymeric. -- You received this message because you are subscribed to the

Re: Improving MSSQL and Azure SQL support on Django

Hi Tim, Thanks for sharing your experience! > On 13 sept. 2015, at 01:48, Tim Allen wrote: > We have a test suite performing table creates / destroys, basic CRUD > operations, stored procedure execution, and more against both pyodbc and > pymssql. > pymssql outperforms pyodbc significantly aga

Re: Concerns with new "libraries" template functionality

Hello, The situation is nowhere near as complicated as you make it sound. 1) Builtins: many applications or projects relied on the private `add_to_builtins` API in order not to have to {% load %} commonly used libraries in every template. The new “builtins” option provides a public API for thi

Re: Making max_length argument optional

Hi Aron, On 22 sept. 2015, at 03:12, Podrigal, Aron wrote: > And for your concern, there will be a MaxLengthValidator added to the > validators to validate the users input does not exceed the database backends > maximum length just like when you set max_length explicitly. This isn’t possible

Re: Making max_length argument optional

Hi Shai, On 22 sept. 2015, at 04:22, Shai Berger wrote: > I'd solve the "need to specify" issue by setting a default that is > intentionally smaller than the smallest (core) backend limitation, say 128. I would pick the highest value supported by all core backends (probably 255 for MySQL, unle

Re: Making max_length argument optional

On 22 sept. 2015, at 07:57, Podrigal, Aron wrote: > We will be using max_length=255 or 128 for the default as Shia proposed. > Would you mind giving a few hours for other contributors to react? I was asleep while you were having this discussion; not every contributor is hooked to django-develop

Re: Methodology for increasing the number of PBKDF2 iterations

> On 22 sept. 2015, at 19:22, Christophe Pettus wrote: > > Given that it is a unidirectional hash, I'm not sure how they *would* be > rehashed. If you have password hashed at 15 000 rounds and want 20 000, you do 5 000 rounds on the current hash. (I don’t know if Django does this.) -- Aymeri

Re: Methodology for increasing the number of PBKDF2 iterations

On 22 sept. 2015, at 21:21, Tim Graham wrote: > At this point, I'm inclined to continue with the 20-25% iterations increase > per release methodology we've been using unless someone wants to advocate for > one of the other proposals. I agree. -- Aymeric. -- You received this message bec

Re: Static type checking for public API

Hi John, In case that’s not clear from the answers above, your question roughly translates to “can you do dozens of hours of very boring work and increase your maintenance workload in the future for no discernible benefit to you, just because I ask?” There’s no way that could be met with a posi

Re: Proposal: --debug-sql option for management commands

> On 17 oct. 2015, at 10:19, Claude Paroz wrote: > > I like the idea. However, instead of monkey-patching the Django > CursorDebugWrapper like DDT is doing now, I'd rather see a solution where we > use dynamic logging configuration to output the SQL commands, if possible. Since the option wou

Re: Fellow Report - October 17, 2015

Thanks Tim! Having CI on Windows is great, all the more considering your reminder that new programmers often use Windows. I'm looking forward to Michael's proposal for the MSSQL roadmap. -- Aymeric. > Le 18 oct. 2015 à 02:36, Tim Graham a écrit : > > Report for week ending October 17, 2015:

Re: Fellow Report - October 17, 2015

2015-10-20 5:04 GMT+02:00 Michael Manfre : > My long term plan is to switch out ADO for replaceable ODBC and FreeTDS. > This may follow the current pattern Aymeric started when he created > django-pymssql, or have them both in django-mssql. For the record, django-sqlserver did that as well. In d

Re: should manage.py test run system checks?

2015-10-20 2:48 GMT+02:00 Tim Graham : > me: I'm of the opinion that running the system checks as part of the manage.py > test command should be opt-in (for example, by writing a test that > asserts the call_command('check') output is empty. For example, when > debugging a single test, it doesn't

Re: Should contrib.auth include support for 2fa out of the box?

On 26 oct. 2015, at 18:22, Tim Graham wrote: > What do you think? I would very much like Django to have 2FA out of the box. Let’s bring django.contrib.auth kicking and screaming into the 2010’s ;-) I even considered crowdfunding it but that didn’t go much beyond idle thoughts. -- Aymeric. --

Re: Django TestCase isolation: setUp vs setUpClass

Hello Samantha, As of Django 1.8 there is a built-in solution to this problem: https://docs.djangoproject.com/en/1.8/topics/testing/tools/#django.test.TestCase.setUpTestData Best regards, -- Aymer

Provide a way to pass kwargs when initializing the storage class

Hello, Currently the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings contain a dotted Python path to the storage class. The class is instantiated without any arguments. ** Problem ** This leads to three annoyances. 1) Third-party libraries like django-storages(-redux) need to provide a

Re: Provide a way to pass kwargs when initializing the storage class

> proposed two-tuples? > > > -- > Raphaël > > > On Sat, 7 Nov 2015 12:15:49 +0100 > Aymeric Augustin wrote: > >> Hello, >> >> Currently the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings >> contain a dotted Python path to the

Re: startproject values for STATICFILES_DIRS and TEMPLATES

Hello René, The current built-in projet template is designed to provide the minimal set of settings required for a functional admin and a good level of security. (A few months ago I would have just said "a functional admin", but a new setting was added since then.) As far as I can tell, the main

Technical board report - 1.8 release cycle

Hello, It recently occurred to the team that, in the interest of transparency and accountability, the technical board should publish a report on its activity at the end of each term. As a reminder, the technical board is a group of five people elected among the Django team who holds two prerog

Re: Technical board report - 1.8 release cycle

Sorry, I missed one discussion: 6bis. December 29th, 2014: accepting DEP 182 (Multiple Template Engines). Decision: yes. -- Aymeric. > On 10 nov. 2015, at 20:41, Aymeric Augustin > wrote: > > Hello, > > It recently occurred to the team that, in the interest o

Re: Form field labels change proposal

I’ve always been annoyed by having to define lower case model field labels and capitalized form field labels. Inconsistencies always creep in. I would like to see this suggestion implemented, if we can provide a decent upgrade story for Django users. -- Aymeric. > On 11 nov. 2015, at 16:59,

Re: removing redirect URLs for some really old Django releases

I hope anyone who still cares about these versions has their own copy… -- Aymeric. > On 17 nov. 2015, at 17:46, Tim Graham wrote: > > I wonder if anyone objects to removing some non-trivial logic to support old > download redirect URLs: > > https://github.com/django/djangoproject.com/pull/

Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

On 17 nov. 2015, at 18:00, Tim Graham wrote: > Do you think it's correct to make the change in Django itself? > https://github.com/django/django/pull/5676 > -- I didn't track down the > reason why this changed in Python. Per PEP 386, the standard

Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

Considering the information provided by Donald, it’s pretty clear to me that we should switch to rc as proposed by Tim. -- Aymeric. > On 18 nov. 2015, at 01:26, Tim Graham wrote: > > Thanks Donald, updating setuptools was the factor I missed, not Python 2 vs. > 3. > > On Tuesday, November

Re: manage.py test and uninstalled apps

Hello Claude, Generally speaking, you cannot safely use a model that isn't defined in an application that is in INSTALLED_APPS. Django raises a warning when you import such a model. This restriction prevents situations where relations between models aren't set up correctly. There’s a string of

Re: manage.py test and uninstalled apps

2015-11-19 8:27 GMT+01:00 Claude Paroz : > To be clear, I don't contest in any way that design choice. I understand > and approve it. > I'm just pointing to this unwanted side-effect, wondering if anyone has > ideas how to circumvent it, as I think it's a legitimate use case. > Ah, I misunderstoo

Re: "Project" vs "App"

Hello Thomas, Thanks for bringing this up. There’s definitely some room for improving the documentation — I know because I wrote it. In terms of organization, I’d rather discuss how each topic (settings, models, etc.) relates to projects and apps than talk first about projects, then about apps

Case-insensitive email as username

Hello, I spent a good part of today implementing what must be the most common scenario for custom user models: case-insensitive email as username. (Yes. This horse has been beaten to death. Multiple times.) Since it was the first time I implemented a custom user model from scratch by myself, I

Re: Case-insensitive email as username

2015-11-23 23:52 GMT+01:00 Carl Meyer : I've implemented the CITEXT-based solution a couple times; I think for a > PostgreSQL-based project it's the preferable option overall. > Perhaps we should add native support in contrib.postgres? I'm forseeing a small difficulty in terms of API. This is a

Re: Non-atomic migrations in Django?

I like the API as well. Surprisingly, I couldn't find a Trac ticket about this. -- Aymeric. 2015-11-24 16:39 GMT+01:00 Anssi Kääriäinen : > I don't see any problem with optional non-transactional migrations. So, +1 > for the idea and API. I haven't looked at the implementation, so no > comments

Re: Keep django/django-old GitHub repo?

The real question is — did anyone remember that it existed before Tim brought it up? I’m pretty sure we can drop it. (For the more recent community members, it’s a git mirror of the original svn repo that predated the conversion of the official repo to git. We kept it around when we migrated.)

Re: annoyance with Python 3.2 support in Django 1.8

2015-11-26 5:22 GMT+01:00 Asif Saifuddin : > Python 3.2 should be removed as if any one use py3 should use 3.3+ or > better the latest stable. > Hi Asif, Your email sounds like the answer is obvious. It doesn't show that you thought about the use cases, especially those you don't have yourself a

Re: annoyance with Python 3.2 support in Django 1.8

Hello Tim, Did you consider marking affected tests as expected failures on Python 3.2.6? I've done that on one of my projects which faced this exact issue (or a closely related one): https://github.com/aaugustin/myks-gallery/blob/master/gallery/test_admin.py#L199-L205 Best regards, -- Aymeric.

Re: Code styling around URL in 404 pages shown with DEBUG = True

Hello James, This sounds reasonable. I would avoid using “root directory” to describe an URL because there isn’t usually a mapping between directories and URLs in Django projects. -- Aymeric. > On 26 nov. 2015, at 23:44, James Lu wrote: > > When you get a 404 with DEBUG = True the URL sho

Re: is_authenticated as property

Django 1.8 worsens the situation significantly: {% if request.user.is_authenticated %} does the right thing in a Django template but is a security vulnerability in a Jinja2 template! We could implement a property that returns an object: - that is still callable, for backwards compatibility

Re: is_authenticated as property

2015-12-03 7:02 GMT+01:00 Josh Smeaton : > I think we should be asking.. why not? If there's not a good reason not > to, let's make it a callable and a property. > The original discussion dates back to 2008; back then I believe we were slightly more resistant to change, especially when it came to

Re: Validation of m2m

Hello Frederico, It appears that you're hitting the problem described in the "Avoid catching exceptions inside atomic!" warning on this page: https://docs.djangoproject.com/en/1.8/topics/db/transactions/#handling-exceptions-within-postgresql-transactions To obtain that sort of result, I suppose y

Re: ORM difficulties

Hello, > On 5 déc. 2015, at 10:28, Raphael Gaschignard wrote: > > A behaviour that exemplifies this is that > queryset.annotate(foo=thing).annotate(bar=other_thing) is not the same as > queryset.annotate(foo=thing, bar=other_thing) given certain things. This goes > against the intuitive int

Re: Proposal to merge django-csp into contrib

Hello Thomas, > On 5 déc. 2015, at 23:23, Thomas Grainger wrote: > > I think merging django-csp into contrib would be a good fix for > https://code.djangoproject.com/ticket/15727 > I took a look at the pull request. I understand that the “just

Re: Backporting ticket 25548 into 1.9.x

> On 6 déc. 2015, at 10:49, James Bennett wrote: > > Thoughts? I don’t think anyone ever prevented a core dev who wanted to backport a commit from doing so — unless it carried a risk of backwards incompatibility, which doesn’t appear to be the case here. -- Aymeric. -- You received this m

Technical board report - 1.9 release cycle

Hello, As promised, here's the report from April 1st to December 1st, 2015. Activity was even lower than during the 1.8 cycle, which is excellent. For the first time, the board was asked by a commiter to make a technical decision (item 5). 1. April 8th, 2015: adding Preston Timmons to the tea

Re: Make template caching a feature of the Django template engine

Hello, I would suggest to enable the cached template loader by default when DEBUG = False and no ‘loaders’ options is specified. This is technically backwards-incompatible, but: - people who don’t usually configure it will get a free performance boost in production - people who do will be able

Re: MOSS Award to Django

Hello, Unless I missed something, channels aren’t about websockets. They add asynchronous processing capabilities to Django. They aim at being compatible with any bidirectional protocol. Django should support common protocols out of the box and document a public API for third-party projects to

Re: MOSS Award to Django

> Le 12 déc. 2015 à 23:10, Mitar a écrit : > > I would be > completely OK by supporting Websockets now on the transport level, but > the API level should understand and support backpressure. Hello Mitar, Yes, I fully agree with this way to frame the topic. I'm don't know how this would manifes

Re: MOSS Award to Django

Hi Ben, Celery and channels don’t tackle the same problem. Celery is an asynchronous task queue. It is designed perform expensive work after responding to a HTTP request. At that point there is no possible communication with the browser. Channels is an asynchronous message framework. It enable

Re: Make template caching a feature of the Django template engine

On 18 déc. 2015, at 16:21, Tim Graham wrote: > Seems okay to me, but what about the point "It would also be useful to have > caching enabled in development so the template loading behaviour is (mostly) > the same in development as it is in production.” Would it be feasible to > always enable t

Re: [Question] MySQL Microseconds stripping

Hello, > On 19 déc. 2015, at 09:21, Erik Cederstrand wrote: > >> Den 19. dec. 2015 kl. 13.15 skrev Cristiano Coelho >> : >> >> The issue is that every datetime column created has no microseconds (since >> they were created with django 1.7, so it is actually a datetime(0) column) >> and I wou

Re: [Question] MySQL Microseconds stripping

2015-12-20 22:57 GMT+01:00 Cristiano Coelho : > Thanks for the suggestion, I think that work around might just add too > much code, so I'm probably going the way of converting every datetime > column of every table to datetime(6) and afford the extra storage (and > probably a little performance im

Re: FK constraints are not checked at the end of nested atomic blocks

Hello, When a question of "should Django do A or B here?" comes up, adding a setting to let the user choose is the last resort, because it's really a cop-out, not the default choice. Django explicitly creates FKs on PostgreSQL as DEFERRABLE INITIALLY DEFERRED in order not to check constraints unt

Re: FK constraints are not checked at the end of nested atomic blocks

2015-12-21 13:12 GMT+01:00 Anssi Kääriäinen : > The check_constraints operation is extremely expensive, and not suitable > for use at the end of savepoints. Ah. Too bad! -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributio

Re: A community Poll

Hello Curtis, 2015-12-21 14:52 GMT+01:00 Curtis : > So aside from the obvious "preventing circular imports", what other > benefits do people see? > I'm afraid this is an example of "worse is better". String references to other models in FK definitions are one of the remnants of "Django string m

Re: deprecate or undocument shorcuts.render_to_response()?

2015-12-22 18:34 GMT+01:00 Marc Tamlyn : > I'd be in favour of just undocumenting it for now. > I would be fine with either keeping it in the docs with a "you probably want render() instead" note or removing it from the docs. Then in a few years we can deprecate it. -- Aymeric. -- You receive

Re: structural & functional review of django documentation

On 27 déc. 2015, at 23:42, Tim Graham wrote: > In my view, Django's docs haven't strayed from the "topics", "reference", and > "how-to" division that we've had since 1.0 or so. I’ve been around for some time and, to be honest, I still have a hard time using this classification efficiently. > M

Re: Help needed with the MySQL max index length problem for Django 1.10

At that point, I'd prefer picking an arbitrary length that makes sense for the underlying data rather than one based on MySQL's current limitations. Name length sounds like an reasonable proxy for username length. A quick Google search turns up http://www.historyrundown.com/top-5-people-with-the-l

Re: delegating our static file serving

2015-12-31 12:52 GMT+01:00 Anssi Kääriäinen : > In my opinion one of the most important goals for Django is to make > deploying tiny projects securely and easily a trivial matter. We > aren't there right now. > +1 I'm maintaining three such sites (my wife's, my consultancy's and mine). I'm clear

Re: delegating our static file serving

Hello Collin, > On 31 déc. 2015, at 23:44, Collin Anderson wrote: > > I feel like the insecure flag could get renamed to inefficient or something > like that. This view is insecure for serving user-uploaded files, for reasons Florian hinted at. Browsers “helpfully” get a lot things wrong for

Re: structural & functional review of django documentation

On 2 janv. 2016, at 05:48, Doug Epling wrote: > First is, has been, a discussion open for spectators but limited participants > to core members. Asside from its subject pertaining current state and future > path, all other details are above my pay grade. Hi Doug, I’m afraid there’s a misunde

Re: RFC: new backports policy

s RFC. The backlog of unreviewing and uncommitted patches is quite discouraging. If this new policy helps core developers to review and commit patches faster, I'm also +1. Best regards, -- Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups "Dja

[5-for-1] Review request

Hello, I suggest we gather review requests on this thread to make the core devs' job easier (that is, until the thread becomes too long). I reviewed 5 new tickets: #15782, #15792, #15793, #15795, #15798. I'd like someone to take a look at #14091. Best regards, -- Aymeric Augustin

Re: [5-for-1] Review request

st a review of #15255, especially the second comment. Thanks! By the way, we're down to 6 unreviewed tickets. Not everyone claims his reviews :) -- Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post

"Contributing" docs

formation. - The small FAQ at the end should be merged in (1). This will result in a fairly large change so I'd like to hear your thoughts before working on this section of the documentation. Best regards, -- Aymeric Augustin. -- You received this message because you are subscribe

Re: [5-for-1] Review request

Hello, I would like a core dev's opinion on #11555. The tickets I reviewed are listed here: http://myks.org/stuff/django_5-for-1.txt Thanks, -- Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To pos

Ignorable 404s

e number of settings :) That new setting would behave a lot like DISALLOWED_USER_AGENTS. I am +1 on this suggestion, what do you think? Best regards, -- Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: pure sql fixtures for tests

r the structure or the data, it is complicated to make them work perfectly during the tests. Hence the current compromise. Best regards, -- Aymeric Augustin. On 8 mai 2011, at 18:14, Viktor Kojouharov wrote: > Hi, > > This is a bit of a continuation from this email in the othe

Re: Vote on {% include %} behaviour.

t as far as I can tell, it's only used during Django's own tests. This is also true for the reset() method of template loaders. If memoizing doesn't work — it's a bit crude — maybe we could extend this code to cache all template loading operations. Best regards, -- Aymeric

Re: Deprecation policy for IE6

2011/6/9 Idan Gazit > I'm looking at admin tickets, and I realize that some defined policy for > when we can safely start to break IE6 would be very helpful. > My vote is: "last year". Even Microsoft begs people to move away from IE6. I can't think of a context where people: a) can't upgrade

Re: Undocumented feature for INSTALLED_APPS settings

2 - like "from import *", it's not explicit, 3 - you don't add apps to your settings file every day, so there's little to gain. I think it should be deprecated; since it was never documented, we could even remove it outright. Best regards, -- Aymeric Augustin.

Re: Undocumented feature for INSTALLED_APPS settings

On 12 juin 2011, at 22:35, Aymeric Augustin wrote: > Hello, > > I checked the SVN history. This "feature" was never documented, even before > the reorganization at r8506. It appears in django/conf/__init__.py when > magic-removal is merged (r2809). > > We ju

Re: Undocumented feature for INSTALLED_APPS settings

ket/16247 Could someone review it? 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 this group, send email t

Re: WSGIRequest._stream.read() blocking

Hi Jonathan, Isn't this the same bug as <https://code.djangoproject.com/ticket/15785> and <https://code.djangoproject.com/ticket/15890>? Best regards, -- Aymeric Augustin. 2011/6/14 Jonathan Slenders > if I replace: > > > if type(socket._fileobject) is type

Re: Template Engine Compilation and Runtime Refactoring Progress

plains why. 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 this group, send email to django-developer

Admin inlines and fieldsets

. Reading Russell's closing comment, it looks like he had (1) in mind but not (2). Does the wontfix also apply to (2)? Best regards, -- Aymeric Augustin. [1] https://code.djangoproject.com/ticket/10938 -- You received this message because you are subscribed to the Google Groups "Django d

Re: Community page update

Hello, Thanks for the report. This problem has happened intermittently in the last few days. You can follow its resolution here: https://code.djangoproject.com/ticket/16339 Best regards, -- Aymeric Augustin. On 24 juin 2011, at 16:30, Thierry wrote: > The update for the community p

Re: Timezone-aware storage of DateTime

is in local time, an user can still enter an ambiguous datetime. That's unavoidable: an UI in UTC isn't acceptable for my end users, and neither is an "is_dst" checkbox. But all datetimes generated internally are correct, and that's the most important for me. Best regards,

Re: minify static files (css and js)

Hello, You're probably looking for: https://github.com/jezdez/django_compressor Best regards, -- Aymeric Augustin. On 7 août 2011, at 14:36, gert wrote: > Hi > > I have always wanted to minify my css and js but it never seemed like > the right time to do it. Someho

Multiple timezone support for datetime representation

Hello, The GSoC proposal "Multiple timezone support for datetime representation" wasn't picked up in 2011 and 2010. Although I'm not a student and the summer is over, I'd like to tackle this problem, and I would appreciate it very much if a core developer accepted to mentor me during this work,

Re: Multiple timezone support for datetime representation

Under PostgreSQL, I assume I have to use a TIMESTAMP WITH TIME ZONE and set the connection's timezone to UTC if I want non-Django applications using the same database to obtain correct results, regardless of their connection's timezone. To be honest, this is pure speculation; I must check

Re: Multiple timezone support for datetime representation

e timezone conversion helpers) available to anyone who has pytz, regardless of the value of USE_TZ, we could use this pattern: try: import pytz except ImportError: if settings.USE_TZ: raise -- Aymeric Augustin. -- You received this message because you are subscri

Re: PHP-inspired user-friendly in-browser DJango install

Hi Alec, Nothing prevents you from altering the settings file dynamically and telling the user to restart the webserver. You can run wih an in-memory SQLite database until this is done. So your question isn't related to the development of Django itself; it would be more appropriate on django-u

Check-in #1 / Multiple timezone support for datetime representation

and interpret naive datetimes in the timezone defined by settings.TIME_ZONE (instead of rejecting them outright). For this reason, I've decided to keep os.environ['TZ'] and time.tzset() even when USE_TZ is True. Best regards, -- Aymeric Augustin. On 3 sept. 2011, at 17:

Re: Should I split ticket #16502 in three tickets or not?

Hello, Yes, I think ticket #16502 should focus on the problem of CreateView: why doesn't it have a default template and does it need one? The other issues you discovered while investigating that problem should go into separate tickets. Best regards, -- Aymeric Augustin. On 15 sept.

Check-in #2 / Multiple timezone support for datetime representation

p)". The next step is to adjust these functions in DateFieldField, depending on the value of settings.USE_TZ. Best regards, -- Aymeric Augustin. On 11 sept. 2011, at 23:18, Aymeric Augustin wrote: > Hello, > > Given the positive feedback received here and on IRC, I've started

Re: Localization on User model

ki/SummerOfCode2011#Enhancedauth.user Unfortunately, this GSoC didn't happen this summer. The canonical ticket for this issue is https://code.djangoproject.com/ticket/3011 — there's a lot of background over there. Best regards, -- Aymeric Augustin. -- You received this message because you are su

Re: User.objects.active() support.

if you want more info. Hello, If I understand correctly, this is same idea as #16611. This feature was rejected by a core developer, which means it won't be added to Django. The rationale is explained in https://code.djangoproject.com/ticket/16611#comment:5 Thanks for the suggestion! --

Check-in #3 / Multiple timezone support for datetime representation

e. I'll mention all this in the release notes. Unrelatedly, I have switched the SQLite backend to supports_timezones = False, because it really doesn't make sense to write the UTC offset but ignore it when reading back the data. Best regards, -- Aymeric Augustin. On 17 sept. 201

Check-in #4 / Multiple timezone support for datetime representation

won't have much time for this project next week. See you in two weeks for the next check-in! Best regards, -- Aymeric Augustin. On 24 sept. 2011, at 15:24, Aymeric Augustin wrote: > Hello, > > This week, I've been working on a related topic that I had missed entirely in >

Re: Cleaning up manage.py and import paths

2011/10/11 Carl Meyer : > Unless there are significant objections, I'd like to commit this in the > next few days and get it into 1.4. I'll also modify the patch on #16360 > to take advantage of the new layout; hopefully that can get into 1.4 as > well. > > Let me know if you see something I've ove

Re: Having Django supporting IDEs represented at http://djangoproject.com/

2011/10/11 Alex Gaynor : > I hate to use the "w" word, but this seems infinitely better as a wikipage. I agree with Alex: I'd prefer if this information was community-managed. A quick search turns up: https://code.djangoproject.com/wiki/DjangoResources#Developmentenvironment https://code.djangopr

Check-in #5 / Multiple timezone support for datetime representation

ch for #16906 that I wanted to merge in my branch before further work, and fixed some related tickets (#16899, #16923, #4076). I've had other priorities since my last check-in; I hope I'll have more time for this project now. Best regards, -- Aymeric Augustin. On 2 oct. 2011, at

Re: Sane defaults for Startapp and Startproject

many of the points discussed in your proposal. I think that's the best solution to the question discussed here: "how should I organize my (first) Django project?" Best regards, -- Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups

Re: Sane defaults for Startapp and Startproject

have different settings in development and production anyway, and the overhead of changing TEMPLATE_DIRS/STATICFILES_DIRS is negligible. That's why I said it's a personal preference, maybe even an aesthetic matter :) Best regards, -- Aymeric Augustin. -- You received this message bec

i18n docs

t do you think? Have I missed something? 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, se

Re: Django CMS Developer

ropriate. -- 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-developers+unsubscr...@goo

Re: i18n docs

t's more consistent with the implementation too. > > .. _W3C Web Internationalization FAQ: > http://www.w3.org/International/questions/qa-i18n > .. _GNU gettext documentation: > http://www.gnu.org/software/gettext/manual/gettext.html#Concepts > .. _Wikipedia article: &g

Re: i18n docs

e process, I've proof-read all the i18n docs, edited them lightly, and removed some duplication (especially with the i18n howto). Given that I've moved files and chunks of text around, the result was hardly possible to review, so I committed it at r17026, after checking that I didn'

Check-in #6 / Multiple timezone support for datetime representation

_ZONE) and where it's better to use "current time zone" to interpret naive datetimes. Depending on the answer, I may have to make the model layer aware of the "current time zone". As usual, if you're curious: https://bitbucket.org/aaugustin/django/compare/..django/django

Re: Check-in #5 / Multiple timezone support for datetime representation

On 18 oct. 2011, at 14:48, Daniel Swarbrick wrote: > On Oct 16, 11:48 am, Aymeric Augustin > wrote: >> Hello, >> >> I've implemented the storage and retrieval of aware datetime objects in >> SQLite. This involved some refactoring, because SQLite returns dat

Re: Deploying Feature in manage.py

space; you can probably find one that will suit your needs. Thanks for the suggestion anyway! -- 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@googlegroup

Re: Clearing cache between tests (#11505)

Hi Jim, On 29 oct. 2011, at 19:07, Jim Dalton wrote: > I noticed that Aymeric Augustin committed a patch last week [17042] that > fixed some issues in the cache backends. Apparently the fact that the cache > carries over test to test remains a problem. Yes, while working on the cache

<    1   2   3   4   5   6   7   8   9   10   >