Re: DEP Pre-posal: Re-Designing Django Forms

Hi Robert, I have a whole heap of ideas about this, some of which are captured in documentation here: http://django-adapters.readthedocs.io/en/latest/ The code generally doesn't exist yet, but the project is at https://github.com/ mjtamlyn/django-adapters. This is a *huge* project to achieve ever

Re: improving our Contributor License Agreement process

Accessibility of contributing > Leal protection We shouldn't drop the idea of CLAs, they're there so that an organisation or individual who wants to do things "properly" can still do so. But I don't think we need to enforce it for any contribution. The CLA story for Django is already hazy, as we

Re: models.CalculatedField feature

I like the idea, and have a number of concrete use cases I would use it for. In one case I even have a custom manager which always applies a particular `.annotate()` already, so it can be filtered and accessed on the model. I am inclined to agree with Shai that the fully database version should at

Re: Automatic prefetching in querysets

I feel it would be better to optimise for your usecase, as apposed to try >> to prevent uncalled-for behaviour. >> >> >> >> On Aug 15, 2017 23:15, "Luke Plant" wrote: >> >>> I agree with Marc here that the proposed optimizations are 'magical&#

Re: Automatic prefetching in querysets

Hi Gordon, Thanks for the suggestion. I'm not a fan of adding a layer that tries to be this clever. How would possible prefetches be identified? What happens when an initial loop in a view requires one prefetch, but a subsequent loop in a template requires some other prefetch? What about nested l

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

Yes, don't need that sorry. On 8 May 2017 at 14:40, Adam Johnson wrote: > I'm pretty sure our search requirements on dp.com need that, > > > s/need/don't need/ ? 😉 > > On 8 May 2017 at 13:59, Marc Tamlyn wrote: > >> I'm not sure I see the ben

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

I'm not sure I see the benefit here. The strength and purpose of postgres FTS is that you can combine some FTS behaviour with some relational queries easily at the same time. I'm pretty sure our search requirements on dp.com need that, so using a dedicated search provider is a better option. On 7

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

I would be happy to revisit that decision which was made 9 years ago. APIs returning unusual status codes such as 204 are much more common now than they were then. I can't think of a good reason not to add ~10-15 2-line classes. Marc On 7 April 2017 at 09:37, Brice PARENT wrote: > > Le 07/04/17

Re: Adding generated common table expressions

Hi! This looks generally very good, and I'm quite excited about it. In terms of taking it forwards, I think a DEP is a very good idea, and there are at least 3 core devs who are keen to see a solution. Whether you have the right solution yet I'm not so sure, but it sounds like you're not either.

Re: Vietnamese Django full text search in postgres.

Hi Cử Nhữ Văn, This mailing list is for development of Django itself, rather than support queries. You may get a better answer on the main mailing list or on #django on IRC. You may also find some help about different languages in the docs: https://docs.djangoproject.com/en/1.10/ref/contrib/postg

Re: Provide 'V' as alias for 'Value'?

Given that you can always do import Value as V, I'm not sure providing an alias is necessary. On 3 April 2017 at 12:15, Josh Smeaton wrote: > I think I proposed V as an alias back when I was writing the patch, but > the rough consensus at the time was that one letter class names are a bit > of a

Re: Permission classes for Class Based Views

I don't feel there is any need for this feature in Django. As you mention in the ticket, there are ways of approaching it used in DRF, there are other ways in django-braces[0], I personally have my own taste in how to handle it. The details will depend on the logic necessary - sometimes you need to

Re: Template handling of undefined variables

+1 to not having to add (and then remove later) a {% load %} tag to every template - that was seriously dull with the URL change. Marc On 20 February 2017 at 11:42, Luke Plant wrote: > On 19/02/17 12:55, Adam Johnson wrote: > > +1 for more obvious errors, silently changing the behaviour could i

Re: Should Model.save() fix incorrect types that happen to save correctly?

Agreed - ensuring that this works in the general case is not reliable. On 13 February 2017 at 15:51, Adam Johnson wrote: > What do you think? Absent a better suggestion, we could document this >> pitfall so that there's something to point to when related tickets come in. > > > +1, as Aymeric poi

