Re: Signature of the allow_migrate database router.

On 17 févr. 2015, at 11:06, Loïc Bistuer wrote: > The proposed fix for the release blocker > https://code.djangoproject.com/ticket/24351 suggests changing the signature > of the `allow_migrate` database router. > > From: > def allow_migrate(self, db, model): > > To: > def allow_migrate(self,

Re: Drop the TEMPLATE_DEBUG setting

Just to clear a possible confusion — that will still be possible, but you’ll have to do it differently once you start using the TEMPLATES setting: DEBUG = True TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'OPTIONS': { # ...

Re: Drop the TEMPLATE_DEBUG setting

2015-02-16 14:30 GMT+01:00 Collin Anderson : > Is there a reason to not always store the debug information? Performance? > Why have two behaviors? > Yes, I assume performance was the reason when this code was written, around 2005 or 2006. I can't say if performance is still a concern after 10 ye

Drop the TEMPLATE_DEBUG setting

Hello, During the multiple template engines refactor, I didn’t touch TEMPLATE_DEBUG. The only purpose of this setting is to control whether Django stores the information required to display stack traces for exceptions that occur while rendering Django templatse. I think I should have deprecated it

Re: discontinue shipping tests with contrib apps?

Hello, I find the flat structure in tests/ quite convenient, especially for making large changes, also in combination with shell globbing. Merging modeltests and regressiontests was a win. I'm not convinced a contrib folder would help much. Reserving foo_* for contrib app foo sounds sufficient

Re: Making the test suite run faster

On 7 févr. 2015, at 15:09, Fabio Caritas Barrionuevo da Luz wrote: > Parallel is different than concurrent Of course. I’m concerned with parallelism here because that’s what gives the performance improvement. Of course I have to make concurrency safe. > did you come to look at the package "te

Re: Making the test suite run faster

On 7 févr. 2015, at 01:02, Russell Keith-Magee wrote: > I've thought about (but never done anything) about this problem in the past - > my thought for this problem was to use multiple test databases, so you have > isolation. Yes this means you need to do more manual setup (createdb > test_data

Making the test suite run faster

Hello, As the test suite is growing, it’s getting slower. I’ve tried to make it faster by running tests in parallel. The current state of my experiment is here: https://github.com/django/django/pull/4063 I’m distributing the tests to workers with t

Re: CSRF REASON_NO_REFERER with meta referrer tags

Le 4 févr. 2015 à 03:31, Jon Dufresne a écrit : > > Prevent the application from being served in an attacker's iframe: use > X-Frame-Options. (Supported by all major browsers [1]) That's irrelevant in the scenario we're discussing here. The iframe Paul talks about would be injected by a MITM. I

Re: CSRF REASON_NO_REFERER with meta referrer tags

Le 3 févr. 2015 à 16:44, Jon Dufresne a écrit : > > However some URLs are accessed by a unique URL > containing a nonce without a login. Login is not an option for these > URLs. Sharing this URL is considered very bad and I would like to > avoid it happening unintentionally. You can fix that pro

Re: CSRF REASON_NO_REFERER with meta referrer tags

Le 3 févr. 2015 à 16:54, Jon Dufresne a écrit : > Assuming this MITM already has the correct CSRF value, what is > stopping this MITM from adding a REFERER to the HTTPS request? While MITM of HTTP is trivial, MITM of HTTPS isn't possible (under Django's security model, which doesn't account for

Re: CSRF REASON_NO_REFERER with meta referrer tags

2015-02-03 13:10 GMT+01:00 Tim Chase : > On 2015-02-03 10:31, Aymeric Augustin wrote: > > Your request boils down to "make Django's CSRF protection of HTTPS > > pages vulnerable to MITM attacks" which isn't acceptable. > > If you've got a MITM th

Re: Middleware+Transactions:

Hi Thomas, Both ways had advantages and drawbacks. Eventually I chose to include only the view function in the transaction for the following reasons. 1) Django never made any guarantees about which process_* methods of middleware would be called. Therefore every middleware must implemented defens

