Re: new to django... looking to contribute to learn more

Certainly sounds useful, and the research seems to suggest all (most?) of the major backends support it. -- C On 9 February 2015 at 11:26, Bob Remeika wrote: > Hi, > > I'm new to django and python in general but I've been a programmer for a > while now. > > I was

Re: new to django... looking to contribute to learn more

t 13:21, Bob Remeika <bob.reme...@gmail.com> wrote: > Yeah I think so although I don't know enough about it to know for sure. > I'm hoping to come up with something rough and then get a little help from > people that know better. > > On Sunday, February 8, 2015 at 5:24:28 PM UTC

Re: discontinue shipping tests with contrib apps?

Just to shine a light on another perspective- I frequently tell people to look at contrib for "best practices", and including tests within a 3rd party app would fall under that. -- Curtis On 10 Feb 2015 03:34, "Marc Tamlyn" wrote: > +1 to removing tests from contrib

Re: discontinue shipping tests with contrib apps?

ate > "tests" directory. Or did I misunderstand what you meant? > > - Django REST framework > - django-nap > - the apps that split out from contrib (formtools, comments, localflavor) > > On Monday, February 9, 2015 at 5:28:22 PM UTC-5, Curtis Maloney wrote: >> &

JsonResponse and list values

Ran into this bug this morning... what's the rationale behind JsonResponse only accepting dict types unless you set safe=False to allow _any_ type? Surely list/tuple should also be permitted? There's a test explicitly ensuring lists fail. I'm not comfortable turning off ALL type safe-guards

Re: JsonResponse and list values

Cheers for the quick reply... well, you learn more about how shit JS is every day :P -- C On 17 February 2015 at 10:41, Florian Apolloner <f.apollo...@gmail.com> wrote: > > > On Tuesday, February 17, 2015 at 12:30:25 AM UTC+1, Curtis Maloney wrote: >> >> Ran into this

Re: Drop the TEMPLATE_DEBUG setting

Just to chip in here... when TEMPLATE_DEBUG=True the template engine uses a substantially different Lexer, based on re.finditer() instead of re.split(). There are about 10 hooks in the Parser class, too, that exist almost exclusively to allow the DebugParser to change behavior. If we always

Re: Adding context to docs

In all cases in Django, if your code imports the class, you can put it wherever you like - so long as Python can find it. It's only things that are "discovered" by Django [admin, models, etc] that must be in a specific module. By convention, forms are put into forms.py ... but that's so _humans_

Re: Adding context to docs

On 20 February 2015 at 11:49, Diana Probst wrote: > Never done either of those things, and I'm completely not set up to do > them. I will if creating this subject has made me the owner of it, but > it's a lot more work for me than it would be for someone else. I'd

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

On 3 March 2015 at 03:57, Marten Kenbeek wrote: > Hey all, > > I'm working on a proposal to extend the URL dispatcher. Here, I'd like to > provide a quick overview of the features I propose. > > I'd like to: > - Allow matching based on request attributes such as the

Re: Django Admin new look

Looks pretty slick, but brings with it all the hassles of the past attempts to re-skin admin: it breaks legacy custom pages. I wish we could standardise a theming layer for admin... allow legacy templates, or switching to new, clean, themable templates... Perhaps this could be integrated with

Re: Composite fields

Have you reviewed all the existing works on trying to add composite fields? I know several managed to reach a level of maturity that was almost merge quality, and am sure I heard some of the recent ORM changes would ease support. On 5 March 2015 at 11:42, Thomas Stephenson

Re: GSoC 2015: Template engine optimisation

I have convinced my self [with absolutely no hard evidence, just familiarity with the code] that the template engine is overly cautious when it comes to ensuring values are strings and are escaped properly. After a while I believe layers and layers of caution have accrued, and nobody is sure any

Re: About Class Based views

I found when taking the CBGV session in MelbDjango School, it was best to approach teaching CBV as an exercise in Interfaces. Once the students were familiar with writing basic views, and the patterns therein, much of CBGV became "obvious", and the lesson focused more on the power of interfaces.

Re: About Class Based views

