Re: Cookies with Django

{I am not a lawyer. None of this is legal advice, of course.} Django itself does nothing to tell your users authentication uses cookies. If and how you choose to do that is up to you; also, there are some 3rd party apps to try to make this easier. However, I find this paragraph from https://gdp

Re: Feature Request: Allow Serialize Foreign Keys as Ids

I think if you give it an afternoon's digging you could add an option to the django core serializers to list non-field attributes to include. -- Curtis > > On Thursday, August 3, 2023 at 9:46:27 PM UTC-4 Curtis Maloney wrote: >> __ >> Hi Mike, >> >> On Fri, 4 A

Re: Feature Request: Allow Serialize Foreign Keys as Ids

Hi Mike, On Fri, 4 Aug 2023, at 06:03, Ryan Gartin wrote: > I came across this issue calling the following and FK fields with _id are > ignored: > serialize('json', , fields=['title', 'state_id']). I think the problem you've run into here is "state_id" is not a Field on your model; it's wh

Re: Can we move the activity on this list to the Forum now?

Does the Forum allow me to get email notifications / summaries? If not, it will mean I disconnect with that part of the community. -- Curtis On Thu, 4 May 2023, at 15:19, Arthur Rio wrote: > Yes please! > > > > On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com > (jure.erznoz...@gmail.c

Re: Drop CSRF middleware from the settings template

On Mon, 17 Apr 2023, at 04:25, 'Ryan Hiebert' via Django developers (Contributions to Django itself) wrote: > I've recently been working with other new frameworks, particularly Remix. > Coming from Django, which has had excellent CSRF for many years, one of my > first questions was how to handl

Re: create database view from another table

Hi Mike, this is not really the correct list for your question - this list is about development _of_ Django, not _with_ Django. That said: did you consider adding an index for each of the derived values you wanted? This can act as an efficient way to keep, effectively, a "cache" of values deri

Re: ticket 5929

On Sun, 8 Jan 2023, at 23:29, Barhamou Hama wrote: > Hi all, I came across this ticket here > opened 15 years ago that doesn't > seem to have been resolved. I decided to work on it. But in 15 years a lot > can happen. Is it still relevant? Has there b

Re: Integrate dj-database-url into Django

I recently did a bit of an audit of "settings types" whilst preparing for an overhaul of django-classy-settings. I found you could cover a majority of the common config types if you could somehow parse from an environ string the following (which closely aligns with django-environ): + str + int

Re: Model-level validation

FWIW +1 from me! -- C On Thu, 6 Oct 2022, at 14:11, Aaron Smith wrote: > It sounds like there is little support for this being the default. But I'd > like to propose something that might satisfy the different concerns: > > 1) A `validate` kwarg for `save()`, defaulted to `False`. This maintain

Re: Model-level validation

On Thu, 29 Sep 2022, at 14:29, Aaron Smith wrote: > Why doesn't Django validate Models on save()? The short answer is: backwards compatibility. Model level validation hasn't always been a thing, with Django initially depending primarily on Form validation. Since it hadn't _always_ been there, i

Re: Configuration of "level" in LOGGING

On Tue, 5 Apr 2022, at 09:26, Dan Swain wrote: > The current Django LOGGING setup requires a string for the "level". This is > not intuitive since the Python logging module defines logging.DEBUG, > logging.INFO, etc. I think one should be able to configure the logging level > using { 'level':

Re: Deprecation of using pk in public ORM API

Hello Mike, On Wed, 26 Jan 2022, at 20:46, Albert wrote: > > Hello all, > > I would like to know your opinion about deprecation of using "pk" > alias in filters and other places of public ORM API. > I use Django long time and never use "pk" because in my opinion > it is misleading. > I mean, ins

Re: Idea

Additionally, incorporating DRF [or any other 3rd party lib] into core would lock them into Django's release cycle. As for built-in REST/API features, Django provides `JsonResponse` already, so the main piece lacking is de/serialisers. The built in serializer framework is well suited to generat

Re: A base compression middleware class

Hi Illia, I like the idea here, and your design looks sensible at first blush, but I feel conflicted. As much as I like the idea of allowing more flexibility and future-proofing this middleware, AIUI the gzip middleware is generally discouraged, as it's typically more efficient to have your we

Re: GSOC Proposal : A new AUTH library.

Just throwing another idea into the pile whilst we're here. For a long time I've felt we could more easily support a lot more use cases if we separated Authentication from Authorization. The simplest path for this would be to separate credentials (username, password) from the User record. This

Re: Let's simplify coding with html

I think it's unclear to me what you mean by "support for bootstrap". Bootstrap is, after all, a CSS library [with some JS tools for complex widgets]. It looks like the syntax example you gave supports specifying classes [and likely other attributes] on elements, so using Bootstrap with that is a

Re: Feature request: Template tag like stateless component in JSX React

On Fri, 29 Jan 2021, at 19:18, Aztec Rabbit wrote: > Curtis - This is nested block right? what i want is like tag include (can be > called more than once) but with children. Correct. And that's more or less what nested block does; The difference from include is sniplates takes a template and rip

Re: Increase default integer keys to 64 bits

I recall a discussion some time about about adding a setting to control which field to use for the default PK... seems there's some overlap here. -- C On Fri, 29 Jan 2021, at 12:42, Christophe Pettus wrote: > tl;dr: Introduce new field types to handle auto-incremented ID fields, change > the P

Re: Add image and phone_number fields to Django User auth model

I second this; I would have moved to having auth.User be abstract, and force projects to create their own _always_, except (a) it breaks a lot of history, and (b) it breaks the "ready to go out of the box" nature. It's a small cost at the start of your project, that avoids problems for a sizabl

Re: Feature request: Template tag like stateless component in JSX React

I did something like this in django-sniplates https://sniplates.readthedocs.io/en/latest/tags.html#the-nested-widget-tag -- C On Thu, 28 Jan 2021, at 17:33, Aztec Rabbit wrote: > Hi, > > I think template tag like in JSX is very useful, for example: > > > card.html > > > {{ title }} > {{

Re: Pendolumn

Hi, Damiano I suspect we chatted on IRC yesterday about this... On Wed, 9 Sep 2020, at 11:01, Damiano Porta wrote: > Hello everybody! > Can I use Pendolumn (https://pendulum.eustace.io/) as default datetime > library for my models? > This library is good, it has very intuitive and clean API desi

Re: Django default input validation accepts special caracters

Just my 0.02 $CURRENCY... Interesting they're limiting the input for a security issue [at least from the example] that manifest from not escaping _output_. Seems related to something I learned early in my web career... about not storing values escaped, because you don't know which medium it nee

Re: include_block template tag

Interesting ideas... and looks similar to some of the features I put into Sniplates: https://sniplates.readthedocs.io/en/latest/ If you like we can work on adding this to sniplates, if it's not accepted into core. -- Curtis On Mon, 17 Aug 2020, at 19:05, Jure Erznožnik wrote: > While renderin

Re: The blacklist / master issue

Just my small contribution to the discussion... Independent of "social" aspects to the choice of words, the move towards "self explanatory terminology" is preferable, IMHO. As an example, it takes less mental effort or historical context to know what an "allow_list" is compared to a "whitelist"

Re: Deprecate HttpRequest.is_ajax

On Thu, 21 Nov 2019, at 09:25, Tom Forbes wrote: > > If Django were to provide a solid API for parsing Accept headers [not as > > easy as it sounds] and selecting a preferred response type [based on accept > > preference weights] ... would that take care of the bulk of "content > > negotiation

Re: Deprecate HttpRequest.is_ajax

My reading of this discussion boils down to "if we get rid of is_ajax (a buy-in convention nobody can rely on), how do people decide if it's an AJAX call or not?". To my mind, the "content negotiation" advocates have it right: HTTP has a mechanism for determining what response format is desired.

Re: Proposal: security enhancements

I think there is certainly a strong case based on "secure by default" to include this in core, where it would otherwise face the "it works fine as a 3rd party app" barrier to entry. IMHO it would require, however, that the solutions be sufficiently generic as to not enforce an overly restrictiv

Re: Python 3.8 and Django 2.2.3 Issues

> Kind regards > > On Monday, July 15, 2019 at 1:25:24 PM UTC+1, Curtis Maloney wrote: >> >> >> On Mon, 15 Jul 2019, at 22:13, Ehigie Aito wrote: >>> Like I said, I didn't say the problem was from Django. I said it's from >>> Python 3.8 bec

Re: Python 3.8 and Django 2.2.3 Issues

e that this change has happened. As I said earlier, I think there is a change in how Python 3.8 works that is causing those checks to fail. -- C > > On Mon, 15 Jul 2019, 13:07 Curtis Maloney, wrote: >> __ >> I think you're making an assumption about the cause of the proble

Re: Python 3.8 and Django 2.2.3 Issues

I think you're making an assumption about the cause of the problem, without evidence. Yes, there's an issue shown in that traceback related to middleware, but I've not seen yet why you've concluded it's creating a settings.py with MIDDLEWARE_CLASSES. I think the problem is more likely some cha

Re: Python 3.8 and Django 2.2.3 Issues

On Mon, 15 Jul 2019, at 21:36, Ehigie Aito wrote: > Like I said, in older versions of Django, that variable used to be named > MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django > 2.2.3, its MIDDLEWARE but Python 3.8 and Django 2.2.3 its named > MIDDLEWARE_CLASSES which

Re: Python 3.8 and Django 2.2.3 Issues

On Mon, 15 Jul 2019, at 21:23, Curtis Maloney wrote: > First for everyone reading, it's important to note that Python 3.8 hasn't > been released yet. To elaborate on this point - it's _close_ to release, so it's valuable to see how Django behaves with it. -- C --

Re: Python 3.8 and Django 2.2.3 Issues

First for everyone reading, it's important to note that Python 3.8 hasn't been released yet. Secondly, a new project in current Django will not emit "MIDDLWARE_CLASSES" in a new settings file. Could you explain how you determined something had "changed" the setting? Could you also provide deta

Re: GDAPS

On 6/20/19 7:12 AM, Christian González wrote: What I need for a good plugin life cycle are methods, callbacks that are called when a plugin is "installed" = run the first time, methods for enabling/disabling etc. > The easiest way would be implementing these methods within the AppConfig subcla

Re: GDAPS

On 6/17/19 5:47 PM, Christian González wrote: I've given some thought to this over the years, and what I think we've somehow missed in settings until now is ... Namespaces! I can second this from my POV, having "evaluated" a few plugin systems now. Any plugin or app ought be able to declar

Re: GDAPS

[forgive me for typing as I think... but sometimes it's the best way to think ;) ] On 6/17/19 5:19 AM, Christian González wrote: Am 16.06.19 um 10:06 schrieb Adam Johnson: * What do you think are the implications for Django core? Is there anything Django could do better to support this and all

Re: How to deal with potential Django bugs you come accross

Hi Erik, On 5/13/19 8:22 PM, Erik Stein wrote: Hello everyone -- From time to time I come accross a potential bug in Django core, but because of a tight schedule don't have the time to dive into it and write a proper ticket. How would you suggest to deal with it? my personal position wo

Re: Proposal to format Django using black

On 4/25/19 8:14 PM, James Bennett wrote: I like Django's style guide. I like the *idea* of an autoformatter. I dislike the particular mostly-unconfigurable style Black enforces, and I find that several of its rules negatively impact code readability. So I would be -1 on applying it to Django

Re: First ASGI pull request is ready for review

I cannot find emoji enough to express how much I appreciate the work you've put into this :) -- Curtis On 4/25/19 6:50 AM, Andrew Godwin wrote: Hi everyone, Just wanted to drop a note and say that the first pull request in the series needed to enable async in Django is now ready for review:

Re: Why does ModelForm do validation and not Model

On 4/17/19 4:55 AM, Aymeric Augustin wrote: Hello Will, It's mostly for performance reasons, since validation can be expensive. Really? My memory was that it was (a) backward compatibility [model validation was added later], and (b) practicality [try catching everywhere in your code you sav

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

On 4/13/19 10:22 PM, Markus Holtermann wrote: Thanks for the proposal, Shai. I quite like it. As discussed at the DCEU sprints I think I'd like to be able to omit the display form of an item and have it auto generated from an item's name, i.e. turning "FOO_BAR" into "Foo Bar" (`key.replace("_",

Re: Add to QuerySet method `one` that acts as `first` but without ordering

On 4/14/19 8:02 PM, Florian Apolloner wrote: Hi, while your arguments for adding `.one` are all good and well, I think adding yet another function will add quite some confusion and will make arguing harder imo. As a middleground I could imagine adding an `ordered=True/False` argument to first

Re: Proposal to format Django using black

So to summarise the discussion so far: 1. automated code formatting will be a great boon - reduce work, lower barrier for new committers, reduce work for the fellows, etc. 2. there are issues with git history in doing "the great commit". 3. there are issues with black's formatting choices.

Re: More standard template filters

On 4/5/19 8:16 PM, Adam Johnson wrote: FYI Jinja2 allows (most) python expressions, so this would Just Work(TM): {{  myvar.startswith("x") }} Django Template Language has a lot of legacy that prevents this from happening, afaiu it would not be possible to move to it. For "legacy" read "philo

Re: More standard template filters

On 4/5/19 3:06 AM, Collin Anderson wrote: Hi All, I use django templates a lot and I always wished there was a myvar|startswith:"teststring", myvar|endswith:"teststring" and a myvar|contains:"teststring" filter. It's almost like we need a syntax for calling methods with an argument, just li

Re: GSoC 2019 proposal - Easy Ethereum Blockchain integration

On 3/15/19 6:42 AM, Diego Lima wrote: *Introduction* These days, every single living being has heard of Bitcoin. Some of those know that Bitcoin is a cryptocurrency (crypto for short) and, within those, a few know that it runs on top of a technology called Blockchain. Be aware that outside

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

On 2/23/19 7:35 AM, Collin Anderson wrote: I wouldn't mind just rolling back the security fix (or maybe making a straightforward way to enable/disable the behavior). We could instead encourage people to use on any links (from the password rest page) to untrusted urls. I don't think it would

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

On 2/5/19 1:09 PM, Cristiano Coelho wrote: Pointing to Django Rest Framework should be more than enough. Anyone starting a project with Django and a SPA/JS architecture, will pretty much end up with DRF. Correct me if I'm wrong. It's likely they'd end up with DRF, however there are alternative

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

On 2/5/19 11:52 AM, Maciek Olko wrote: I didn't find this topic being discussed before. I guess it wouldn't take much to say "Just like any other server-side framework that can parse and generate arbitrary content, Django can be used to support any Javascript or Mobile app that talks HTTP(S)

Re: IRC Channel

On 12/14/18 5:30 AM, Avi Garg wrote: Does Django have an IRC channel? I am unable to join it if so... There is #django on the Freenode network. To join it you will need to create an account on their network - see https://freenode.net/ for more details. -- Curtis -- You received this messag

Re: A faster paginator for django

On 12/5/18 8:30 PM, Saleem Jaffer wrote: Hi all, The default paginator that comes with Django is inefficient when dealing with large tables. This is because the final query for fetching pages uses "OFFSET" which is basically a linear scan till the last index of the current page. Does it make

Re: Consensus about visual diagrams in the docs.

On 11/30/18 7:38 PM, guettli wrote: I do not care for the strategy, I care for the goal. How to find clear consensus now? There is a time honored practice in open source of spurring more spirited discussion by presenting a solution, however sub-optimal it may be. It may not be the accepted

Re: Question regarding a possible bug

On 11/23/18 11:10 AM, bernie2004 wrote: I am pretty but not 100% sure i found a bug in 2.1.2. Would it be appropriate to post a description of what i think i found to this mailing-list before starting a ticket or is there a better place for posting things like that? Opening a ticket directly

Re: QuerySet.iterator together with prefetch_related because of chunk_size

On 10/12/18 10:51 AM, charettes wrote: Hello Tobias, From my understanding the introduction of chunk_size doest't help here. The fundamental reason why iterator() cannot be used with prefetch_related() is that the latter requires a set of model instance to be materialized to work appropriate

Re: Question (potential feature request) on dropping database column in migration

On 10/02/2018 09:42 AM, martin_x wrote: Hi there, Thanks for making Django a great framework for starters :D Recently my team have run into problems when trying to remove a database column from the model without stopping our Django server, below is the timeline: There have been processes de

Re: RFC732 (a.k.a. brotli) support

On 09/14/2018 08:24 PM, Aymeric Augustin wrote: Hello, I would like to be sure that Brotli is actually faster. In my experience, while decompression is fast, compression can be extremely slow. https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html It's primarily tuned for fast

Re: Not Creating test DBs with PG backend

On 08/28/2018 08:33 PM, Tim Graham wrote: Why is a new option needed? Why can't --keepdb be used for this use case? Because that would be different behavior. If you can convince me that using --keepdb is a solution, then I will use your argument to say that --keepdb should be on always. Wha

Not Creating test DBs with PG backend

Greetings, one problem that turns up more and more frequently, it seems, is that someone is trying to run tests but can't because of the following scenario: 1. The user they connect to the DB using a role that does NOT have permission to create a DB 2. Django's PG adapter, when keepdb is no

Re: A Django Async Roadmap

In general this sounds like a tremendously useful tool... I'm caused to wonder, however... what, if any, are the performance impacts? -- Curtis On 08/21/2018 08:10 AM, charettes wrote: Regarding the lazy loading of deferred fields and foreign keys I wanted to mention I've been working on a t

Re: HTML5 and XHTML5 documents

On 08/17/2018 06:50 PM, Nils Fredrik Gjerull wrote: think, however, that it is more clear if we give it a value. By the way, the syntax is not new it is the old syntax from HTML4. I have spent quite some time cleaning up ill-formed HTML4. One of the more significant differences between the adve

Re: Django and Cython

On 08/02/2018 07:02 AM, Daniel Anechitoaie wrote: I'm looking at frameworks like https://vibora.io/ that make use of Cython to greatly improve the performance and I'm just wondering if something like this would work with Django? Was there any discussion (taken into consideration) about using Cyt

Re: A Django Async Roadmap

On 06/05/2018 07:54 AM, Tom Forbes wrote: Are the proposed modifications to how Django runs sensible? I had a few random thoughts while reading your proposal: I think getting rid of the related field references could be a big issue here and cause a lot of headaches for existing applicatio

Re: Spaces between argument separator and argument in template filter generate error

On 05/31/2018 06:39 PM, oli...@kidsnote.com wrote: Are there any reasons that not allow spaces between separator and arg? My first thought would be that it starts making the syntax looser, meaning more things that are currently error cases would be accepted as valid. Which means mistakes wi

Re: A more useful list of common passwords?

On 03/30/2018 07:05 PM, Adam Johnson wrote: This new file sounds good to me. Whilst you're at it, what is the new file size? I downloaded the gist, took only column 3 (the actual passwords) and gzipped it, it came to 81K over the existing 3.8K. Uncompressed that's 163K over 7.1K. Still

Re: A more useful list of common passwords?

By which I mean... hi Brenton! Great to see you being active again :) It's great you've taken the time to do this, and the benefits are very clear [improved security], but what are the costs? Whilst you're at it, what is the new file size? -- Curtis On 03/30/2018 04:26 PM,

Re: A more useful list of common passwords?

What sort of performance impact is this having over the existing list? What's the additional memory load, if any? -- Curtis On 03/30/2018 04:24 PM, Brenton Cleeland wrote: Three years ago Django introduced the CommonPasswordValidator and included a list of 1,000 passwords considered to be "co

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

On 03/30/2018 08:57 AM, Ryan Hiebert wrote: It's a subtle difference between how a single filter works and two filters work together over to-many relationships. Here's a writeup that I found helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/ It's also addressed in the

Re: GSoC 2018

On 03/17/2018 08:18 PM, Manasvi Saxena wrote: Hello Sir, On Saturday, March 17, 2018 at 2:23:45 PM UTC+5:30, Curtis Maloney wrote: On 03/17/2018 07:37 PM, Dmitriy Sintsov wrote: > Hi! > > Template languages are my favorite topic in programming. Having writ

Re: GSoC 2018

On 03/17/2018 07:37 PM, Dmitriy Sintsov wrote: Hi! Template languages are my favorite topic in programming. Having written a few template engines myself... I guess it's high on my list too :) If you implement html library yourself, it is much better to define tags not as functions but as c

Re: Cache backends and thread locals

I believe I'm (at least partly) responsible for this change, and the short answer is basically "historically memcache client libs have been awful with threading". This may have improved, but in order to avoid a whole slew of potential problems (with memcache and other backbends) I copied the pa

Re: “Abusing BinaryField” warning about binary files in DB

On 02/26/2018 08:30 AM, Antoine Pietri wrote: Can I suggest replacing the warning by something like this?: Although you might think about storing files in the database, consider that it might be a bad design choice. This field is not a replacement for proper static files handling. That said, t

Re: Thoughts on diff-based migrations with django?

Hi, I must say your idea intrigues me... and I'd certainly like to discuss it further. The first thought that comes to mind is how would such a system handle data migrations? Being able to leap from one schema state to another is great, buy typically in the life-cycle of a reusable app it'

Re: Google Summer of Code 2018

On 02/13/2018 09:23 PM, askpriya...@gmail.com wrote: Hello ! What is the policy regarding NoSQL datastores being used as backends ? I think adding support for something like MongoDB might be good idea. Could you elaborate on why you think it would be a good idea? I believe every other time t

RFC : Migration Adapters

Hey, I've recently written an app that implements a closure tree using views... and in order to make the migrations work as needed you must manually add an entry to the migrations. Another friend of mine, a recent django convert, was wanting a way to add to the migration script generated whe

Re: Don't assume that missing fields from POST data are equal to an empty string value.

On 01/22/2018 06:03 PM, Anupam Jain wrote: Wow - I just realised that we have been losing data for sometime on our web platform since there were some fields in the ModelForm that were hidden and not being sent. They were all being overwritten as blank values. Thank God, we use django-reversion

Re: GLOBAL_PERMS

So, I've taken a different approach, following Markus' idea, and added "app_label" to Permission. I probably still need to add a check to ensure you don't set app_label _and_ content_type, but that can wait for now. You can now define new app-level permissions on the app's AppConfig.permis

Re: GLOBAL_PERMS

On 12/31/2017 11:51 AM, Josh Smeaton wrote: - I dislike the seetings approach of GLOBAL_PERMS and would rather see   users writing explicit data migrations. I don't favour either setting or migration based perms, but if you're going to go with migration based, then please also consid

Re: GLOBAL_PERMS

On 12/31/2017 12:50 AM, Markus Holtermann wrote: Thanks Curtis, I had a quick look. Some thoughts (in no particular order): - IMO a nice idea. I've attached all model independent permissions to  the user model in the past to work around the limitation. Certainly a good one I'll remember to m

GLOBAL_PERMS

So, after a discussion with a new user on #django today I decided to make "permissions not bound to models" a first-class feature. So I've written a simple patch that is in https://github.com/django/django/compare/master...funkybob:feature/cjm/global_perms?expand=1 Basically: 1. Allow Perm

Re: about ticket 28588- has_perm hide non-existent permissions

On 09/25/2017 08:56 PM, Dan Watson wrote: Seems like maybe it would be more helpful if has_perm logged a note about the permission not existing (probably only in debug), rather than just returning False. In fact, I'd argue it should still return True -- if the permission did exist, the superuse

Re: Automatic prefetching in querysets

The 2 goals of a famework: - protect you from the tedious things - protect you from the dangerous things N+1 queries would be in the 'dangerous' category, IMHO, and 'detecting causes of N+1 queries' is in the 'tedious'. If we can at least add some DEBUG flagged machinery to detect and warn of

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 >(targeted >for Septe

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

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 possib

Admin browser support policy

This topic seems to appear frequently over the years, but I've yet to see a clear decision. Without a clear Browser Support Policy for admin, it can be very unclear what cleanups, optimisations, and improvements can be made. Collin Anderson suggested supporting IE11+ ("as that's the latest on

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

f) let MySQL users opt for PositiveBigAutoField if they want... On 10/06/17 19:40, Curtis Maloney wrote: 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

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 cha

Re: Default to BigAutoField

ated 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, Curtis M

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. I've >been >bitten by i

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: Integrate dj-database-url into Django

My django-classy-settings also supports env-based settings, in a declarative manner with defaults. What I've yet to crack (though the discussion is underway) is good formats for structured settings like caches and databases. Generally I use dj-database-url for my own projects :) I like the i

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 necessar

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 12:50:02 AM UTC+2, Paolo Melchiorre wrote: >>> >

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 provides

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 introduce

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

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 w

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

  1   2   3   >