Re: CSRF REASON_NO_REFERER with meta referrer tags

Hi Jon, Your request boils down to "make Django's CSRF protection of HTTPS pages vulnerable to MITM attacks" which isn't acceptable. Of cours, if that's a tradeoff you want to make, you can make your own version of CsrfViewMiddleware and put it in MIDDLEWARE_CLASSES. 2015-02-03 2:35 GMT+01:00 J

Re: Feature proposal: Conditional block tags

On 31 janv. 2015, at 22:12, Raphael Michel wrote: > What is the technical reason for {% if … %}{% block %} not being > possible (or, not behaving as expected)? I suspect it has to do with {% if %} being interpreted at runtime while {% block %} is interpreted at compile time. I never investigated

Re: Feature proposal: Conditional block tags

Hello, That’s a rather specialized behavior for the general purpose {% block %} tag. I’m not convinced that building in such specialized behavior beats composing blocks i.e. handling the condition with a {% if %} tag. The Django template language has way too much ad-hoc, inconsistent syntax in

Re: automated import sorting and better pull request checks

Hi Tim, Good idea. There are so many changes on PR 4009 that I couldn't check if you wrote a .isort.cfg. Did you, or are you just using the defaults? -- Aymeric. 2015-01-29 14:18 GMT+01:00 Tim Graham : > As a code reviewer, I've really appreciated that we've cleaned up the code > using flake8

Multiple template engines for Django - retrospective

Hello, Here’s the final weekly update for this project: https://myks.org/en/multiple-template-engines-for-django/#2015-01-25 Huge thanks for everyone who helped me along the way! -- Aymeric. > On 18 janv. 2015, at 22:49, Aymeric Augustin > wrote: > > Hello, > > I publi

Re: Settings: lists or tuples?

As explained above and discussed on the #django-dev IRC channel, it's an acceptable choice to use tuples, even though it isn't the default Django chose. Please don't raise warnings or do anything else to discourage using tuples. Writing this patch consists in: - going though the 22 settings whose

Re: Settings: lists or tuples?

On 20 janv. 2015, at 18:52, Andreas Kahnert wrote: > But since you all seem to like lists that much, maybe a compromise would be > to explicitly note in the docs that there is a danger in using lists which > can be prevented by tuple usage. As explained in my previous email, tuples don’t help

Re: Settings: lists or tuples?

On 19 janv. 2015, at 21:13, Andreas Kahnert wrote: > I advertise that strongly against lists, because we actually had that kind of > issue in our company. Hi Andreas, This is probably obvious, but I thought I’d mention it just in case — you can keep using tuples in your projects. We’re just ta

Re: Multiple template engines for Django - week 13

Hello, I published my update for week 15: https://myks.org/en/multiple-template-engines-for-django/#2015-01-18 -- Aymeric. > On 11 janv. 2015, at 00:02, Aymeric Augustin > wrote: > > Hello, > > Here’s episode 14: > https://myks.org/en/multiple-template-engines-f

Re: Formalizing template loader and debug api's

Hi Preston, On 14 janv. 2015, at 20:43, Preston Timmons wrote: > As a quick recap: > > First, this branch uses origins everywhere: for extends history, for > TemplateDoesNotExist errors, etc. There's no more 4-tuple of statuses. Good. > Second, I use these attributes on the origin: > > engin

Re: Django documentation doesn't show correctly in any browser

Hi Some Developer, On 13 janv. 2015, at 20:15, Some Developer wrote: > Any suggestions? Until this gets resolved, you can use http://django.readthedocs.org/en/latest/ which still has the previous CSS (for the time being). > I'm pretty sure I can't be the only one who is having issues. Well, t

Re: Replace decimal prefix(kB) with binary prefix (KiB) for bytes