people more readily grasp how all the pieces fit together, and where to hook in to get the results they want. -- C On 18 March 2015 at 10:19, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > On Wed, Mar 18, 2015 at 5:38 AM, Curtis Maloney < > cur...@acommoncreative.com>

Re: Composite fields

Dev discussions typically happen on #django-dev on the Freenode IRC network. -- C On 18 March 2015 at 19:54, Thomas Stephenson wrote: > IRC discussion sounds fine with me, but I'd like to be involved. What's > the channel? > > Thomas > > On 18 March 2015 at 15:47, Asif

Re: URL matching problem

Firstly, this is really a question for django-users ... this mailing list is for discussion of the development _of_ Django, not _with_ Django. On 24 March 2015 at 13:16, Ma Yuping wrote: > django V1.6.8 > > Let URL be: > > url(r'^blog/(?P\d+)/$', views.index,

Re: GSOC: Turn contrib.admin into a customizable management interface

Let's not get bogged down in minutiae just yet :) How to implement a grid and what level of browser support is something that can be threshed out in the process. I love the idea of a Dashboard with custom Widgets. Allowing the existing "App list" widgets, along with new custom non-model widgets

Re: Using AbstractBaseUser without django.contrib.auth

Does your model inherit from PermissionsMixin? If you're using Admin, or any of Django's permissions machinery, you will need django.contrib.auth in there to use the Group and Permission models. -- Curtis On 2 April 2015 at 13:47, Dan Watson wrote: > While trying out

Re: Wsgi Traceback on Django 1.8

At a guess, one of your views is returning a string instead of a HttpResponse object. This is the wrong forum for this question. This list is for discussing the development _of_ django, not _with_ django. Your question belongs in django-users. On 9 April 2015 at 14:56, wrote:

Re: Unneeded index created with unique=True and db_index=False in TextField

Was the OP referring to the unique index, or the index created for the LIKE lookups? I was involved in a discussion recently [was there something on list too?] wanting to be able to opt-out of the second index because they knew they didn't need it, and it was _huge_ on their database. -- C On

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

I looked into using UNLOGGED some time ago, but the create table method was misnamed, and the actual create table function was inflexible. Now the code is much cleaner, and each DB can specify how to enact create table and friends. Which leaves us with the question -- is it possible to alter the

Re: templates: override inner nested block

Could you provide a solid, minimal example of how you get this case? I have seen duplicate rendering of nested blocks happen in the past, and it was because in the resulting template, two blocks wind up with the child defined in them [this actually lead to me writing a {% reuse %} tag to take

Re: Why can't templates access properties

Feel free to open a ticket, as it will give a place to retain the discussion. Perhaps start with the use case for having additional properties on a QuerySet :) -- Curtis On 27 May 2015 at 07:14, Ram Rachum wrote: > I found the cause of my problem:

Re: Feature: Support Server-Sent Events

I think the real questions are: 1. What is stopping a 3rd party product from providing the features you want? If there is something Django can do to make it easier, point it out, and I'll gladly champion a good feature. 2. Why should your solution be the "blessed" solution? The discussion

Re: Using `SECRET_KEY` in password hashers

I think it'd royally screw you over if you ever had to change your secret key [due to suspected leak, for example] as now all your passwords are invalid. -- Curtis On 9 June 2015 at 15:16, Ram Rachum wrote: > Hi, > > What do you think about using the project's

Re: Using `SECRET_KEY` in password hashers

e current > implementation. So isn't this an improvement? > > On Tue, Jun 9, 2015 at 8:55 AM, Shai Berger <s...@platonix.com> wrote: > >> On Tuesday 09 June 2015 08:23:03 Ram Rachum wrote: >> > On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney < >> cur...@acommoncreative.com

Re: Feature: Template Components

This sounds a bit like combining django-sniplates with django-amn, and going a bit further... Fragments of templates, list of JS/CSS dependencies, and a way to collect it all together and ensure your page has everything you need... Sounds interesting to me... I'd be happy to collaborate on it

Re: Django urls and Angular ui-router

This question really belongs on django-users ... this list is for discussion about the development _of_ Django, not _with_ django. That said, it's quite specific in Django that URLs do not map to Templates - they map to View functions. So, depending on your case you should easily be able to have

Re: Allauth user fields and userProfile fields save in one registrationform

This is a list for discussion of the development _of_ Django, not development _with_ Django. This question is better suited to the django-users list. In general, if you need to edit two models in one form submission, you use two ModelForms... I have a blog post on this topic:

Re: Proposal: deprecate and remove egg template loader

so _that's_ why I've been adding zip_safe=False to all my setups for years :P +1 to encouraging the world to move forward :) -- Curtis On 14 July 2015 at 10:40, Russell Keith-Magee wrote: > > On Mon, Jul 13, 2015 at 11:00 PM, Donald Stufft wrote:

Re: Support for UNLOGGED tables in PostgreSQL

On 16 July 2015 at 05:01, Shai Berger wrote: > This is a shot in the dark: Could it be that rolling back transactions > involving unlogged tables is harder? The idea does make sense, and running the > test suite does an extremely untypical amount of rollbacks. I thought at

Re: Support for UNLOGGED tables in PostgreSQL

I second what Aymeric say rather than take on the burden of maintaining correct warnings, let's point at the people whose responsibility it really is :) -- Curtis On 20 July 2015 at 06:44, Aymeric Augustin wrote: > I agree with pointing to the relevant

Re: Speedy Mail 2.0 - a new webmail platform in Python and Django

Guess I should sign up on django-users so I can throw my hat in for this... I've yearned for a Python-based webmail that has a featureful UI :) So far there's only Modoboa, excellent as it is. Competition is healthy, so... -- Curtis On 22 July 2015 at 05:20, Shai Berger

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

Let me open by saying I am in no way averse to the removal of these two tags... and this reminds me I need to also re-work my "remove the 'x as y' argument syntax" patch again... On 7 August 2015 at 07:08, Marc Tamlyn wrote: > However, as with all technical debt, it has a

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Just my $0.02... I quite like the idea of adding update_instance and commit, with save calling both... To me, this provides a clean and obvious place to customise updating the instance before saving... as well as a clear place to get an updated instance without saving. -- Curtis On 7 August

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

Given the [currently] low burden, I agree with a more gradual deprecation... document against their use to help encourage people to move away from them, then we're in a better position to more painlessly remove them in the future. -- Curtis On 7 August 2015 at 11:43, Karen Tracey

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

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 way (a) people are warned off it, and (b) we're confusing people who find it and want to check what it does [even though it's

Deprecating old keyword syntax in DTL

Long ago, the keyword syntax in Django templates was: expr as name but was changed to look more like Python as: name=expr However, the facility to parse the old syntax is still there, but will silently fail unless you pass "support_legacy" to token_kwargs. In fact, it is enabled for

Re: Deprecating old keyword syntax in DTL

For reference, the old PR is here : https://github.com/django/django/pull/1619/files Unfortunately, it doesn't rebase cleanly onto master... some very odd stuff shows up... but it wouldn't take much to regenerate this work. -- Curtis On Saturday, 8 August 2015 21:33:22 UTC+10, Curtis Maloney

CSRF middleware conflicts with request.upload_handlers

So I recently ran into the csrf/upload_handlers conflict as mentioned in the not https://docs.djangoproject.com/en/1.8/topics/http/file-uploads/#id1 I'd like to propose an additional option to solve this -- a decorator to mark a view as "ajax-only" ... so the CSRF middleware will _only_

Re: CSRF middleware conflicts with request.upload_handlers

:51:18 AM UTC-5, Curtis Maloney wrote: >> >> >> So I recently ran into the csrf/upload_handlers conflict as mentioned in >> the not >> https://docs.djangoproject.com/en/1.8/topics/http/file-uploads/#id1 >> >> I'd like to propose an additional option to s

Re: MOSS Award to Django

On 16/12/15 12:05, Ben Liyanage wrote: And, beyond that, there are plenty of non-critical tasks that applications could easily offload until after a response has been sent - like saving things into a cache or thumbnailing newly-uploaded images.

Re: Decoupling the ORM

I've identified one new "issue". There is an implicit assumption that primary keys are useful for ordering by the current QuerySet API methods `.first()` and `.last()`. I believe the case here is that first and last are meaningless without an ordering, so in lieu of any programmer supplied

