Re: [RFC] Test methods filtering on tests run

Hi Antonio I have the same problem when running tests in Django's test suite. When there's a failure, I have to copy the test path, paste that, then copy the failing test. The entire path to the test isn't printed in the failures. I'd be a big fan of *some* kind of implementation that allows

Re: Tracking/logging bruteforcing, especially on admin accounts?

I understand the reasoning for "use the cache", but not every site has caching enabled, especially lots of smaller sites. A separate table could be used for tracking attempts, and cleared out per user on successful login attempt/ip address. This table would not need to be huge if designed with

Re: Possible Bug (MYSQL)

Hi Paulo, Have you opened a ticket on Trac for this yet? If not, please do so. This mailing list isn't really for verifying bugs. That said, does the query work if you provide an actual alias for the aggregate?

Re: Some thoughts on upgrade pain & deprecations.

I like the general idea. Going with your low tech solution we could have snippets for the X most popular test runners to treat warnings as errors. Perhaps ./manage test.py --warnings-as-errors or similar for the interface django provides. Every time django makes a release there are some that

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

Usually, yes. I'm not sure refresh_from_db works on related managers though. I ran into a similar issue writing unit test fixtures just last week and refresh_from_db didn't fix the problem. On Thursday, 9 June 2016 02:46:25 UTC+10, bliy...@rentlytics.com wrote: > > To be clear, I think the

Re: [ANNOUNCE] Django 1.10 and 1.9.9 released

Awesome! Thanks Tim, once again, for driving the release process on time. Love your work! On Tuesday, 2 August 2016 05:03:27 UTC+10, Tim Graham wrote: > > Django 1.10 and a bug fix release for the 1.9 series (1.9.9) are now > available: > >

Re: Implement form.as_table, as_ul, as_p using templates

I like the concept, though I haven't looked into the 4 points you laid out. I like the concept of the prefix you mentioned in the widget thread also - I'd love to see template packs as third party libraries that easily slot in (per form I think is crucial). I'm unsure of the proposed

Re: Renaming the postgresql_psycopg2 backend

I remembered a thing from Michaels talk at #DUTH. Let me present a use case for subclassing a backend: https://github.com/opbeat/django-postgres-readonly/blob/master/django_postgres_readonly/base.py I think if we end up favouring immediate deprecation, we could proactively find and inform

Re: Window expressions, #26608

First off, great work on this patch. I haven't given it much of a look over just yet unfortunately, but I'm trying to figure out where your issues are to help unblock. - I'm unsure how DEFAULT_INDEX_TABLESPACE is causing issues with your patch, can you explain a bit? - Explicit arguments in

Re: Modifying django.db.models.expressions.Func.as_sql() to allow `**extra_context` to be more useful

Avoid modifying self in `as_` methods if possible, even if you are going to restore state. See how some of the others work around needing to switch order etc here: https://github.com/django/django/blob/75f0070a54925bc8d10b1f5a2b6a50fe3a1f7f50/django/db/models/functions/base.py#L58 Short

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

I posted on the ticket before reading this thread. Whoops. As mentioned above it's impossible to always convert user input into the output provided by the database without doing a round trip, because there are driver data adapters, and django converters that both get a chance at modifying the

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

Hah, sure, exactly like that! Is it documented? Yes, yes it is. https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#using-argon2-with-django On Monday, 16 January 2017 20:12:23 UTC+11, Florian Apolloner wrote: > > > > On Monday, January 16, 2017 at 3:56:44 AM UTC+1,

Re: Google Summer of Code Updates - Class based indexes

Great work Akki! I know there hasn't been a lot of activity on this thread, but I'm really looking forward to using the new indexing features, and I bet there are a lot of others. It's also been fun to follow along with your progress as you've been pushing many smaller commits rather than one

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

ressions. What do you > think? > > > > [0] > https://github.com/django/django/commit/39f35d4b9de223b72c67bb1d12e65669b4e1355b > > > [1] https://github.com/django/django/pull/7088 > > > > On Wednesday, November 25, 2015 at 7:24:22 PM UTC-5, Josh Smeat

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