In that case I believe it's more important to be understandable by our target audience than to be technically correct. If we make the change we'll probably get bug reports pointing out KiB as a typo. I know that geeks love to feel smart by being more correct than the masses, so I expect this ch

Re: simplifying the default template context_processors

> Le 12 janv. 2015 à 05:25, Russell Keith-Magee a > écrit : > > For more irony - the removal of TEMPLATE_CONTEXT_PROCESSORS was the one that > bugged me most from the original template cleanup :-) In hindsight it was a mistake. -- Aymeric. -- You received this message because you are subsc

Re: simplifying the default template context_processors

On 11 janv. 2015, at 09:43, Russell Keith-Magee wrote: > However, I'd still have some concerns about a project template that took out > all the "useful" utilities, and required users to remember the exact spelling > of half a dozen builtins to have functionality that would have historically >

Re: simplifying the default template context_processors

On 11 janv. 2015, at 06:20, Russell Keith-Magee wrote: > TEMPLATE_CONTEXT_PROCESSORS isn't in the project template at present; it is a > default value inherited from global settings > (…) > ISTM that we can't pare that down with just auth and request without having > some pretty profound conseq

Re: Multiple template engines for Django - week 13

Hello, Here’s episode 14: https://myks.org/en/multiple-template-engines-for-django/#2015-01-11 Hopefully I’ll reach the point where I don’t have enough material to write a weekly update by the end of February :-) -- Aymeric. > On 4 janv. 2015, at 00:23, Aymeric Augustin >

Re: Multiple template engines for Django - week 13

On 4 janv. 2015, at 22:09, Tim Graham wrote: > > I don't think it's fair to put pressure on Aymeric like that. My throughput on this project has been rather stable. There’s only so much I can do by next week. Pressure won’t add hours to my days anyway ;-) As a consequence I don’t want to weigh i

Multiple template engines for Django - week 13

early 2016. -- Aymeric. > On 27 déc. 2014, at 23:59, Aymeric Augustin > wrote: > > Hello, > > My twelfth update is online: > https://myks.org/en/multiple-template-engines-for-django/#2014-12-28 > > It comes with a question — should I drop `select_template` fr

Re: permissions and groups data migration

Hi Adam, Migrations build a fake app registry containing fake app configs for each state of the models. They implement a small subset of features of the real app configs. See https://github.com/django/django/blob/5e32605/django/db/migrations/state.py#L119-L131 That’s why my_app_config.models_

Re: Formalizing template loader and debug api's

2014-12-29 4:53 GMT+01:00 Preston Timmons : > Did that explain it better? If not, I can try again. :) > Yes, I understand better now. The debugging information is two dimensional data: for each level of template extending, for each template loader, you have one entry — entries are 4-uples in you

Re: intended security model for templates

2014-12-29 0:26 GMT+01:00 Curtis Maloney : > I certainly like the idea of making public the API to load your tag lib by > default for your project. It's there, it's clean, and it's been stable for > a looong time. Of course, the multi-template-engine work may change this. It doesn't. Template

Re: Formalizing template loader and debug api's

Hi Preston, Thanks for working on this ticket — and for bearing with my changes :-) > On 28 déc. 2014, at 06:30, Preston Timmons wrote: > > ## 1. Add new template loader apis > > I tried to solve this patch without changing the template loader apis, but I > eventually decided this was inevitab

Re: Multiple template engines for Django - week 12

Hi Michael, > On 28 déc. 2014, at 07:12, Michael Manfre wrote: > > If I'm understanding your post correctly, any potential performance > improvement that a special cased select_template would have would likely be > negated by caching. Sorry, I didn’t explain sufficiently clearly. My reasoning

Multiple template engines for Django - week 12

On 20 déc. 2014, at 23:57, Aymeric Augustin > wrote: > > Hello, > > I haven’t written to this mailing-list for three weeks because nothing > warranted your immediate attention. > > Now the code is in reasonably good shape. Feel free to have a look: > https://githu