Re: SubQuery without using RawSQL

Subquery is one word so the lowercase Q would be correct yes. I'm skewed from using SubQuery in my code for the last few months, so that looks fine to me, but let's not get into another query_set problem On 12 January 2017 at 13:11, Adam Johnson wrote: > I vote for Subquery - I wouldn't make a c

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

DEFAULT_CONTENT_TYPE does sound like a setting which shouldn't exist. On 12 January 2017 at 10:53, Adam Johnson wrote: > Having reviewed the ticket a bit and thought about it, I've had two > thoughts: > >1. The current patch doesn't fix existing custom views > >

Re: Responsive admin

I'd suggest including this with a mechanism (on the admin site?) to disable it for a while if that causes problems for existing custom setups? Marc On 9 January 2017 at 11:59, Adam Johnson wrote: > - perhaps supplying an empty CSS file with the same name overrides the >> file provided by the ad

Re: Guidelines to name python modules of Django applications?

What Aymeric and Florian sayid. On 7 December 2016 at 15:58, Florian Apolloner wrote: > On Wednesday, December 7, 2016 at 1:10:48 PM UTC+1, Aymeric Augustin wrote: >> >> I still think I wouldn't use a django_ prefix when I create new apps >> because >> it adds a small but pervasive overhead to p

Re: automating Django releases

I'm pretty confident we can just automate the process you currently do. On 26 November 2016 at 05:40, Josh Smeaton wrote: > I think automating as much of the release process is a fantastic idea. > Regarding bumping the release numbers, have you seen the bumpversion > project https://pypi.python.

Re: drop compatibility with Python < 2.7.8?

I'd be inclined to agree with Claude. On 15 November 2016 at 07:20, Claude Paroz wrote: > I wouldn't spend too much energy about Python 2.7 stuff. Let the > workarounds in place, and just wait for Python 2 to die. I don't see the > point in forcing people of stable Debian-based distributions to

Re: Getting full URL using django.urls.base.reverse - PR

Given we already have `request.build_absolute_uri(path)`, I'm not 100% sure what extra this gives us. It's a bit of syntactic sugar for sure, but it solves a pretty narrow use case. The only times I've actually needed this has been when sending emails and I'm using a `Site` object instead of reques

Re: New deferred loading implementation (Was: [Review Request] Added support for database delegated fields (like AutoField))

I have fed a lot into this discussion in person and on Slack. I don't understand all the ins and outs completely, but I feel that the situation is sufficiently complex enough that we need to consider it all together. The code was certainly very challenging when I tried to make a UUID field use a DB

Re: Built-in router link generator in Django

This doesn't seem like something which is the responsibility of core django to me. There are dozens of different ways to build your menus, I don't see anything about that package which makes it the best way of doing it. On 3 October 2016 at 03:24, Val Neekman wrote: > Folks, > > I am wondering i

Re: Challenge teaching Django to beginners: urls.py

Fwiw, I spent a little time investigating this a couple of years ago. I would like to see Django officially bless the idea of alternative URL systems, and provide the "full" regex system and preferably at least one "simple" system - even if all that system supports is integers and slugs. This would

Re: Django default PK type setting

For what it's worth I think this is *much* harder than it appears on the surface. Whilst setting another field as the PK is easy, setting another base type as an "auto" field is surprisingly tricky - lots of AutoField assumes integers. However, I do think it has some merits. An obvious benefit to

Re: FEATURE REQUEST: Choices overriding in a classes, which inherit abstract class

Adding a new meta option is very unlikely to happen. Really, this is a question about dynamic choices, rather than just inheritance. I'd rather see some sort of solution which allows some (optional) hooks to customise choices on a per-class (or maybe even per instance) basis. This is tricky though

Re: SearchQuery concatenation (`&` and `|`) is either broken or documentation incomplete

Combinable Mixin, so I wonder > if the limitations for SearchQuery aren't on purpose. > > Marc Tamlyn would probably have a good idea if this was an oversight or > deliberate. > > The fix would be to define a SearchQueryCombinable Mixin that looks very > similar to

Re: change commit message format to present tense?