Hi Nicola, Without a lot of familiarity of SearchQuery, in particular, it looks like a bug to me. SearchQuery defines its own operators to work around the limitation in Combinable, but fails to take into account that when two SearchQuery instances are combined, you're returned a

Re: Django default PK type setting

A major issue with this would be the many apps out in the wild (and their tests!) that assume the pk is an integer, and do queries like .filter(pk=1). I don't like the idea of being able to enforce a different kind of pk type for apps that you haven't written yourself. Is there an actual

Re: Add past/present/future validations for Date and DateTime types

Jani is correct, you'll need to be careful to handle timezones if timezones are activated in SETTINGS. I can see value in a django-validators external package that you could expand upon with newer validators as they come up. But whether or not you want to build and maintain such a project is

Re: Django Box - A vagrant virtual machine for testing Django

Hi Tim, Doesn't SQL Server still require windows? I know there are plans from Microsoft to allow SQLServer running on Linux and drivers for linux to connect to SQL server, but I wasn't aware that those projects had materialized yet. This specific Vagrant image is an Ubuntu 16.04 virtual

Re: Django Box - A vagrant virtual machine for testing Django

> > I don't think a formal approval/proposal is needed to keep django box > under the Django org. For example, tools to help with Django development > don't require things like fixing security issues (I hope). As long as it's > working as semi-maintained, we can add a link to it from the

Re: Django Box - A vagrant virtual machine for testing Django

Hi all, a quick update. https://github.com/django/django-box now has a live compiled box available from https://atlas.hashicorp.com/djangoproject/boxes/django-box-1.11 What this means is that a minimal Vagrantfile can now be: Vagrant.configure("2") do |config| config.ssh.forward_agent = true

Re: Adding aggregates to ModelAdmin.list_display

I think I'm OK with `list_aggregates` because it implies a terminal queryset method which really restricts the members used to create that aggregation (the GROUP BY). Adding aggregates to existing list_display would require something *else* to refine the group by using `values()`. If

Re: request to reopen issue #23332 (using the dotted test name in test output)

I'd be very happy with a change to give the full dotted path to the test. I've copy/paste/modify/copy/paste hundreds of times, and it has always bothered me. Big +1. Agree with Tim that a push upstream would be good, but I'm all for solving this immediately in Django. I think the suggestion

Django Box - A vagrant virtual machine for testing Django

Hi All, At the PyCON AU sprints I began working on a project for building a vagrant virtual machine that would facilitate testing django, itself, against most of the databases that django supports. I forked https://github.com/jphalip/djangocore-box which was last updated about 3 years ago and

Re: Django Box - A vagrant virtual machine for testing Django