Re: Delivering PR 3114 - The _meta refactor

Hi Russell, 2014-12-22 8:39 GMT+01:00 Russell Keith-Magee : > The question: Do we - > > 1) Accept this particular internal specific naming of GFK as a quirk > reflecting the limitations of contrib.admin > > 2) Try to nail down what a "virtual" field means, or find some alternative > flag to ident

Re: Multiple template engines for Django - week 11

days. Updates for weeks 9 to 11 are available at the usual location: https://github.com/aaugustin/django/commits/multiple-template-engines -- Aymeric. > On 30 nov. 2014, at 10:37, Aymeric Augustin > wrote: > > Hello, > > Here’s my eight update — this is getting repe

Re: Migrations in Django 1.7 make unit testing models harder

There's django-admin test --keepdb for this purpose (in Django 1.8). -- Aymeric. > Le 20 déc. 2014 à 18:41, Bernard Sumption a écrit : > > A proposition: the problem isn't that migrations take 80 seconds, it's that > this 80 seconds is repeated every time a developer runs tests. How about >

Re: Settings: lists or tuples?

On 17 déc. 2014, at 21:54, Carl Meyer wrote: > So I think there is a backwards-compatibility issue. Indeed. > Personally, I would love to decide to just bite this bullet and > normalize to lists, but I think it would need to be marked as a > backwards-incompatibility in the release notes, and i

Settings: lists or tuples?

Hello, I’m about to introduce a new setting that is a sequence of things, TEMPLATES, and I have to decide whether it will be a tuple of a list. Unfortunately Django is very inconsistent in the type of settings. In global_settings.py: - 22 settings are tuples - 10 are empty, 12 aren't

Re: Experimental APIs DEP

On 6 déc. 2014, at 10:05, Carl Meyer wrote: > As the DEP notes, our backwards-compatibility policy already includes a > longstanding carve-out for anything documented within the "internals" > section of the docs. We haven't made much use of this for documenting > actual internal APIs (most of tha

Re: delegating our static file serving

Yes, I support this plan. "Serve your files with nginx!" doesn't fly in the age of PaaS. Serving static files with Django and having a CDN cache them is a reasonable setup as far as I know. I don't know if the "probably insecure" argument still holds. Are there some specific security risks in se

Multiple template engines for Django - week 8

Hello, Here’s my eight update — this is getting repetitive :-) https://myks.org/en/multiple-template-engines-for-django/#2014-11-30 -- Aymeric. > On 23 nov. 2014, at 00:02, Aymeric Augustin > wrote: > > Hello, > > I published my seventh update: > https://myks.org

Re: does django-admin need a man page?

Le 26 nov. 2014 à 01:51, Nick Phillips a écrit : > > I'd suggest considering implementing > something to generate a man page from whatever you wish the "canonical" > source of the information to be. The canonical source of information is: https://docs.djangoproject.com/en/dev/ref/django-admin/

Multiple template engines for Django - week 7

es that make sense regardless of the > Multiple Template Engines Project in small batches, in order to minimize the > size of the final pull request. > > -- > Aymeric. > > > >> On 9 nov. 2014, at 22:05, Aymeric Augustin >> wrote: >> >> Hello,

Re: Configurable safety options for high performance Django systems

I've had to implement workarounds for such problems in many Django projects I created. For example I wrote code to determine which models have too many instances for dumping them all into a HTML dropdown and automatically add this model to raw_id_fields in related models. The main difficulty I'm f

Re: Supported Python versions in future Django versions

2014-11-18 11:53 GMT+01:00 Some Developer : Are there any stats available for market share of the various versions of > Python 3? If Python 3.3 has a similarly small market share you could drop > that as well and start with Python 3.4 which is the first version of Python > 3 I have felt was good e

Re: Request for removal: Mysql warnings get promoted to Exceptions in debug mode