This post by Tim Pope is considered the "definitive guide to commit messages" as far as I'm aware. http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html +1 to adopting this style. On 24 June 2016 at 19:15, Jon Dufresne wrote: > On Fri, Jun 24, 2016 at 10:48 AM, Carl Meyer wrote

Re: Use migrations api to create a command for data migration between different databases

I'd suggest your approach is also quite slow. Andrew Godwin did something similar once at a lower level - see https://github.com/lanyrd/mysql-postgresql-converter (use at your own risk) On 10 June 2016 at 19:44, Bruno Ribeiro da Silva wrote: > The problem here is that this works well for small d

Re: Clearing prefetch related on add(), change(), remove()

to get asked whether > or not this was a bug or not on IRC and my initial thought was also "wtf, > that is clearly a bug" -- hence I asked Yoong Kang Lim to open a ticket. > > Cheers, > Florian > > > On Tuesday, June 7, 2016 at 7:47:29 PM UTC+2, Carl Meyer wrote:

Re: Clearing prefetch related on add(), change(), remove()

I may be "too close" to knowing the implementation of this feature to be able to comment on whether the behaviour is surprising to most people, but it doesn't surprise me. It's certainly analogous to that when you do `MyModel.objects.create()` it doesn't change an already executed queryset. There's

Re: django-mssql present and future

I'm definitely a fan of doing things under the /django banner. I think so long as we make it clear that this is in development then it shouldn't matter about feature parity - especially as django-mssql won't have a version supporting 1.9 or 1.10 anyway. On 27 May 2016 at 08:24, Aymeric Augustin <

Re: Rewriting admin internals

There are certainly elements of forms refactoring you would want to pull from the admin - read only fields and fieldsets being the two most obvious. At a guess, James is alluding to https://github.com/mjtamlyn/django-adapters, my currently stalled project to think about reworking the form/serializ

Re: Rewriting admin internals

Sure, give me 12 months of two full time experienced Django developers and we can rewrite the admin. Honestly, I think everyone knows the admin would benefit from a significant rewrite. However, as the efforts of admin2 proved, it's a huge job to undertake. The admin has a huge number of features

Re: Should we require pytz for timezone support in Django?

It would seem reasonable to me to require it. I wonder whether the reasoning is based on distro packaging or similar? On 17 May 2016 at 01:21, Josh Smeaton wrote: > While writing timezone tests for > https://github.com/django/django/pull/6243 I ran into some issues where > pytz seemed to be requ

Re: Help Text Per Model Field Choice

Choices are currently very simple in core Django. There are multiple different packages which provide alternative syntaxes or useful ideas for ext

Re: Process DEP for "official" non-core projects

I'm a big fan of pulling things into github.com/django. One other point which has been raised when I've mentioned this before is the role of the django fellow(s) with regards to these projects. This should at least be touched on in the DEP. On 11 May 2016 at 20:34, William Hakizimana wrote: > Ju

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> > ISTM that the strongest argument in favor is that I think it _is_ > significantly easier for a casual user to build and deploy their first > websockets app using Channels than using any other currently-available > approach with Django. Both channels and Django+whatever-async-server > require ma

Re: Django Integration

Major features merged into Django have generally never been as "perfect" as the standards required for smaller patches. There's a recognisation of the need for ongoing work, probably over the course of multiple versions, in order to perfect any major new feature. The effort involved in getting a pa

Re: Django website ssl-certificate expired

We are aware of the issue and are working on it. Thanks, Marc On 4 May 2016 at 10:30, Wim Feijen wrote: > Hi guys, > > Apologies if I am posting in the wrong group, but the certificate of > djangoproject.com expired today (4 May). > > Wim > > -- > You received this message because you are subsc

Re: Making Django more PaaS-friendly

I like the idea of integrating dj-database-url. There's a similar package for CACHES[0], which is a neat idea but slightly more tricky to justify as I don't know if PaaS tend to send the cache details in that format necessarily. I'm not sure about the rest of the mail, although I'd definitely be u

Re: Vendoring Select2

Agreed. I recently was trying to use a fitler horizontal widget on my phone and thought the whole thing was broken because `` looks so wrong. I'd love to see this experience improved, and select2 is a good reliable solution. On 6 April 2016 at 15:11, Aymeric Augustin < aymeric.augus...@polytechniq