An interesting idea put forward by Ed Morley on the issues tracker (https://github.com/django/django-box/issues/12) is to merge the django-box project into the django main repository directly. The meat of the suggestion is copied below: > The ideal end state I see is that this project lives

Re: Django Box - A vagrant virtual machine for testing Django

> > I have my environment set up already, and I suspect this would hold for a > lot > of the more experienced developers here; do you think the new box will > improve > things for me? > > It probably won't make a big difference for those that already have environments setup for django

Re: MariaDB, official support

I believe Adam is (or is planning..) writing a DB backend that includes MySQL and MariaDB. Adam, did I remember correctly? If so, are you going to suggest adding this new backend to core as a replacement? Mads, perhaps you can help with this effort? Regards, On Tuesday, 15 November 2016

Re: Window expressions, #26608

uesday, November 22, 2016 at 11:50:17 PM UTC+1, Josh Smeaton wrote: > >> Thanks for picking this up. I've been wondering if Window expressions >> would be possible, and what limitations we might have to make based on our >> ORM. >> > > I was fortunate that the

Re: automating Django releases

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.org/pypi/bumpversion? After some trial and error, I seem to have a configuration that works with the existing version tuple in

Re: automating Django releases

Appreciate the security concerns of the jenkins boxes, but Jenkins is the obvious choice as a task runner. My first thought would be to bring up a special slave that was particularly hardened and walled off from the regular PR runners. I'm unsure how far access to the slave from the master

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

+1 to everything Baptiste and Ben have said. A bug in a CBV isn't a good argument for throwing away CBVs entirely. We should probably review patches that touch security systems quite a bit more thoroughly in the future - meaning more eyes rather than a single set of eyes spending more time. On

Re: Window expressions, #26608

Adam, are you thinking we should be adding something like Model.objects.window(), or just allowing Window-type expressions on backends that have a specific feature flag? Does the compiler need to get involved at all, or can we handle the full range of window expressions with the expressions

Re: SubQuery without using RawSQL

I like my bike sheds to be green. But I don't have a problem painting it red either. It seems red is the more popular colour, and that's fine. > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To

Re: segmentation fault while running test suite and possible bug in documentation.

Regarding the segfault it's likely related to this: https://code.djangoproject.com/ticket/24080 A bug in sqlite. On Thursday, 1 December 2016 20:39:26 UTC+11, Vimarsh Chaturvedi wrote: > > Hey guys, > > My first time posting here. > I downloaded the Django source code and I was going through

Re: Add custom autoreload file tracking options setting

> I am -0 to -1 for the debugger -- I've seen to many sites out there running with DEBUG=True, enabling RCE ootb seems to be pretty horrible. But it's so incredibly useful. And we already show the django debug page for errors with DEBUG=True that exposes enough secrets to allow a sufficient

Re: Should we add a dependency on the multipledispatch library, or vendor it?

It seems everyone that has chimed in prefers adding a dependency to vendoring. If there are alternative views please express them, but I'm going to recommend a dependency on the PR. Thanks On Tuesday, 3 January 2017 09:13:01 UTC+11, Josh Smeaton wrote: > > I agree with Tim. I think the

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

gt; Hi Josh, > > I do agree and support your idea's. How about pointing/recommend pyenv for > deployment in the doc? > > Thanks, > Asif > > On Sunday, January 8, 2017 at 4:38:52 PM UTC+6, Josh Smeaton wrote: >> >> I guess I don't really see how we'd be helping use

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

Apparently I'm dumb and didn't read enough. pyenv *does* take care of installation too. I'm not familiar enough with it (obviously..) to know whether or not we should be encouraging its use. On Sunday, 8 January 2017 22:33:44 UTC+11, Josh Smeaton wrote: > > I don't think pyenv is

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

I guess I don't really see how we'd be helping users in any meaningful way by supporting python 3.4 with Django 2.0. Django 2.0's defining change is dropping Python 2. We have no idea what else will land in 2.0. If we're trying to consider Enterprise users on "older" Distros: - 1.11 will be

Should we add a dependency on the multipledispatch library, or vendor it?

This has been briefly discussed before, but we need to form a consensus on whether we vendor or depend on the multipledispatch library for the following PR: https://github.com/django/django/pull/6395 The brief overview of the patch is to allow

Re: Should we add a dependency on the multipledispatch library, or vendor it?

I agree with Tim. I think the intent is to add dependencies as part of a feature, not specifically as part of another DEP (which I don't believe this feature needs). I don't think `overloading` was considered as a dependency, but it's interesting. If this feature doesn't make 1.11 (it

Re: is support for old cx_Oracle versions needed?

I'm unsure how others typically install cx_Oracle, but when I had to do it, it involved downloading and installing proprietary oracle drivers, making sure the headers were linked to the correct place, and then using pip. I don't think licensing allows OS maintainers to package up cx_Oracle and

Re: status of 1.11 release blockers

There are two specific patches that I'll be looking to merge before the feature freeze. I'd appreciate more eyes on the following if anyone has some capacity (and knowledge) for review. https://github.com/django/django/pull/7587 (Support server-side cursors for queryset iteration in database

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

> That said, it is pretty incredible that beginners can (still) install Django just about anywhere they have Python without compiling anything at all. I think this comment perfectly summarises my initial resistance to forcing this change. I think adding argon2_cffi to extra_requires could be

Re: re :GSOC 2017 Project - Test framework cleanup

At this late stage, it's highly unlikely that you'd be able to put together a successful proposal, and demonstrate your ability to execute on it. We encourage students to spend some time contributing before proposal stage, to give us a better idea of the ability to complete their tasks.

Re: Adding generated common table expressions

Thanks for bringing this up Ashley, and for all of the detail you provided. I'd certainly like to see CTEs make their way into Django, provided we could come up with a nice enough API. From the look of it, you've already got something that works with an okay API so I'm hopeful. I'd be very

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

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 an anti pattern (Q, F) that we shouldn't persist with. Aliasing V in the examples was my way of sneaking the idea through for those who chose to

Re: Pull requests waiting for review

I'd just like to add - thank you for the polite reminder! I know it can be very frustrating having patches sit around without any attention, and sometimes a good bump is and/or feels necessary. Doing so in a positive manner is very welcome. As a small reminder - the release of django 1.11

Re: DJANGO_SETTINGS_FILE

FWIW - I wasn't completely sure what the problem was you were relating or the solution you were proposing as a means to fix it. I came to this thread a bit late, and was probably overwhelmed by lots of text without reading and understand your first message in the thread well enough. The big

Re: assertRaises vs. assertRaisesMessage

We throw lots of ValueErrors and TypeErrors rather than creating new exception types all over the place. There's definitely an argument to be made that different exception types can be created. But I know that I've definitely run afoul of believing I was testing one error (assertRaises) when I

Re: Django test suite taking > 2 hours, gets stuck, have to Ctrl-C

While it's important to figure out the cause of the hang (and the horrendous runtime - 2 hours is far too long), in future you could try using the vagrant image https://github.com/django/django-box to run your tests. It comes loaded with all supported python versions and databases (except

Re: Project idea for GSoC page - Support for expressions in indexes

I think Markus is currently working on this idea, along with Ian Foote, who has contributed some precursor work to make the idea possible (deconstructed expressions). The current PR is https://github.com/django/django/pull/8056 On Saturday, 4 March 2017 05:39:11 UTC+11, akki wrote: > > Hi > >

Re: Problem with running tests with mysql database.

If you're having issues with specific environments and configuring all of the dependencies, you can try using https://github.com/django/django-box which is a Vagrant virtual machine running on Virtualbox. It has postgres, mysql, sqlite, and all of the pythons Django uses for testing. You could

Re: Automatic prefetching in querysets

I'm in favour of *some* automated way of handling these prefetches, whether it's opt-in or opt-out there should be some mechanism for protection. Preferably with loud logging that directs users to the source of the automated hand-holding so they have an opportunity to disable or fine tune the

Re: Automatic prefetching in querysets

> > It won't affect experienced users. They'll read the release notes, see > that this change has been implemented, and either go and delete a bunch of > prefetch_related() calls, grumble a bit and turn auto-prefetch off globally > or just file it away as another fact they know about the

Re: Admin list view counting

at. >> > >> > On 7 Aug 2017 08:03, "Adam Johnson" <m...@adamj.eu > >> wrote: >> > >> > +1 from me, I've spent long enough on those COUNT(*) queries at work. >> > >> > Is it worth putting this logic in Paginator so applicat

Re: Suggested documentation: PG server-side cursors used in .iterator() only work inside a transaction

Yes we should be documenting edge cases and unexpected results. We have a page that discusses some issues with server side cursors: https://docs.djangoproject.com/en/dev/ref/databases/#transaction-pooling-server-side-cursors Is there anyway we could make SSC work without a transaction? We'd

Admin list view counting

The admin list page performs a count(*) (twice!) when viewing the list page of a model. One of these counts can be disabled, but the pagination count can not be. On huge tables, this can be a massive performance issue. https://code.djangoproject.com/ticket/8408 was created to disable the

Re: Automatic prefetching in querysets

I think there's a lot right with your suggestions here Shai. It delivers better default behaviour for new projects, does not affect existing deployments, and seems pretty easy to enable/disable selectively at any level of the stack. My only concern would be libraries leaning on this behaviour

Re: Optimizing out unused annotations from count queries

I'd like to see this provided all bases were covered. I'll just list below the cases where I think it wouldn't be safe. - Filtered annotations - Annotations that join to anything other than a non-null foreign key: .annotate(local=F('related__field')) - Annotations that have a GROUP BY on fields

Re: Optimizing out unused annotations from count queries

if the same annotation above works on m2m joins or not. On Sunday, 20 August 2017 09:41:43 UTC+10, Tom Forbes wrote: > > Thanks for your reply Josh. Can you elaborate on why optimizing out ' > .annotate(local=F('related__field'))' would not be safe? > > On 20 Aug 2017 00:10, "J

Re: PostgreSQL aggregation and views through unmanaged models

> Therefore I'd favor we keep the current adjustment in the master branch as it > restores backward compatibility but I don't have strong feelings about reverting > it either if it's deemed inappropriate. Fixing the crash is the number 1 priority in my opinion, as it broke something that used

Re: Django directory design philosophy question

I agree that creating a "project" subdirectory inside the code directory, that's usually named the same thing, can be quite confusing. I'd like to see some kind of improvement here, but I haven't done the research to see what makes sense. The cognitive overhead of myproject/myproject,

Re: On ASGI...

FuncName() and FuncNameAsync() are common patterns in .NET land with async/await. The snake case translation would be funcname_async. From a quick scan, the JS world hasn't settled on a convention yet, though there is a bit of discussion about how to differentiate the names. Personally I don't

Re: Makemigrations hooks for third-party apps?

Can you provide the operations that users can then import into their migrations, similarly to how contrib.postgres provides the HStoreExtension operation [0]? The import could even be a function taking the extended model that returns the appropriate operation. This might be a bit more lo-fi

Re: Having a MongoDB connector for Django

I'm in agreement with most of the others - that Django should not strive to achieve compatibility with a bunch of different database types simply to open itself up to a larger user base. The cost you pay is a lack of functionality that takes advantage of the specific features granted by a

Custom Join Conditions

There's currently a patch https://github.com/django/django/pull/7560 for ticket https://code.djangoproject.com/ticket/27332 that implements custom join conditions. It was nearly ready for merge for 1.11 but slipped. There are some merge conflicts the author still needs to sort out, but nothing

Re: Refactoring the autoreloader

I'd just like to second (or third) an appetite for this or a similar change. Lately I've started to notice very poor performance (high cpu usage, slow shutdowns, etc) with the django dev server on my project. I've moved to runserver_plus/werkzeug with watchdog in the mean time but it'd be good

Re: Feature request: get_first_or_404

>From my experiences, all projects I've worked on have implemented get_first_or_none and get_first_or_404, and usually slightly differently. I think these shortcuts would make sense for Django. Interested to hear how common the usage would be from others on the list though. -- You received

Re: Additional PostgreSQL-specific functions

Hey Joey, I think you can create a new ticket for this function. If there is a way to approximate or implement this function in all 4 supported backends then that would be preferred. If it can only really be implemented in postgres, then document in the ticket why, and you can add the new

Re: Using server side cursors for values and values_list

I can't think of any reasons why not to do this off the top of my head. Have you looked into the code? Is there any technical reason you can see that might prevent chunked fetching from working there? On Saturday, 18 November 2017 03:27:13 UTC+11, Dražen Odobašić wrote: > > Hi, > > at the

Re: [off topic] Re: models.CalculatedField feature

Re-reading your reply, I think I've misunderstood your intent there (I didn't realise who the author was). Please disregard my previous reply. On Sunday, 19 November 2017 09:59:44 UTC+11, Josh Smeaton wrote: > > Until you want to aggregate or filter on that calculation, and p

Re: [off topic] Re: models.CalculatedField feature

Until you want to aggregate or filter on that calculation, and perform that filtering in the database rather than pulling back millions of records to do so in python. The database *must* be involved. On Sunday, 19 November 2017 06:32:48 UTC+11, ilya.ka...@jetbrains.com wrote: > > Such

Re: models.CalculatedField feature

Introducing an `as_python` to the expression API would probably work. It'd involve a lot of work to implement for all supportable expression types. Considering there are many 3rd party / user code expressions in the wild without as_python, we'd need to find a way to fail gracefully. However,

Re: models.CalculatedField feature

I too have seen computed properties poorly implemented as model functions/properties, only some of the time matched with an appropriate database selector. I think there's a lot of merit in the idea. I don't agree with reimplementing lookups/transforms/funcs to produce the python version of a

Re: Improving Backward Compatibility

Following on from Collin, another ticket that generated a large amount of code churn for little perceived benefit was https://code.djangoproject.com/ticket/21127 (enforce on_delete). I know there are many in the community that rail against any and all changes (I had an argument with such a

Re: Improving Backward Compatibility

the recent releases. > That's one feature per week or fortnight. We'd likely deprecate fewer > features if we had to reach consensus on django-developers every time. > > Best regards, > > -- > Aymeric. > > > > On 7 Dec 2017, at 04:09, Josh Smeaton <josh.smea...

Re: A Django Async Roadmap

I think most of what you've laid out sounds great and that pursuing async Django is in the projects best interests. The sync to async and async to sync wrappers that have come out of channels give me much more confidence that this project is doable in a reasonable amount of time with backwards

Re: Proposal: security enhancements

Most of this sounds really good. As Jacob mentioned, CSP can be quite scary, and sounds like something a novice could try to implement for "good security" and end up causing way more issues. I'd really like to see easy integration for report only mode, with controls that are harder to turn for

Re: #django-dev IRC channel

Yes - that's probably a good idea! On Thursday, 26 April 2018 05:11:33 UTC+10, Kenneth wrote: > > Hello, > > I was just curious about the #django-dev IRC Channel. > Currently, the only mention for this channel is on the Code of Conduct FAQ > page. >

Re: GLOBAL_PERMS

> > > - 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 consider adding a first class permission type,

Re: Change Local Memory Cache to Use LRU #28977

To lend some weight to this, I've implemented an LRU loc mem cache and have done some benchmarking. There are some graphs in the readme: https://github.com/kogan/django-lrucache-backend - which I've written a little about

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

I wasn't aware of this new feature Shai, thanks for pointing it out! For this particular case I'd prefer locking to be bound to a particular queryset rather than the database as a whole. I would also expect it to fail loudly when accessing a non-fetched related object (book.author), which can

Re: Change Local Memory Cache to Use LRU #28977

ck >> >> >> +1 to adding an option to disable the check as well. If you're using a >> LocMemCache in production, you probably don't care about compatibility with >> memcached, because you'll be using it for different types of data. >> >> On 5 January 2018 at

Re: Security middleware for django for insecure (http) connections

HTTPS is enough. Despite that, how would you handle the **client** doing decryption and encryption? I don't think this is an idea you should pursue, especially if your expertise is not in security. On Tuesday, 16 January 2018 10:03:00 UTC+11, Vishwas Mittal wrote: > > Hello everyone, > > I am a

Re: Fellow Report — January 12, 2018

Welcome, and nice work! I've seen some of the reviews you've made and you're straight into the deep end. On Saturday, 13 January 2018 04:01:06 UTC+11, Carlton Gibson wrote: > > Hi all, > > With help from Tim, Aymeric and Frank, I got started on the fellowship > this week. > (Thank you all!) >

Re: PR 9583 - Ticket 28643

I think having Left/Right is the right way to go. If there are opportunities to use slicing syntax, then they would resolve internally to those Expressions I would think. But that can be done separately, and have greater scope such as ArrayField in Simons example. On Friday, 19 January 2018

Re: Change Local Memory Cache to Use LRU #28977

>> penalty which the LRU-eviction policy will almost certainly improve >> compared with the current random-eviction policy. >> >> Grant >> >> >> On Mon, Jan 8, 2018 at 2:25 PM, Josh Smeaton <josh.s...@gmail.com >> > wrote: >> >>>

Should ModelField.choices accept a callable?

https://code.djangoproject.com/ticket/22837 was closed as invalid. It concerns itself with migrations being detected when model field choices (which may be dynamic) change. The workaround suggested is to pass a callable to choices with a link to https://code.djangoproject.com/ticket/13181.

Re: Should ModelField.choices accept a callable?

Migrations are mainly for tracking database changes. Model attributes not SQL related are pushed into the migrations also, presumably for the purposes of data migrations (maybe post-hoc justification, only a few people would actually know). Providing a callable still provides access to the

Re: Purpose of constant_time_compare?

I don't doubt that timing attacks can work in practise, but the link you've posted is not this. From the commit message: > There have not been any reports of attempted exploit in the wild. (The vulnerability was discovered through code review.) On Friday, 9 February 2018 09:27:03 UTC+11, Anssi

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018 21:08:31 UTC+11, Florian Apolloner wrote: > > Yeah, I am also worried about the churn for no gain in my eyes. If users > overuse mark_safe, they will overuse dangerously_trust_html too… > > On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote: >> >

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

vey the gravity of what this actually does. >> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be >> dangerous to trust the literal "Some Content", for example. >> >> Perhaps it could be something a bit more explicit. `no_escape(stri

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Or, since this isn't a template tag (facepalm) trusted_html(m.content) trust_html(m.content) On Friday, 23 February 2018 07:46:45 UTC+11, Josh Smeaton wrote: > > Yes I'm not a fan of the *dangerously...* names either. I'm still > somewhat wary of *trust_html* which is a *verb* and co

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

:04 PM UTC+1, Josh Smeaton wrote: >> >> Or, since this isn't a template tag (facepalm) >> > > Which raises a perfectly valid point: If we were to change this, we will > also need to come up with a new name for the "|safe"-filter. > -- You received this mes

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

I agree that the names are misleading and we should probably provide better names. I'm wary of deprecating the old names because it'll create a lot of churn (some of which would be the right thing to do). Maybe we could just alias and warn when using the old name, leaving a decision on

Re: Jenkins resources

Hi Matt, The django-box project[0] uses very close to the same ansible configuration that is used to configure all of the Jenkins slaves Django uses with the notable omission of an Oracle builder. Since the repos are separate, there has been some divergence on the Jenkins side of things, but

Re: Add Alias or annotations without group-by support?

2018 14:01:41 UTC+11, Cristiano Coelho wrote: > > It wouldn't work if you also want to order by the annotated value. > > El viernes, 9 de marzo de 2018, 8:27:36 (UTC-3), Josh Smeaton escribió: >> >> Would teaching filter() and friends to use expressions directly solve >

Re: Add Alias or annotations without group-by support?

Would teaching filter() and friends to use expressions directly solve your issue? You suggested using `alias` upthread, but that's only really required so you can refer to it later? Unless you wanted to refer to the field more than once, having each queryset method respect expressions should

Re: Shouldn't manage.py call python3 instead of python?

I think you're right and PEP394 is the relevant text: https://www.python.org/dev/peps/pep-0394/ TL;DR For now, *python* should refer to python2 and *python3* should be used to refer to python 3. On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote: > > The header of manage.py has:

Re: Shouldn't manage.py call python3 instead of python?

As a datapoint, I've seen roughly 1 person per week in #django IRC confused about specific startup exceptions due to them using python 2 rather than python 3 on Django >= 2.0. Unsure how many of these are due to the shebang. That said, it looks like there are no good solutions other than maybe

<    1   2   3   4   >