2014-11-17 10:45 GMT+01:00 Florian Apolloner : > Imo we should make those exceptions instead! Data truncation should never > be just a warning ;) > Those who think like you can use a database instead of MySQL ;-) I agree we should simply remove the code that promotes warnings to exceptions in DE

Re: Multiple template engines for Django - week 5

in small batches, in order to minimize the size of the final pull request. -- Aymeric. > On 9 nov. 2014, at 22:05, Aymeric Augustin > wrote: > > Hello, > > Here’s my fifth update: > https://myks.org/en/multiple-template-engines-for-django/#2014-11-09 > > The f

Re: Multiple template engines for Django - week 1

> On 4 nov. 2014, at 21:38, Aymeric Augustin > wrote: > > 2014-11-04 20:58 GMT+01:00 Preston Timmons <mailto:prestontimm...@gmail.com>>: > With the new template update, do you foresee > django.utils.setup_test_template_loader and > django.utils.restore_template_

Supported Python versions in future Django versions

Hello, The Django team has been discussing the timeline for dropping support for older Python versions. The current consensus is: - Support Python 2.x until the LTS version after 1.8, which should be released late 2017 or early 2018 and supported until 2020, when official support for Python 2

Re: 1.8 release planning

Hello, This timeline was discussed by the core team today at Django under the Hood and approved. The support period for Django 1.4 will extend for six months after the release of Django 1.8. The recommended way to migrate from 1.4 to 1.8 is to go through 1.5, 1.6, and 1.7. I encourage you to

Re: Explicit relative imports

.registry import apps # NOQA > > from https://github.com/django/django/blob/master/django/apps/__init__.py > > On Tuesday, November 11, 2014 1:51:19 PM UTC-8, Aymeric Augustin wrote: >> >> Hello, >> >> We’ve started using explicit relative imports in newer part

Explicit relative imports

Hello, We’ve started using explicit relative imports in newer parts of the Django source tree. They’re short and readable. That’s good. I would like to add guidelines about imports in the coding style guide in order to improve consistency. My inclination would be to recommend relative imports

Running flake8 on pull requests

Hello, Since we started using flake8, we made many small commits to fix glitches. Would it be possible to run flake8 on Jenkins when testing pull requests? I think that would help. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers

Multiple template engines for Django - week 5

Hello, Here’s my fifth update: https://myks.org/en/multiple-template-engines-for-django/#2014-11-09 The first step of my project, as outlined in my original proposal, is complete. -- Aymeric. > On 1 nov. 2014, at 23:30, Aymeric Augustin > wrote: > > Hello, > > I’m hap

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Hi Preston, On 7 nov. 2014, at 18:51, Preston Timmons wrote: > First, if multiple engines are configured, how do you see the error being > displayed if a template isn't found in any of them? Currently, this > originates from the template loaders. For instance, the filesystem loader > raises a

Re: Multiple template engines for Django - week 4 - DEP ready for review!

> On 6 nov. 2014, at 01:31, Carl Meyer wrote: > > Seeing the `OrderedDict` syntax in the example in the latest PEP update > made me sad. I’m convinced. I had an interesting idea for NAME. It can default to the name of the engine. Then only people who configure more than one instance of a given

Re: Multiple template engines for Django - week 4 - DEP ready for review!