Re: A community Poll

To clarify a few points: In general, I'm in favour of removing string references for things... however, when it comes to relation fields, I'm on the side of "alway lazy". Also, I don't want this discussion to be about my specific issue with contenttypes... more a general "community opinion of

Re: delegating our static file serving

On 01/01/16 15:49, Fabio Caritas Barrionuevo da Luz wrote: A question: are there any plans to also improve MEDIA files (user uploaded files) in any foreseeable future? Perhaps this is outside the scope of Django, but I believe Django could provide by default, any option to get a little more

Re: re-thinking middleware

In general, I love it. It's MUCH simpler for people to write and comprehend... requires no classes [but IMHO the callable class is "cleaner"] and allows for configurable middlewares easily... I do wonder, though... how the anti-import-strings factions will react... I'm sure it can, at

group-by promotion

Hey all, I'm trying to write a PR for adding Postgres9.4's "FILTER" syntax for aggregates, but I've hit a bug I can't figure how to fix [and nobody's awake on IRC :)] https://github.com/django/django/pull/5956 Basically, for the query: qset = FilterAggParentModel.objects.annotate(

Re: Vote on Jira as bugtracker

On 09/01/16 13:08, Hugo Osvaldo Barrera wrote: Not an actual django developer (I'm a user lurking here really), but I'd still like to chime in: Doesn't make your input any less valid... in fact, perhaps makes it more valuable :) * Jira is too complex. Devs may end up understanding it,

Re: delegating our static file serving

I should probably finish off my toy working on the same lines... but introducing my earlier comments about per-source paths and permissions mixins... Very much a WIP, but I'm sure you'll see the idea: https://gist.github.com/funkybob/a89c10e24716a4ce55cf -- C On 18/01/16 09:58, Gordon

Re: Deprecate Cache.has_key()?

Isn't this so it complies with the dict interface? True, it's discouraged now, but it's still there. On 30 January 2016 10:42:12 am LHDT, Tim Graham wrote: >Also the template BaseContext class has an undocumented has_key() >method. I >wonder if that can be removed

Re: remove support for unsalted password hashers?

I kept meaning to weigh in on this... but all my points have been made. It sounds like the middle ground is to: 1) remove them from the default list 2) keep them in the codebase 3) make them noisy (raise warnings) 4) provide docs/tools on how to upgrade Then we get "secure by default" (1), as

Admin hstore widget