Re: Vendoring multipledispatch

Does anyone (potentially from OS packaging worlds maybe) have a good reason NOT to have a dependency? In the event that Django does have Pip dependencies, I still think we should establish some rules. Things like they should be stable and mature, and perhaps widely known, and still be under active

Re: Choosing migration with relative syntax

I actually think this would be super useful if we can make it make sense (HEAD~ with merges..). "Undo the migration I just did" is a common operation in development. M On 11 Mar 2016 2:18 p.m., "Joakim Saario" wrote: > You can always have a y/N-question to limit these cases. Though, I think > th

Re: Proposal on Custom Indexes - Google Summer of Code

I like this a lot. Even we we then keep the "Meta" options as they are forever, they then become shortcuts to what you could define explicitly. In any case, we would need some careful checks that (for example) you can't have identical indexes defined in multiple ways with the same names. On 14 Ma

Re: Admin hstore widget

tty sure it's only a year ago a completely raw JS widget was rewritten with jQuery. On 8 March 2016 at 10:40, Curtis Maloney wrote: > > > On 08/03/16 20:47, Marc Tamlyn wrote: > >> Doing something better with the admin hstore is definitely something I'd >> lik

Re: Admin hstore widget

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 soft delete can be added later. 2. Is there

Re: Making max_length argument optional

Voting: 1) should there be a default? I'm lazy, so I would be happy to have one. Where validation matters you can change it, where it doesn't you don't have to. I'd draw an analogy to (Positive)(Small)IntegerField - I often use the normal one when I mean some variant of validation, or some other

Re: Proposal: django.contrib.mysql

One of the other reasons why contrib.postgres is in core is that it required some changes to internals of the ORM. It's possible that all of those we need are done now (except custom indexes) - is there anything about contrib.mysql which would benefit from this? I'm happy for JSONField to be made

Re: Annotate date intervals or ranges

Probably just because there hasn't been an immediate need, and because it working on every database the same way could be... awkward. When you have dates, you also have to think about the timezone implications as well - which timezone do you need that date in? It's also worth mentioning that if yo

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

That looks like a good balanced message to me. On 17 February 2016 at 16:57, Tim Graham wrote: > Here's another try for the docs: > > One of the most powerful parts of Django is the automatic admin interface. > It > reads metadata from your models to provide a quick, model-centric interface > wh

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

I see no reason to remove old versions from readthedocs. On 17 February 2016 at 04:22, Felipe Prenholato wrote: > I was catch by that change today and found the docs in > http://django.readthedocs.org/en/1.5.x/. > > I wan't to suggest that for documentations that Django will remove from > docs.d

Re: argon2 PasswordHasher

It is once per user, but it's once for *EVERY* user when that scenario occurs. That could easily bring a site down if sessions were invalidated or you have short session times. It's far too likely someone will have serious, hard to debug problems as a result of this magical behaviour. I also stron

Re: argon2 PasswordHasher

I may not understand the security implications here properly, but as far as I can tell there isn't a strong enough case that Argon2 is fundamentally better than PBKDF2 yet? At least no more than people's arguments that BCrypt is better. I think retaining the simple out of the box experience where y

Re: test --keepdb and explicitly migrating the test database

Simon - that's great but still means ending up having to create a new test DB every time you switch to a new branch, something you do a lot if you're part of the QA process! +100 to this feature, it would be super useful for me, especially when working with long running feature branches with migra

Re: Vote on Jira as bugtracker

Yeah, this is a non-starter for me. All bug trackers are bad, we should stick with the bad one we are used to. Marc On 6 January 2016 at 13:26, Victor Sosa wrote: > To answer you question: > There is a plug-in to migrate all the data to Jira and similar to > integrate with any it with any in yo

Re: Request for Input: WSGI 2.0