> On 5 nov. 2014, at 09:42, Aymeric Augustin > wrote: > > I'll let you know when I have a specification ready for review. I just pushed an implementation plan for shortcuts and template responses. Search for `render(request, template_name` in the DEP or look at the

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Hi Collin, 2014-11-05 3:21 GMT+01:00 Collin Anderson : > On Tuesday, 4 November 2014 17:30:27 UTC-5, Aymeric Augustin wrote: > I suspect the only reason why it isn't is to avoid changing the default >> settings (django.conf.global_settings). >> > Right. Can we uncomment

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Hi Carl, 2014-11-05 0:02 GMT+01:00 Carl Meyer : I can imagine a scenario where I am > implementing a specialized project-specific template backend (for some > reason - let's hand-wave past this), and it would feel extraneous to be > forced to name an app sub-directory that I plan to never use. >

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Hi Marc, 2014-11-04 13:09 GMT+01:00 Marc Tamlyn : > > It would be preferable to have the backend configuration outside of > `django.template`. `django.templating` seems reasonable, but even > `django.template_backends` might be appropriate as it only contains > backends. > See my answer to Carl's

Re: Multiple template engines for Django - week 4 - DEP ready for review!

2014-11-04 14:45 GMT+01:00 Collin Anderson : > That makes sense, though, is it just me or is CONTEXT_PROCESSORS a fairly > frequently configured setting? My main use case is to enable the request > context processor. > In my opinion the request context processor should be enabled by default. I s

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Hi Carl, Thank you very much for the thorough review! Most of your comments are in line with my thinking and only require clarifications in the DEP. Tomorrow I'll proof-read and push what I've written tonight. I'm answering on a few items below. Everything else I agree with :-) 2014-11-03 19:47

Re: Multiple template engines for Django - week 1

Hi Preston, 2014-11-04 20:58 GMT+01:00 Preston Timmons : > With the new template update, do you foresee > django.utils.setup_test_template_loader and > django.utils.restore_template_loaders still working? > This is a good question. To be honest, I had filed it under "implementation details I'll

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Hi Collin, It’s exactly the right time to discuss APIs :-) After pondering your proposal, I'm still +0 on consistency with DATABASES and CACHES, but I'll make that change if other people agree with you. Does anyone else have an opinion on this? Thanks, -- Aymeric. > On 3 nov. 2014, at 01:

Re: Multiple template engines for Django - week 4 - DEP ready for review!

> On 2 nov. 2014, at 00:53, Michael Manfre wrote: > > Overall the DEP looks really good. Thanks! > It's currently assumed that BaseEngine.select_template() will scan the list > in order and return the first one it can load, but it might make sense to > explicitly state that in the DEP. I’ve

Multiple template engines for Django - week 4 - DEP ready for review!

): https://myks.org/en/multiple-template-engines-for-django/#2014-11-02 I’m looking forward to your feedback! -- Aymeric. > On 26 oct. 2014, at 22:36, Aymeric Augustin > wrote: > > Hello, > > I just published the third update: > https://myks.org/en/multiple-template-engine

Re: Websockets... again

Then the first step is to throw away the ORM. See my talk at DjangoCon US 2013 for details. -- Aymeric. > Le 28 oct. 2014 à 23:36, Marco Paolini a écrit : > > What if we do it with asyncio? > > 2014-10-28 22:47 GMT+01:00 Aymeric Augustin > : >> No, there isn

Re: Websockets... again

No, there isn’t. I assume that “including in core” means at least “making usable in combination with WSGI and with the ORM”. Even if we disregard for a minute the fact that WSGI is incompatible with websockets, the ORM is a hard problem, because current solutions involve either (a) threads — n

Multiple template engines for Django - week 3

Hello, I just published the third update: https://myks.org/en/multiple-template-engines-for-django/#2014-10-26 -- Aymeric. > On 19 oct. 2014, at 00:09, Aymeric Augustin > wrote: > > Hello, > > Here's the second update: > https://myks.org/en/multiple-template-e

Multiple template engines for Django - week 2

Hello, Here's the second update: https://myks.org/en/multiple-template-engines-for-django/#2014-10-19 Best, -- Aymeric. On 12 oct. 2014, at 20:31, Aymeric Augustin wrote: > Hello, > > I just posted the first update on this project: > https://myks.org/en/multiple-tem

Re: Multiple template engines for Django - week 1

Hi Anssi, On 17 oct. 2014, at 14:49, Anssi Kääriäinen wrote: > The FAQ section says that template context processors isn't going to be > supported for context processors. Indeed, at this time, my theoretical position is not to enforce such an API and leave it up to template engines. But I may