So, I've been working on https://code.djangoproject.com/ticket/25197 I have it as part of my own project, with a view to contributing to core once it's polished. Currently it has basic functionality - a JS widget that fires on load, hides the textarea, and produces a table of (name, value,

Re: Django & django-polymorphic

On 11/02/16 09:22, 'Hugo Osvaldo Barrera' via Django developers (Contributions to Django itself) wrote: Hi there, I'd love to see some (most?) of the features from django-polymorphic on django itself. I'm very much be willing to work on this myself. Of course, there's several details that

Re: thinking about the admin's scope and its description in the docs

On 11/02/16 00:55, Andy Baker wrote: I can't help but feel that the "admin is very rudimentary and hard to customize" is perpetually overplayed by many in the community. Maybe I'm suffering Stockholm Syndrome but I'd like to raise a dissenting voice. I must admit I'm a large proponent of

Re: Django & django-polymorphic

On 11/02/16 15:05, 'Hugo Osvaldo Barrera' via Django developers (Contributions to Django itself) wrote: > There was some research by Sebastian Vetter on "single-child > auto-resolve" solutions for MTI and how they scaled (from memory, > model-utils' InheritanceManager, polymorphic, and

Re: thinking about the admin's scope and its description in the docs

On 11/02/16 20:11, Andy Baker wrote: > As customisable as it can be, I find the problem to be it is a data-centric view of your system, closely tied to the database models. You're correct that a truly 'task-centric' UI would be a lot of effort - but really - how common are such interfaces in

Re: Add warning or prohibit module level queries?

+1 At the very least we need to provide better feedback or errors to help isolate _where_ this is happening. I've helped quite a number of people on IRC with this problem... firstly, people aren't understanding _what_ the problem is, but also discerning where it's happening is often quite

Re: Should tutorial start with minimal Django?

When we were teaching MelbDjango, I did start by writing views in the root urls.py this avoided students having to create a bunch of files and apps and references and imports and... For some of the students transitioning from PHP, it was much easier to deal with only learning one thing

Re: Proposal: Refactor Form class

Hi, On 04/03/16 07:00, 'Moritz Sichert' via Django developers (Contributions to Django itself) wrote: Hello, I want to propose a refactor of the Form class to make it easier to customize and subclass. I've recently had thoughts in this direction, so seeing your post intrigued me...

Re: Admin hstore widget

On 08/03/16 02:43, Tim Graham wrote: 1. Merging something minimal always help to get feature requests. :-) 2. Could you be more specific about what you're looking for? All the existing documentation for style related stuff is at

Re: Admin hstore widget

On 08/03/16 20:47, Marc Tamlyn wrote: Doing something better with the admin hstore is definitely something I'd like to see land. 1. I'd like more input on the features people feel are essential. Something that allows you to add/change/delete keys is all you need to start with. Features like

Re: Revisiting multiline tags

On 12/03/16 11:47, Nathan Cox wrote: I don't understand why this conversation has had to go on for this long. The original post was in February of 2012, and it is now March of 2016. That's four years of discussion that basically boils down to a couple of purists insisting that their coding

Re: Django startproject template enhancement proposal

Well, you could use: mkdir my_client_name django-admin startproject project my_client_name/ So it will create my_client_name/project/settings.py, and leave the namespace clear for you to create my_client_name/my_client_name/ as your app... -- Curtis On 15/03/16 10:51, Ramez Ashraf wrote:

Re: [ GSOC 2016 ] providing standard interface for NoSQL databases

It sounds like by "NoSQL DBS" you mean specifically "Document store DBMS". Is this correct? (I'm sure most people know my rant about how "NoSQL" is a misnomer, and it's really "Non-relational" that people mean - it's not SQL per se they're avoiding, it's the relational model) The

Re: MySQL data loss possibility with concurrent ManyToManyField saves

+1 for me, too... this aligns with "safe/secure by default". -- C On 21/03/16 09:13, Aymeric Augustin wrote: I agree with Karen. -- Aymeric. On 18 Mar 2016, at 22:15, Karen Tracey > wrote: This is the 2nd major issue I can recall caused by

Re: Add documentation to address OWASP Top 10?

On 06/04/16 11:35, Josh Smeaton wrote: I like the idea of addressing the OWASP top 10. Further, I think the advice of obscuring keys is wrong. The problem is actually addressed in the OWASP Top 10[0] *4 Insecure Direct Object References:* A direct object reference occurs when a developer

Re: Making Django more PaaS-friendly

Just want to throw my 3c in here... Firstly, for reference, I wrote django-classy-settings to help with various settings related problems, one of which being env-based setting. https://github.com/funkybob/django-classy-settings As my env decorators are written to be class properties, they

Re: Making Django more PaaS-friendly

On 12/04/16 04:26, Aymeric Augustin wrote: On 11 Apr 2016, at 19:39, Curtis Maloney <cur...@tinbrain.net> wrote: 1. All env vars can have a fallback value (the method in my case) 2. You can mark an env var as not having a fallback value, and it will raise an error at start up if n

Re: Making Django more PaaS-friendly

On 14/04/16 05:57, Carl Meyer wrote: Hi James et al, In general, I like the idea of adding a helper to Django to read settings from the environment. I think this helper should be kept as simple and non-magical as is reasonable. Thus: - I'm in favor of a flexible helper function that can be

Re: Table Locks and bulk creating inherited models

On 03/05/16 09:47, Russell Keith-Magee wrote: Hi Geoffrey Have you given any thought to what the API for a table lock would look like? Since it's a table-wide action, having it on the Manager makes some sense... though it would be, I suspect, implemented via _meta. I can see something

Re: Table Locks and bulk creating inherited models

On 03/05/16 14:08, Gavin Wahl wrote: > with MyModel.objects.lock(): > ... do stuff ... This is misleading as it implies the lock is released when the context manager exists, but in postgres at least the lock will be held until the end of the transaction. Hah! Shows how much I

Re: Template-based widget rendering

Sorry for the late entry to the discussion, but I was looking over the code and wondered about something. In projects where I've used my django-sniplates for form rendering, it's been helpful that I can have several different form widget sets within the one project -- for instance, for

Re: Template-based widget rendering

On 12/05/16 01:04, Preston Timmons wrote: Hey Curtis, I think you're asking how this patch will help with form and field layouts? If so, not that much. It only addresses moving the widget HTML that currently is hardcoded in Python into templates. No... was all to do with widget rendering...

Re: Template-based widget rendering

On 16/05/16 15:10, Carl Meyer wrote: On 05/15/2016 11:01 PM, Curtis Maloney wrote: So this seems to leave us only part way to removing rendering decisions from the form code -- your widgets can be templated, but your form code still needs to decide which widgets... Yep, one step at a time

Re: Middleware error framework, high level logging for database queries

On 19/07/16 05:16, Rishi Gupta wrote: Hi django-developers, (1) Middleware error framework. Zulip has some exception middleware to allow 40x errors to be returned to the user from anywhere within the view code via raising a special exception, which we’ve found to be a really nice, convenient

Re: Extend support for long surnames in Django Auth

As I watch this discussion I am reminded of a talk I saw a few years ago at PyConAU: https://www.youtube.com/watch?v=_V4q0o-nKp4=PLs4CJRBY5F1KDIN6pv6daYWN_RnFOYvt0=33 -- Curtis On 01/08/16 09:34, James Pic wrote: On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton wrote:

Problem with caching template loader

Hey, a client of mine was having a strange bug with the caching template loader, which we've yet to identify, but as I was looking at the code, I saw the following: def load_template(self, template_name, template_dirs=None): key = self.cache_key(template_name, template_dirs)

Re: Any inerest in Zlib pre-compressed HTML generator responses?

On 16/08/16 09:10, Bobby Mozumder wrote: Hi, I also use generators for my views, and I use Django’s streaming views with my generators to stream responses, so that the web browser receives early responses and start rendering immediately before the view is completely processed. The web browser

Re: Sonar for the Django rpoject

If there will be sweeping commits to remove six and other py2 concessions, can the cleaning be included then? On 4 September 2016 9:38:05 AM AEST, Sergei Maertens wrote: >I kind of like these reports, since they can take away some of the >early >review work. I would

Re: Challenge teaching Django to beginners: urls.py

On 15/09/16 16:37, Curtis Maloney wrote: Somewhere I have code to provide a "parse" based URL router. Will dig it up now 1.10 has has shipped Ah, found it... So, here is a gist of a sample of using parse (https://pypi.org/project/parse/) instead of regex. https://gist.github.co

Re: Should the Django session-id be hashed?

On 22/09/16 18:52, Rigel wrote: Hello! The Django session framework stores session-ids in the database as plain-text. Unless I'm missing something, these ids could be vulnerable to SQL injection attacks, if any are discovered or if developers misuse features like extra(). Firstly, extra()

Re: Please put monitor.py as default in next django version

On 15/10/16 08:16, Ricardo Prado wrote: Thanks "Folks" in special Aymeric Let's go, let me explain about this "monitor.py". When users deploy django app in production, the changes in any python script need be "reloaded" for apply changes, in this you have two options to do this: 1 - restart

Re: Feature idea

My solution to the "initial password problem" is to send a password reset token first... And Django has this built in, handily :) http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/ It would be very easy to use the same approach for an "invite" registration pattern.

Re: drop compatibility with Python < 2.7.8?

Well, I certainly agree with the intent... especially, as you say, for LTS users who effectively cement themselves to a version for the long haul. Might as well remind them there are security updates in things other than OpenSSL, Java, and Django :) -- C On 15/11/16 09:49, Tim Graham

Re: Fellow Report - October 15, 2016

Ummm... On 16/10/16 11:45, Tim Graham wrote: https://code.djangoproject.com/ticket/27334- File uploads could rename temporary files rather than copying them (duplicate) https://code.djangoproject.com/ticket/27334- File uploads could rename temporary files rather than copying them (accepted)

Re: Changing {% include %} to strip a trailing newline

On 05/01/17 10:09, Adam Johnson wrote: Whitespace control in templates is an exercise in frustration. In my experience more flexible tools such as {%-, {%+, -%}, and +%} in Jinja2 increase the frustration. I really enjoy the {%- etc. operators in Jinja 2 in the context of

Re: No 'Content-Type' header in response

>From what I can see in the rfc, it is permitted but not required. Only a body in a 204 response is proscribed. Any metadata (I.e. headers) are about the resource just accessed... So a Content-Type would, IMHO, be acceptable but not essential. On 26 December 2016 9:47:02 PM AEDT, roboslone

Re: Django versioning and breaking changes policy

See? This is exactly what I told you you could expect ... to be shown the new release process details :) [For those playing at home, Bernhard raised this concern on IRC first, and I recommended bringing it here. He expressed concern about being roasted, and I predicted someone would

Re: Admin and CSS Custom Properties

I recently discovered that the stated "policy" on browser support in Admin is... well... not clear at all. https://docs.djangoproject.com/en/1.11/faq/admin/#what-browsers-are-supported-for-using-the-admin It claims to support full function for "YUI's A-Grade" browsers, but the link it

Re: Django 2.0 Python version support (Python 3.6+ only?)

Is there any list of things we gain from dropping / adding any particular version? The older discussion mentions a tracking ticket, but it is empty. -- C On 8 August 2017 9:45:54 AM AEST, Tim Graham wrote: >With a little more than a month to go until the Django 2.0 alpha

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

Dogfooding is a fairly strong argument, IMHO. Especially when there's a volunteer to do the work. -- C On 7 May 2017 6:53:13 PM AEST, Paolo Melchiorre wrote: >On Sun, May 7, 2017 at 9:16 AM, Florian Apolloner > wrote: >> On Sunday, May 7, 2017 at

Re: Default to BigAutoField

I know people hate settings, but what about one for auto id field type? It would let you handle backwards compatibility, uuid, and bigint... -- C On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss wrote: >I think this would be a good improvement, and I'd like to see it.

Re: Default to BigAutoField

ing the auto-generated primary key "swappable", including >foreign keys that point to it. This sounds like a headache. > >I haven't thought of a possible solution since Kenneth floated this >idea in >#django-dev yesterday. > >On Friday, June 9, 2017 at 7:11:05 PM UTC-4

Re: Trimming in the settings file (Was: Re: Follow-up to #28307: Possible app_template improvements)

On 26/06/17 20:21, Melvyn Sopacua wrote: On Thursday 15 June 2017 08:14:02 Aymeric Augustin wrote: I see the point for the number of useless files. But in every release, settings.py has been trimmed more and more to the point that it's next to useless. I'm wondering about the upside of that.

Re: Cython usage within Django

On 22/05/17 09:30, Tom Forbes wrote: Hey Karl and Russell, Thank you for your quick replies! Russell: You are of course right about the speed of the Python code itself being a bottleneck and the usual suspects like the database are more important to optimize. However I don't think it's

Re: Exceptions in model._meta._property_names with some 3rd-pty libraries

What about using inspect.getmembers ? https://docs.python.org/3/library/inspect.html#inspect.getmembers In other code I've also used inspect.classify_class_attrs but it seems to be undocumented :/ If nothing else, it could be used as a guide on how to do this. -- Curtis On 03/06/17 08:52,

Re: Follow-up to #28307: Possible app_template improvements

On 15/06/17 16:14, Aymeric Augustin wrote: Hello, The more files get generated to startapp, the more empty useless files accrue in many projets, because devs don't take the time to delete those they don't use. Beat me to the punch... I agree the default template should be as light as

Re: Default to BigAutoField

On 10/06/17 22:21, Claude Paroz wrote: Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit : Right, hence my point of having a global setting to say "the default auto-field is ..." I see, but this conforms to the pattern "use the same id field type for a

Re: Default to BigAutoField

Right, hence my point of having a global setting to say "the default auto-field is ..." This would: a) let people continue to use AutoField b) let people opt for BigAutoField c) let 3rd party projects be agnostic d) let people use UUIDField(default=uuid.uuid4) e) possibly make it feasible to

<    1   2   3   >