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

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

> On 31 août 2015, at 20:59, Aymeric Augustin > wrote: > > Perhaps we could make the --parallel option the default in runtests.py. You’d > have to pass --parallel-num=1 to disable it. This would help occasional > sprinters unfamiliar with the option. They could just run .

Re: Password validation in Django revisited

address. > > Superuser successfully created > > Cheers, > > /Markus > > On Saturday, September 5, 2015 at 5:14:16 PM UTC+10, Aymeric Augustin wrote: > Hello, > > Indeed, this will be annoying for development. > > I don’t find the “admins don’t need rules,

Re: Password validation in Django revisited

Hello, Indeed, this will be annoying for development. I don’t find the “admins don’t need rules, they know what they’re doing” argument compelling. The cobbler children’s go barefoot… Besides, if admins know the rules, having validation enabled won’t hurt :-) I’m in favor of implementing an es

Re: Making the test suite run faster

On 31 août 2015, at 20:41, Tim Graham wrote: > Aymeric, did you envision any changes to Django's CI setup? Glad you asked :-) I have some thoughts but no definitive opinion. > Currently we run 1 Jenkins executor per CPU, so I don't know that adding > parallelization would have any benefit? (We

Re: Making the test suite run faster

Hi Tino, 2015-08-31 8:35 GMT+02:00 Tino de Bruijn : > - What happens when two SerializeMixin tests try to lock the same file? > Does one wait for the other (probably not), or is a lockfile exception > raised? > The second one waits for the first one to complete. This happens all the time because

Re: Making the test suite run faster

On 31 août 2015, at 06:12, Andrew Godwin wrote: > I'm on board merging this without Oracle support - if I understand right, it > means we just have to run those non-parallel for now, so we're not losing > anything, right? Right. -- Aymeric. -- You received this message because you are subs

Re: Making the test suite run faster

;s development version and have a large test suite.) Thanks! -- Aymeric. > On 22 févr. 2015, at 16:29, Aymeric Augustin > wrote: > > **tl;dr** I can run the full test suite in 85 seconds on SQLite, a 4.8x > speedup. > > > Hello, > > Since I last wrote abou

Re: Add DoNotTrack (DNT) middleware?

On 29 août 2015, at 19:32, Alex Gaynor wrote: > Moreover, adding the middleware doesn't change any behavior, you still have > to do a bunch of work in your app to actually implement the not-tracking > logic. Indeed I’m afraid that people will believe that the middleware makes them compliant,

Re: How to disable system check framework?

Hello Marcin, There’s an obvious bug here: silenced checks are still printed out — even though they don’t prevent Django from starting. I hadn’t understood that from your earlier messages. It shouldn’t be very hard to fix. If you want to make sure we don’t lose track of this bug, you should fi

Re: Django oscar core apps confilicts with my local apps

Hello Kishan, This is off-topic for the django-developers mailing-list, which is dedicated to the development of Django itself. Please send usage questions to django-users. The docs for Oscar’s get_core_apps() answer your question: http://django-oscar.readthedocs.org/en/latest/topics/customisati

Re: request for API review of streaming responses additions

Hello, I have three main comments on this patch. 1) About the general API design This patch adds 7 new “stream” public APIs that duplicate the current “render” APIs. Adding a stream=False argument to the current APIs would be a more lightweight alternative. Passing stream=True would enable the s

Re: Improving MSSQL and Azure SQL support on Django

Hello Meet, On 21 août 2015, at 19:39, Meet Bhagdev wrote: > We’d love for Django users to have a solid option to use MSSQL and Azure SQL > if they wish, and it would be great to make this option a reality. Even though this isn’t what you’re asking for :-) I’ll take this opportunity to summ

Re: Django Admin New Look

LLED_APPS wins. (NB: before 1.7, management commands had the opposite behavior.) -- Aymeric Augustin. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop

Re: Django Admin New Look

On 18 août 2015, at 01:28, Tim Graham wrote: > Unless someone can present an argument for keeping IE8 support, I wouldn't > worry about it considering it will be end of life about 1 month after the > release of Django 1.9. Let’s just make sure the admin stays usable, even if it looks bad. Sinc

Re: Enhancement to the call_command function to allow the use of modules as arguments

2015-08-17 16:54 GMT+02:00 Mike Lissner : > > I’m -1 on removing the Python API that’s equivalent to `django-admin >> my_command`. It’s needed for testing management commands that override >> other management commands. >> > > Not sure what you mean here, but I suspect you're making a good point. >