Multiple template engines for Django - week 1

Hello, I just posted the first update on this project: https://myks.org/en/multiple-template-engines-for-django/#2014-10-12 My work in progress on the DEP is available here: https://myks.org/en/multiple-template-engines-for-django/dep/ Feedback is welcome, especially on sections I've described a

Re: Storage engine aliases?

On 2 oct. 2014, at 09:36, Curtis Maloney wrote: > I tend to characterise them as : > > static -- What is an integral part of your site. What you keep in source > control, and is required for the site to function. > > media -- what happens as a result of your site functioning. I have two shor

Re: Built-in support for Jinja2 in Django

On 2 oct. 2014, at 14:35, Josh Smeaton wrote: > - The pluggable solution works well when you have a common interface, but a > different implementation in the backend. Have you thought about how to > support differences in syntax (interface) between various templating > libraries? Yes, I have.

Built-in support for Jinja2 in Django

Hello, I've been thinking about providing built-in support for Jinja2 in Django. I found that supporting pluggable template engines, like Django does for databases, caches, etc. would be the most elegant solution. The best summary I have at this time is on the crowdfunding campaign's page: htt

Re: Transaction management and atomic

2014-10-01 9:21 GMT+02:00 Florian Apolloner : > Imo, this is mainly useful to rollback if no error occurred! The other use > of this feature might work but is quite dangerous imo. > If you really know what you are doing, it might be possible to use it safely while taking advantage of a database's

Re: Storage engine aliases?

Hi Jeremy, That could be useful for any website that gets some of its assets from the code (JS, CSS), others from a CDN (eg. product photos), others from another CDN (eg. tutorial illustrations), etc. However we'd have to make sure it beats the common solution of having a model instance for eac

Re: RFC: "UPSERT" in PostgreSQL

On 28 sept. 2014, at 19:57, Simon Riggs wrote: >> 1) The django-developers mailing list isn't the place to rehash the debate, >> 2) The disparaging vocabulary you're using isn't acceptable in this forum, >> 3) Personal attacks based on prejudice will not be tolerated. > > Well, for 1) any commen

Re: RFC: "UPSERT" in PostgreSQL

On 28 sept. 2014, at 13:44, Petite Abeille wrote: > Again, your house, your choice. But it seems a bit self-indulgent to concoct > your very own take on MERGE, with baroque syntax, peculiar semantic, and all, > just because some abstract aspects of the MERGE specification is not to you > likin

Why is the CSRF template context processor hardcoded?

Hello, I'm wondering why django.template.context defines: # We need the CSRF processor no matter what the user has in their settings, # because otherwise it is a security vulnerability, and we can't afford to leave # this to human error or failure to read migration instructions. _builtin_context_

Re: Loading timezone naive data into your test database with USE_TZ = True