Hi Cory, [Disclaimer - I don't suppose to speak for the whole community here, this is a personal opinion of how I see things] Django's wsgi handling code has remained largely unchanged for many years, so to answer the question of "what does Django itself need from new wsgi, ignoring channels", I'

Re: admin: implementing list_prefetch_related

Hi Richard, Overriding the queryset is a pretty simple method override, I'm not sure there is sufficient need for prefetching here. In particular, the syntax for prefetch related is much more complex than for select related, so it's less well suited to this kind of shortcut. Marc On 30 Dec 2015 1

Re: Add "view_decorators" to django.views.generic.View

Personally, I find that decorators aren't the best way of interacting with CBVs. They're useful when you have a mixed style codebase, but I tend to convert the decorator into a mixin applied at the appropriate point. I think the style of decorating in the URLconf is horrible. Marc On 21 December

Re: deprecate or undocument shorcuts.render_to_response()?

I'd be in favour of just undocumenting it for now. On 22 December 2015 at 16:27, Alasdair Nicol wrote: > I think that updating the docs to use render instead of render_to_response > is an good change. Many of the CSRF problems that I see new users > struggling with are solved simply by switching

Re: Decoupling the ORM

I agree that the current uuidfield is a simplistic solution to be used as autofield, and having a way to specify your autofield type globally would be good, equally something like a biginteger field. The complexity involved with doing this (custom RETURNING statements, database level defaults, inte

Re: Channels integration plan, first draft

[Note: I have not read all the channels docs, sorry if some of these points are covered there.] On a packaging note, is there a way to use django[channels] type syntax like flask does? I'm not familiar with the restrictions of this but it may remove the need for try/except imports. I'm also curio

Re: Split DeleteView into a more generic ConfirmView

to target > django-braces. Will take me a few days tho, because I am loaded with > (school) work right now :). > > --Lennart > > On Tuesday, December 8, 2015 at 10:38:01 AM UTC+1, Marc Tamlyn wrote: >> >> Hi Lennart, >> >> I certainly like the idea and have writ

Re: Split DeleteView into a more generic ConfirmView

Hi Lennart, I certainly like the idea and have written at least two implementations of `ConfirmView` in my projects before. Without getting into specifics, I'm not sure how we feel about adding more generic views like this, even where it does make sense. To me a good initial course of action could

Re: Backporting ticket 25548 into 1.9.x

Agreed the reasoning is sound. This is a major bug as far as I'm concerned and I'd like to see it backported. Thanks for bringing it up. Marc On 6 Dec 2015 1:05 p.m., "Shai Berger" wrote: > On Sunday 06 December 2015 14:52:08 Aymeric Augustin wrote: > > > On 6 déc. 2015, at 10:49, James Bennett

Re: worth adding PyPy to continuous integration?

If we can get it running on the CI reasonably easily I see no reason why not. On 2 December 2015 at 16:46, Tim Graham wrote: > Once in a while, we get a ticket about failures when running the Django > test suite on PyPy. Sometimes they are bugs in PyPy, other times we use > something that's not

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

I can see a use for this, but the API is unsure. Given that from a performance point of view it should be possible to do this as a transform after a values query (in most cases using a similar lazy sequence-like object will maintain the performance you need), can I propose implementing it as an ext

Re: Keep django/django-old GitHub repo?

As there are no active PRs there any more I'm pretty sure it can be ditched. On 25 November 2015 at 14:36, Tim Graham wrote: > Does https://github.com/django/django-old provide any value? I think it > can be deleted. Maybe there are a few links to the pull requests there but > I've never come ac

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

So. If I understand correctly, this would deprecate the existing cached template loader, replace it with a more powerful, debug ready version (on by default?). Assuming this is what you mean, I wholeheartedly support this. There's no reason not to be performant by default. Marc On 23 Nov 2015 2:16

Re: Bringing some popular must have django tools/packages under django org umbrella

This is something the core team discussed in Amsterdam. I believe there was consensus to trial it with Django registration. I should catch up with James and see if it is transferred. If this goes well I see no reason why not. The biggest problem is the selection of packages, we have historically w

Re: Non-atomic migrations in Django?

+1 to idea and API. I've wished I had this recently - even if it's just so I can check up on the progress of a slow running data generation migration so it flushes the data every few 100 records. On 24 November 2015 at 16:07, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > I like

Re: [Feature Request] Performant values_list query

To give some brief historical context: values_list has been around a LONG time, so I wouldn't say anyone has consciously designed it with performance in mind above "it's faster than complete model loading". The most noticeable thing which your code does not do which an implementation of values lis

Re: Oracle GIS update

Thanks for getting it running at all! It looks to me like those tests just need to be less accurate for Oracle, good plan. Did you have any specific changes to make to get it to run at all? If so we should include those soon, irrespective of whether the fixes for these other tests make it into 1.

Re: Proposal: add new template tag "age"

Agreed, this does not belong on core. In particular the formatting of a duration varies widely depending on the expected age range, languages and site context. Naturaltime is one implementation, the specific case you seem to be hinting at is a count of years, which is definitely too particular for

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

I'm definitely in favour of a format allowing multiple storage back ends referred to by name. For larger sites it is not unusual to manage files across multiple locations (eg several S3 buckets). The storage param to FileField would be allowed to be the key, and there would be a get_storage functio

Re: a standard descriptor signature?

Sounds good to me. There's not any (good) reason why anyone would be calling these with kwargs that I can think of so we're safe from a compat perspective. Marc On 26 October 2015 at 03:25, Loïc Bistuer wrote: > +1 > > > On Oct 25, 2015, at 23:09, charettes wrote: > > > > Now that Curtis did a

Re: Python 3.5 Support in Django 1.8.x?

FWIW, I think we should add 3.5 support to 1.8. On 23 October 2015 at 17:08, Tim Graham wrote: > Officially Django 1.8 doesn't support Python 3.5. In practice, I think it > probably works. See details in https://code.djangoproject.com/ticket/25502 > about why the 1.8 test suite doesn't pass with

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

I disagree with this system check and I would like to see it reverted before 1.9 final. I admit that my opinions here are skewed by the fact that I think model level validation is fundamentally not well implemented by Django at all. I work to a philosophy that there are two places where validation

Re: Why passing request, *args, **kwargs in dispatch method for generic views

This would cause too much churn for user code - there are millions of CBVs in the wild with customised dispatch/get/post/etc methods which expect these variables and perhaps use them directly. Unfortunately this ship has sailed. On 23 October 2015 at 14:45, Tom Christie wrote: > Although those v

Re: makemigrations --exit; exit status feels backwards from conventions

I see what you mean and the inherent problems with the design. However fundamentally the command you are running is "make some migrations", and the "I don't have any to make" step is clearly an error case, not a success case. In particular it would be very wrong for the real "I want to make some mi

Re: Fellow Report - October 17, 2015

This is awesome news for Django's status in enterprise, great work everyone. I hope something comes from the Microsoft Fellow concept, that would be brilliant. On 20 October 2015 at 15:18, Michael Manfre wrote: > > On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin < > aymeric.augus...@polytechn

Re: Django ORM query syntax enhancement

I don't think complex cases need to have __ equivalents, but I also dispute that long chains like that are necessarily a bad API, I don't find your option 1 particularly neat compared to option 2. Worth noting though that you've used a 2-valued function there which is not a lookup in the same sense

Re: moving the class-based View base class out of django.views.generic?

The idea has been discussed before and was rejected as needless code churn if I remember correctly. I'm afraid I can't remember when or where this discussion happened, it could have been an in person one at a sprint, I can't immediately find a record on this mailing list. Perhaps the fact it's come

Re: status of 1.9 release blockers

2 PM UTC-4, Tim Graham wrote: >>> >>> Status with 2 weeks and a weekend to go until alpha (Monday, September >>> 21). >>> >>> Planned major features for 1.9: >>> >>> PostgreSQL Full Text Search (Marc Tamlyn) >>> >>> I haven

Re: Adding a URL tagging feature

Some quick thoughts: - I'm unconvinced that selecting urls by a given type is a common use case - can you expand on that? - Implementing the detection and usage of tags as middleware seems not as nice as in decorators to me, especially as the middleware tree can be... unpredictable in its behaviou

Re: Password validation in Django revisited

I agree with Aymeric and Markus that createsuperuser should not validate strength of passwords when DEBUG is on. Having to use a secure password for development/test accounts is an unnecessary level of interference for users. I agree its safer to prevent using admin/admin in production and this is

Re: Django Admin New Look

I think this is a bit of a misnomer - if we include a jQuery without IE8 support we will start dropping IE8 from the CSS, our own custom javascript, new jquery features, community plugins will drop it etc etc. For 1.9 itself it may simply be a case of swapping in a different jQuery version, but it

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

Very happy with 1.6.11.x On 19 August 2015 at 16:31, Carl Meyer wrote: > On 08/19/2015 09:28 AM, Donald Stufft wrote: > > On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote: > >> In my ideal world, the version number would help convey unofficial-ness > >> a bit more strongly,

Re: Django Admin New Look

FWIW, I can see the arguments here and I would definitely like to move to jquery 2 and drop old browsers (aggressively). Actually having a solid browser support policy, a redesign etc would be a great time to do this as well. I can see we are likely to get some backlash, but maybe less than I thin

Re: draft blog post for Oracle help

Hi Jani, Thanks so much for sticking your hand up to help maintain Oracle! It is an important part of our ecosystem. Marc On 19 August 2015 at 07:45, Josh Smeaton wrote: > I'll also stick my hand up to be involved with the Oracle backend, but not > the Oracle GIS backend. I don't have a lot of

Re: Django ORM query syntax enhancement

I strongly agree with the third party approach. On 18 Aug 2015 17:49, "Anssi Kääriäinen" wrote: > I'm still thinking we shouldn't integrate any new query syntax into > 1.9. Instead lets make it easy to create 3rd party apps that offer > different querying syntax, and then lets see which solution

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

This is a deliberate approach you would use - South used it for years to customise syncdb. call_command is intended as a python API for testing `$ django-admin foo`. Two of your arguments are based around IDE usage, which I don't think is a valid argument, and the third is about reducing string ma

Re: Django Admin New Look

I don't know about schedule, but caniuse reports IE8 browser usage at 1.5%, more than IE9 or IE10. There's an argument we shouldn't be "enabling" people still using XP who are stuck on IE8, and this is a decreasing problem, but I don't think we can tie ourselves to Microsoft's support dates. On 1

Re: Django Admin New Look

+1 to the svg option. On 16 August 2015 at 20:00, elky wrote: > Hi guys, > > I made double work for vector icons - now we have Font and SVG icons. > Let's choose what to use. > > *Quoting my comment > from SVG > discussion here:* > > Well,

Re: Document/make public prefetch_related_objects

Nothing on `query` is public at the moment - I can see the merit in adding a public API to do this kind of work though. Can you open a ticket? https://code.djangoproject.com/newticket On 14 August 2015 at 13:26, Adam Johnson wrote: > *prefetch_related* is great, but it would be nice to be able t

Re: Generic forms (ModelForm) provide HTML for a form! Can generic views (DetailView) do same?

The problem with bootstrapping code like this is that it's great for a super simple project, but you instantly want to customise it for any project of any serious scope. It seems to me a perfect candidate for a simple external project, although you may wish to have a different API so it's more reu

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

I think Tim's suggestion of releasing the tag as a separate library which can be included in builtins answers Karen's concerns about updating 3rd party templates. I admit that is a case I had not considered. Marc On 7 Aug 2015 15:31, "Tim Graham" wrote: > I put together a pull request to see how

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

I agree that this is an anitpattern. I'm not fond of `get_updated_instance()` as a name, I'm not sure what the correct option is here. Arguably we should split save() into two parts - ModelForm.update_instance() and ModelForm.commit(). ModelForm.save() simply calls these two functions, with the lat

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

ifequal is technical debt in Django. It's a legacy way of doing things which we would not add now. Sure, we don't have to remove it, it isn't blocking us from doing anything else and it isn't broken, and it doesn't need much maintenance. However, as with all technical debt, it has a cost. It's add

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

I commented on the ticket - it's been redundant since Django 1.2 when the smart if was introduced. +1 to deprecating it. On 6 August 2015 at 17:15, Daniel Greenfeld wrote: > No modern project uses ifequal. No one recommends it. I argue it is taking > up valuable bytes in the project. Let's remov

  1   2   3   4   >