Re: Enhancement to the call_command function to allow the use of modules as arguments

Hello Mike, I saw your ticket a few days ago, thanks for bringing it up here. > While using call_command (which simplifies calling management commands), it > occurred to me that the API is a little strange. It currently is designed to > work like this: > > call_command('my_command', *args,

Re: removing FlatPage.enable_comments field?

On 14 août 2015, at 18:22, Shai Berger wrote: > So, what was the field for? Is the purpose still pertinent? If so, since > there are no uses in current code, how is it addressed? I reviewed `git log -S enable_comments`. All occurrences fall in one of three categories: refactoring the FlatPage

Re: removing FlatPage.enable_comments field?

On 12 août 2015, at 00:43, Tim Graham wrote: > A compromise could be to hide the field in the default ModelAdmin and let > those who want it to enable it with a custom ModelAdmin. What do you think? That would resolve my problem of “WTF is this field” without causing too much headache. We sho

Re: removing FlatPage.enable_comments field?

On 13 août 2015, at 08:39, Loïc Bistuer wrote: > How about we deprecate contrib.flatpages: I think it’s sufficiently widely used and not sufficiently bad to make deprecation a good tradeoff. > - I see people abuse it all the time (do way more with it than they should) > just because it's in c

Re: Future of the development server's auto-reloading

Hello Sam, On 10 août 2015, at 11:34, Sam Cooke wrote: > I've thrown together a rough proof of concept[2] for runserver that uses > watchdog to watch for changes/additions/deletions to python files recursively > in the same directory as manage.py and restarts the server accordingly. It > coul

Future of the development server's auto-reloading

Hello, While writing some horrific code [1] related to the development server’s auto-reloading, I realized that its design is fundamentally flawed and I think that we should reconsider it. The current implementation walks through the list of all imported Python modules, attempts to figure out

Re: FAQ on Model-View-Controller

Hi Dan, On 8 août 2015, at 18:03, Dan S wrote: > So I humbly suggest that the wording of the FAQ be adjusted to make clear > that the "meaning" of V and C are not debatable, that templates and > template-feeding code always serve the purpose of Viewing the model, and that > Controller code can

Re: FAQ on Model-View-Controller

Hello Dan, Depending on the size and complexity of a Django project, there are two ways to implement MVC. (I’m talking of a traditional Django project, not Django-as-an-API-for-a-JS-app.) 1) Small project: the straightforward way M = models.py V = template.html C = thick views.py: most of the

Re: Ticket #25236: Remove ifequal from the template language

> On 7 août 2015, at 05:43, Curtis Maloney wrote: > > I'd probably go with updating the documentation to say they're legacy > tags, you're better off using {% if %} now, and warn they may be > removed in a later release. This is my inclination as well. Then we can revisit the topic in a few year

Re: How to disable system check framework?

nctions are provided in transaction module > (thanks so much for that!), so making compat layer should be possible, I > think. > > Kind Regards, > Marcin > >> On Wednesday, August 5, 2015 at 1:16:38 PM UTC+2, Aymeric Augustin wrote: >> On 5 août 2015, at 11:09, M

Re: How to disable system check framework?

On 5 août 2015, at 11:09, Marcin Nowak wrote: > I'm using commit_manually() frequently, but this decorator was removed... Hi Marcin, Sorry for derailing the discussion a bit, but could you clarify why you were using this API? I removed it after failing to find a use case where it would be pref

Re: Django Admin New Look

s just > from another Django admin. > >> On 30 July 2015 at 09:55, Aymeric Augustin >> wrote: >> Le 29 juil. 2015 à 13:13, elky a écrit : >> > >> > I can create small kit which will contain only icons that used in the >> > project - it wi

Re: Making max_length argument optional

> Le 29 juil. 2015 à 18:25, Podrigal, Aron a écrit : > > I see models as what defines the database ddl and and not a representation > from a end users perspective. Django models do a bit more than this: see the `validators` argument, EmailField, etc. > And I see the tight coupling between the

Re: Django Admin New Look

Le 29 juil. 2015 à 13:13, elky a écrit : > > I can create small kit which will contain only icons that used in the project > - it will allow us to save about 70KB. But the question is - how to support > this kit in future if someone decide to add new icons ? Indeed, it could be difficult to ma

Re: Support for UNLOGGED tables in PostgreSQL