Hi Robert, On 17 sept. 2014, at 01:54, Robert Rollins wrote: > I have a legacy database from which my Django application must migrate data > into a Django database. The relevant dates fields are actually TIMESTAMP > columns in the database, but something (perhaps Django, or python's MySQL > d

Re: HTTP/2 and WSGI

2014-09-20 6:42 GMT+02:00 Russell Keith-Magee : > > Historically, Django hasn't been deeply involved in process of developing > WSGI and related standards; this is an opportunity for us to change that > trend. > To me the situation is pretty clear. Either this line will win: https://mail.python.o

Re: Loading timezone naive data into your test database with USE_TZ = True

2014-09-18 23:29 GMT+02:00 Wim Feijen : > Timezones confuse me, maybe Aymeric can answer this one if he has time? > I've bookmarked this thread to answer at some point but I have some work-related matters to deal with first. -- Aymeric. -- You received this message because you are subscribed

Re: a question about get_paginate_by method of django.views.generic.list.MultipleObjectMixin

Someone might want to return a different value depending on the queryset, especially depending on queryset.count(). -- Aymeric. On 14 sept. 2014, at 12:17, younger.shen wrote: > hi everyone: > > I write a mixin so i check the inner mixins of django itself, and find this > > def get_pagin

Re: Unifying locale time formats

While there are some backwards compatibility concerns, I believe option 1 is better: - It provides consistency out-of-the-box for international websites. - It makes the default behavior more reasonable in general. -- Aymeric. 2014-09-10 17:56 GMT+02:00 Malte : > Hi! > > I recently contributed

Re: Two proposals for the Django Code of Conduct.

k to the subject of the two PRs, 84 is fine but 86 is > way out of line because you've then imposed a speech and conduct code on the > entire universe without any context of having anything to do with Django. > Nothing good can come of this. > > -- Ben > > On We

Re: Two proposals for the Django Code of Conduct.

On 9 sept. 2014, at 19:54, Benjamin Scherrey wrote: > So far we have exactly one documented example and TPTB took it seriously > right away. To me, this hardly justifies any need for an explicit > "anti-harassment" policy. I believe the success of the code of conduct is measured by how rarely

Re: The greatest proposal yet: rename this damn group

2014-09-08 16:21 GMT+02:00 Thomas Leo : > +1 for django-contributors > That would be "Django Contributors" since we're talking about changing the display name of the group, not its email address. It's a good proposal. -- Aymeric. -- You received this message because you are subscribed to the

Re: Two proposals for the Django Code of Conduct.

All, I appreciate the effort you're putting into explaining your arguments. However, the relationship with the original proposal is becoming increasingly unclear. Hopefully by now you've voiced your arguments. I think it's time to let the Code of Conduct committee decide whether to accept the pro

Re: Proposal: enhance 1.7 migration docs re django.core.handlers.wsgi:WSGIHandler()

so I haven't tried to change the code. > > -- > Aymeric. > > > > On 5 sept. 2014, at 20:23, Aymeric Augustin > wrote: > >> Indeed, that was the recommandation until Django 1.3: >> https://docs.djangoproject.com/en/1.3/howto/deployment/modws

Re: Proposal: enhance 1.7 migration docs re django.core.handlers.wsgi:WSGIHandler()

I made this addition here: https://github.com/django/django/commit/f8fdb7177b79b79968a3f40612d33c7367ae584f I'm afraid most projects started before 1.4 will hit this :-/ but the fix is really easy so I haven't tried to change the code. -- Aymeric. On 5 sept. 2014, at 20:2

Re: Proposal: enhance 1.7 migration docs re django.core.handlers.wsgi:WSGIHandler()

Indeed, that was the recommandation until Django 1.3: https://docs.djangoproject.com/en/1.3/howto/deployment/modwsgi/ And it worked until Django 1.6 but breaks in 1.7. Sorry for missing that. We should add something in the release notes. Would you mind filing a ticket on https://code.djangoproj

Re: proposing max line length of 119 + enforcing it with flake8

That works for me. Considering the amount of code that needs fixing, it isn't a big deal if the cleanup is spread over many commits. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop rece

Re: Please don't kill the ecosystem

2014-09-03 10:40 GMT+02:00 Tom Evans : > > I think it was more distraction by topics he had not come across. We > set him off by saying "look at the release notes, go thru each change > in turn, see if we are affected and what we need to fix it". > Thanks Tom for the details. I understand better.

Re: Please don't kill the ecosystem

2014-09-02 15:33 GMT+02:00 Tom Evans : > this story was scored > at 8 points, it took a junior developer much longer than 8 points and > wasn't finished in a single sprint - and 1.3->1.4 was *easy* > I don't know how much a point or a sprint is worth in this context :-/ I know that upgrading is

Re: Please don't kill the ecosystem

Hello, While I generally agree with what other core devs have said regarding the examples you raised, I still find your feedback interesting because it reminds us that we iterate too quickly for at least some parts of the community. It's unavoidable that some people will find the pace of Django's

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