I agree with pointing to the relevant section of the PostgreSQL documentation. It will always be more complete, accurate and up-to-date that what we could write. -- Aymeric. > On 19 juil. 2015, at 19:43, Christophe Pettus wrote: > > This can be achieved by pointing to the relevant section

Re: Support for UNLOGGED tables in PostgreSQL

Hello Federico, 2015-07-13 16:26 GMT+02:00 Federico Capoano : > While these are the winners: > >- fsync = off >- synchronous_commit = off >- full_page_writes = off > > Would you like to submit a patch to docs/ref/databases.txt, in the "PostgreSQL notes" section, explaining this config

Re: should we close in-memory file-like objects (StringIO, BytesIO, etc.)?

2015-07-03 17:10 GMT+02:00 Berker Peksağ : > I agree with you on the StringIO and BytesIO cases, but I agree with > Andriy on the other usages (e.g. ZipFile, GzipFile). Many contributors > follow the existing practices to write new tests, so it would be nice > to use best practices if they don't p

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

2015-06-24 23:48 GMT+02:00 Shai Berger : > That is exactly the point: Before the proposed change, you *cannot* control > the page returned for disallowed user agent via handler403(), because that > handler is called when the PermissionDenied exception is raised, not when a > Response object is ret

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

2015-06-24 1:56 GMT+02:00 Shai Berger : > Could any of the supporters elaborate on the use-case? > Just to clear a possible confusion -- this feature already exists, it was added in 2005 to filter out unwanted crawlers by blacklisting their user-agent. The proposal here is to use the custom 403

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

DISALLOWED_USER_AGENTS predates the addition of the 403 handler and wasn't updated to take advantage of it. I believe it would make sense to raise Http403 there. Would you mind filing a ticket on https://code.djangoproject.com/? Thanks! -- Aymeric. PS: perhaps we should audit the code base for

Re: 1.9 release planning

OK, count me as -0 ;-) -- Aymeric. 2015-06-23 13:23 GMT+02:00 Loïc Bistuer : > > > On Jun 23, 2015, at 17:24, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > > > > I'm against making changes to the version numbers we've already plann

Re: 1.9 release planning

I'm against making changes to the version numbers we've already planned for and also against 1.10, 1.11 etc. version numbers. Such numbers can easily break version checks that don't expect this case. There's lots of code in the wild with version checks, some of which will probably behave incorrect

Re: DecimalField with no max_digits and decimal_places

“Unlimited” precision is a natural semantic DecimalField(). Likewise, if we ever make max_length optional in CharField(), now providing it will mean “unlimited” length. (Scare quotes because storage is never really unlimited.) I think we should provide the best API for our users and deal with the

Re: 1.9 release planning

Le 15 juin 2015 à 15:54, Loïc Bistuer a écrit : > > I'm -0 (borderline -1) on that proposal. I don't think we should compromise > on our historical commitment of deprecating over 2 releases I'm in the same camp as Loïc on this specific point. If we're approaching consensus, could a kind soul p

Re: Tips on adding a Couchbase backend

On 14 juin 2015, at 20:23, mnunberg...@gmail.com wrote: > It would only be worthwhile trying to make a proper database-engine if the > rest of django would support it: Specifically, any kind of data modification > using SQL is currently unsupported This is an well defined limitation. If you can

Re: 1.9 release planning

2015-06-12 18:58 GMT+02:00 Carl Meyer : > I don't get the feeling that the core team is really ready to accept > that length of continued support for deprecated APIs. > Especially if the deprecation and removal is a pre-requisite for implementing a new feature... I'm not writing code that I can't

Re: URL namespaces

2015-06-12 0:38 GMT+02:00 Marten Kenbeek : > The change causes exactly... 1 test failure, > `shortcuts.tests.ShortcutTests.test_render`. It's not even a functional > test, it only fails because > `self.assertFalse(hasattr(response.context.request, 'current_app'))` > fails.The template tests don't

Re: App config on the default template for app creation

> On 11 juin 2015, at 21:04, Tim Graham wrote: > > Aymeric, did you consider it? No, I didn’t. > It seems reasonable to me. Yes, it is. My extreme dislike of code generation extends to startapp but I’ve created enough apps.py files to accept the practicality of this suggestion. -- Aymeric.

Re: Using `SECRET_KEY` in password hashers

Hello, 2015-06-09 16:16 GMT+02:00 Josh Smeaton : > You're referring to a "pepper" - a site wide secret that's supposed to be > used, in some way, to further encrypt passwords. As far as I'm aware there > are no algorithms available that take a pepper into consideration. > I'm also wary of implem

Re: 1.9 release planning

> On 8 juin 2015, at 15:25, Tim Graham wrote: > > Any other feedback on the proposal? I could assume no complaints is a good > sign, but some +1's would be easier to interpret. :-) I think your proposal is a reasonable compromise. It came up briefly during some discussions among core devs at D

Re: URL namespaces

> On 8 juin 2015, at 15:24, Marten Kenbeek wrote: > > If there is a consensus that thread-local storage is the better solution I don’t think there’s consensus when only one person brought up the idea :-) I’m unconvinced at this time and I’ll probably argue against it if it gets more seriously

Re: Feature: Support a javascript template language on the server

2015-06-02 18:27 GMT+01:00 Emil Stenström : > That's a problem that I hadn't thought about. I was hoping that querysets > where always serializable, but I didn't think of datetime and decimal (and > others), which people might send to their views. Are there other pitfalls > here? Maybe this could

Re: Feature: Support a javascript template language on the server

2015-06-02 12:54 GMT+01:00 Aymeric Augustin < aymeric.augus...@polytechnique.org>: > implement a template engine that hands over data to a Node.js process, > lets it render the template, gets the HTML back, and returns it. If someone wants to try this, https://github.com/markfinger/

Re: Feature: Support a javascript template language on the server

Hello Emil, 2015-05-30 17:52 GMT+01:00 Emil Stenström : > But what needs to happen is that the same templates that Django uses needs > to be accessible to, and executable in, javascript. > > For this to work, two things needs to be built: > > 1. A way to access the template and the template conte

Re: URL dispatcher API

Hi Marten, I had a look at your proposal today. You've done good work there. My comments revolve around making the API obvious, simplifying it until someone who discovers it understands immediately what the moving pieces are, what they do, and how they relate to one another. Here are my two main

Re: An easier path to upgrade from one LTS release to another

Hello, On 8 mai 2015, at 17:54, Carl Meyer wrote: > > On 05/07/2015 10:20 PM, Tai Lee wrote: >> This sounds good. But will it significantly slow down the rollout of new >> features into Django that require deprecation? > > No, because it would only delay the removal of deprecated features, not

Re: New function to sort words with accents.

If you're using PosgreSQL, django.contrib.postgres provides such a function. -- Aymeric. > Le 6 mai 2015 à 02:52, Paulo Maciel a écrit : > > I am returning the query Something.objects.all().order_by(Lower('name')) but > the order is not respecting names that start with accent, causing these

Re: Improving Test Speed for Projects that use django.contrib.postgres

2015-05-05 6:15 GMT+02:00 David Muller : > Haven't had a chance to try and throw everything into RAM disk but that > sounds pretty cool. > Actually, that's the reason why I added support for tablespaces on PostgreSQL in Django 1.4 :-) https://docs.djangoproject.com/en/1.8/ref/settings/#default-t

Re: Removing global database converters and adapters for datetimes

Hi Carl, 2015-04-13 21:11 GMT+02:00 Carl Meyer mailto:c...@oddbird.net>>: It would also be possible to put the silent-data-loss aspect of this change through a deprecation path, by having the existing adapters raise a deprecation warning on receiving any non-UTC aware datetime for a couple release

Re: Removing global database converters and adapters for datetimes

On 13 avr. 2015, at 20:13, Aymeric Augustin wrote: > Replacing adapters is a bit more tricky. Removing them causes the two > regression tests for #17755 to fail. I haven't determined how I can process > parameters passed to QuerySet.raw(), but since that's part of the OR

Re: Guessable entry points

On 1 mai 2015, at 15:51, Enrique Paredes wrote: > So along this line of thought, `django-admin` is a good command name? Well, it’s a reasonably unambiguous way to refer to the django-admin command, which is good for the docs. “django” is more ambiguous: it can refer to the framework itself (

Re: Guessable entry points

`python -m django` as a alias for `django-admin` sounds good. -- Aymeric. > On 30 avr. 2015, at 19:15, Ryan Hiebert wrote: > > https://github.com/django/django/pull/4588 > > > I this PR I suggest to add a `django` entry point that is identical t

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

> On 27 avr. 2015, at 16:17, Christopher Adams > wrote: > > So wrote an  > RFC > > > and a pro

Re: Idea/request for help: Django Developers Community Survey

That's a great idea! Like all Internet polls the results may be biased by the population who answers. We may not get answers from the least active parts of the community. However it would give us /some/ data instead of opinions. I'm happy to contribute to defining the questions. -- Aymeric.

Removing global database converters and adapters for datetimes

Hello, On databases that don't support time zones -- SQLite, MySQL, Oracle (*) -- the implementation of time zone support I added in Django 1.4 defines: 1. A global converter, e.g. `parse_datetime_with_timezone_support` for SQLite, which processes values returned by the database for datetime c

Re: Django Admin New Look

2015-04-07 17:25 GMT+02:00 Marc Tamlyn : > The primary questions to establish answers to before a possible merge in > my opinion are: > - Do we ship both, or just the new one and release the old one as a third > party package? > I'd like to make the new theme the default unless the developer opts

Re: render_to_response in Django 1.8 missing a request parameter?

Hi Stephen, The only difference between render_to_response and render is that render_to_response doesn't know about the current request while render does. If you were using: response = render_to_response('some_template.html', {'foo': 'bar'}, RequestContext(request)) Now you should use: respons

Re: 1.9 release planning

Hello, With the current system of release branches, the release schedule doesn’t affect much the rhythm at which Django accrues changes. For a given community of contributors and team of committers, the amount of changes in a new release is roughly proportional to its development time. (We cou

Re: Fate of sql* management commands

2015-04-02 23:03 GMT+02:00 Marc Tamlyn : > As far as I'm aware, we have some code paths which still work in 1.9 which > generate tables directly from the models. We use this when running Django's > own test suite, and it is also used now by djangobench. I haven't looked > into exactly how to turn

Re: Fate of sql* management commands

On 30 mars 2015, at 23:10, Carl Meyer wrote: > So it is not true that the Python models are the canonical > representation of your schema, and the SQL DDL is just a translation of > them. In fact, your migrations are the (only) canonical representation > of your schema, which may include things (

Re: GSoC 2015: Improved URL Pattern Matching (Draft)

Hi Alexander, I won’t repeat what Russell said, just add a few things. A few months ago I had a use case for internationalization that looked pretty simple but turned out to be tricky to implement: https://github.com/oscaro/django-o18n . Resolving is easy

Re: GSOC 2015: Django based Management Information System for Institutes

2015-03-25 17:21 GMT+01:00 Asif Saifuddin : > lookign for some feedback from you about my proposal idea > > its still on going to improve my proposal and im working on it > https://gist.github.com/auvipy/1da0d96f826bd8da4d47 > I read it when you first posted it, but I don't have constructive feed

Re: GSOC 2015: Django based Management Information System for Institutes

2015-03-25 14:48 GMT+01:00 Harsh Vardhan Ladha : > Thanks for quick reply. Can you help me to decide whether its good project > for GSoC or not? and to which Mentor I can submit its proposal if Django > community will not accept it? > This isn't our choice. It's one of the rules of GSoC. It also

Re: GSOC 2015: Django based Management Information System for Institutes

2015-03-25 14:40 GMT+01:00 Harsh Vardhan Ladha : > I am planning to develop Django based Management Information System for > Institutes to manage their Marks Entry System and Grade Card generation > system efficiently. > Hi Harsh, GSoC only covers the development of Django itself. Projects that

Re: improving debug logging in development

The lack of a fathomable way to get a functional logging config is a huge pain point :-) In this case, I wish we improve Django’s logging tools rather than document how to bypass them :-/ -- Aymeric. > On 21 mars 2015, at 19:24, Tim Graham wrote: > > I think the lack of an obvious way to

Re: Pre-DEP: community support of unmaintained versions of Django

Hi James, When I read your proposal I thought -- "this makes sense, but if maintainers are making this commitment, they should be part of the Django team". Only after reading Carl's comment did I realize that they shouldn't be part of the team in order to keep the "unofficial" aspect. This makes

Re: Django Admin New Look

2015-03-16 15:41 GMT+01:00 elky : > I'm going to make pull request this week, so in case of success I hope > people will have enough time to test new theme in alpha and beta releases. > For what it's worth, I've deployed your theme on an internal application and received positive feedback from us

Re: GSoC 2015: Template engine optimisation

2015-03-13 12:21 GMT+01:00 Sam Cooke : > The test template we were using to test the performance was a simple: > {% for item in item_list %}{% include "item.html" %}{% endfor %} > Bad luck -- including a template in a loop is one of the known pathological performance cases of the DTL :-( -- Aym

Re: Having the app list available on every admin view

2015-03-12 18:47 GMT+01:00 Riccardo Magliocchetti < riccardo.magliocche...@gmail.com>: > I've started looking in django.contrib.admin.sites and found a couple of > issues, first at line 469, if app_label == model._meta.app_label is true, > shouldn't we add a break after we found an app_label? AFAI

Re: Django Admin New Look

2015-03-11 21:20 GMT+01:00 elky : > I reworked my previous attempt > of stylizing django admin > and now it looks more like original in terms of color scheme. See > attachments. > This looks good! Now let's try and see if we can merge it :-) Here are

Re: Password validation in Django revisited

Hi Erik, Great work! Did you consider tying validators to authentication backends? I admit it sounds like a bad idea and most likely it is, but since different backends may have different security requirements, I'd like to make sure we aren't missing something. Assuming help_text is HTML, you

Re: Testing email settings

2015-03-09 17:44 GMT+01:00 Gavin Wahl : > I expect this command to work with any email backend and to actually do a > complete, end-to-end test of the configuration. > > I agree. Another example: my SMTP provider will accept emails but put them on hold until you've validated the sender's address.

Re: Composite fields

Hello Thomas, It’s hard for me to digest a two-page-long email on a complex topic during the week. I bookmarked your first email when it came in. It’s Saturday, 11am, and I dedicated my first chunk of quality brain time to reading the entire thread. I’ll let you ponder what the effect of your seco

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

u can find everything you need here: > https://docs.djangoproject.com/en/1.7/internals/contributing/new-contributors/ > > Marc > >> On 3 March 2015 at 18:16, Aymeric Augustin >> wrote: >> I agree: providing a default login template would help. Getting started with

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

I agree: providing a default login template would help. Getting started with contrib apps should be as easy as possible. However the current proposal is backwards incompatible for users who define the login template in one of their apps that comes before django.contrib.auth in INSTALLED_APPS (i

Re: A general way to batch SQL queries in Django

2015-02-28 22:05 GMT+01:00 Ram Rachum : > Here is what I'm currently thinking about: Can we make Django do multiple > separate queries (SQL queries are separated by a semicolon right? Sorry for > being a noob) and send them one after another before blocking on reading > any of them? Only then when

Re: Making the test suite run faster

r concerns. -- Aymeric. > On 7 févr. 2015, at 10:42, Aymeric Augustin > wrote: > > On 7 févr. 2015, at 01:02, Russell Keith-Magee <mailto:russ...@keith-magee.com>> wrote: > >> I've thought about (but never done anything) about this problem in the past &

Should the test suite pass on a read-only filesystem?

Hello, Would it be a good property of the test suite to pass on a read-only checkout? Here’s one way to try it without messing up your git checkout (guess why I’m mentioning this): % find django tests -type f -print0 | xargs -0 chmod u-w % find django tests -type d -print0 | xargs -0 chmod u-w %

Re: Signature of the allow_migrate database router.

2015-02-18 14:07 GMT+01:00 Loïc Bistuer : > Individual routers don't have a base class but we can add it to the master > router `django.db.router`. I've updated the PR with a > `router.allow_migrate_model` method. I don't know if we should document > this just yet. > Good. Unless I missed somethi

Re: Signature of the allow_migrate database router.

2015-02-18 6:34 GMT+01:00 Loïc Bistuer : > Another option would be to make the signature `allow_migrate(self, db, > app_label, model_name=None, **hints)` and to put the model class in the > hints dict, the same way we pass `instance` as hint to the other routers. Yes, that's what I wanted to sug

Re: Formalizing template loader and debug api's

2015-02-17 23:47 GMT+01:00 Preston Timmons : > It depends. The cached loader is what I'm least happy with in my > refactoring. This > internal cache idea I think is simpler, more performant, and easier to > understand. > Adding it makes the cached loader changes unnecessary. > In that case, would

Re: Formalizing template loader and debug api's

On 17 févr. 2015, at 05:46, Preston Timmons wrote: > Even so, I think that can be handled with documentation. And an option to disable it. This is very easy to implement. > Do you think it's worth making an attempt to formalize this? Yes, I do. This is an independent follow-up to the big refa

Re: Formalizing template loader and debug api's

Hi Preston, Thanks for your continued work on this and sorry for my slow answers. On 30 janv. 2015, at 03:24, Preston Timmons wrote: > The cache algorithm I added uses the origin object as a cache key. The "name" > attribute is used as part of the key value. Therefore, the underlying loader >

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