Re: Model Generation for CSV, XLS Files

Is django-import-export at all along the lines of what you're looking for? https://github.com/django-import-export/django-import-export > django-import-export is a Django application and library for importing and exporting data with included admin integration. > ... > support multiple formats

Re: HttpResponse headers interface

> > I would prefer "one right way to do it", but I also don't see a compelling > reason to deprecate the old interface. > For me, the reason to eventually deprecate the old interface is to help new developers learning a new codebase. When these developers have been taught to use response.headers

Re: HttpResponse headers interface

> I don't see a reason to deprecate it at all just now (though perhaps in _my_ ideal world that would happen at some point), but I'm not sure if it's worth keeping the current interface in the documentation at all? IMHO, we should eventually take the advice from the zen of Python "There should be

Re: Removing url() ?

+1 for deprecating for eventual removal. On Tue, May 5, 2020 at 9:33 AM Mariusz Felisiak wrote: > Hi, > >I think it's worth to deprecate url() and remove it in Django 4.0 > (that's why I accepted this ticket). Aymeric proposed Django 3.1 as a > beginning of deprecation period in a

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

Hi, I'd like to raise this topic for renewed discussion. I think it is time to begin deprecating the obsolete template tags. So +1 for removal. I had all but forgotten about the {% ifequal %} template tag and then eventually stumbled across it doing unrelated work. Upon rediscovering it as a

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

> I'd like to propose using this new full coverage of operation naming to remove the "auto_MMDD" behaviour +1 on this proposal. As you've noted in your blog post, I find the default auto name extremely opaque. Projects I work on normally have an internal policy to change these names to

Re: Use "raise from" where appropriate, all over the codebase

> > I think it's rare enough that personally, I would have liked to have a > > Flake8 / PyLint rule like that enforces it, and allow ignoring it > > with a comment. (As much as I hate Lint ignore comments.) > > That makes sense. And you know, flake8 supports plugins... a couple of > web searches

Re: Use "raise from" where appropriate, all over the codebase

+1 on chaining exceptions. I think the information is useful. > Is there anything we can do to control the way python displays them? I don't think we should do anything non-standard to display exceptions. Over time, Python programmers have become accustomed to how these exceptions are displayed.

Re: remove_stale_contenttypes doesn't remove entries for renamed apps.

An optional command line argument makes sense to me. +1 On Thu, Jan 2, 2020 at 2:11 PM Adam Johnson wrote: > I guess an optional kwarg would be okay then. > > On Thu, 2 Jan 2020 at 03:08, Javier Buzzi wrote: > >> @adam I agree with your points, about data loss, but this can still see >> this

Re: Redis cache support in core

The django-redis maintainer is currently in the process of stepping down and is moving away from the project. Should we propose moving it to Django's GitHub? For details, see https://github.com/niwinz/django-redis/issues/400 On the other hand, if there is interest in supporting a Redis backend in

Re: Proposal to format Django using black

> One thing we have not considered here is that after running black on Django a huge portion of our outstanding merge requests will have conflicts, some of which might be tricky to rebase. I’m not sure there is much we can do about that though. With a little bit of git-foo, this is actually not

Re: Proposal to format Django using black

> 2. there are issues with git history in doing "the great commit". Tools make a real difference here. I know everyone has their preferred tools and workflows, but there are tools that let one move through iterations of git blame. This is something I do quite frequently. Just one example, in

Re: Proposal to format Django using black

Big +1 I've used black in quite a few projects now and found it has greatly reduced the mental energy involved in code formatting while aligning all contributors expectations. I'm in favor of adding no configuration. That is, use black's default line length and string delimiters. IMO, the less

Re: Can we remove FILE_CHARSET?

> Is that always available these days? (I'd guess yes.) I too would guess yes. I believe any reasonably modern text editor will support UTF-8 and even likely default to saving in that encoding. I know mine does. > Is is something we want to impose? Not sure. Are there people doing > otherwise?

Re: Adding a database-agnostic JSONField into Django

> Anyone know of an SQLite implementation? A quick search shows the JSON1 extensions exists: https://www.sqlite.org/json1.html According to the release history (https://sqlite.org/changes.html) this was added in version 3.9.0 (2015-10-14). But I have no direct experience working with it. On

Re: Can we remove FILE_CHARSET?

> So Jon, are you basically saying that Vasili's concern shouldn't come up? Yeah, I think it shouldn't come up. But I'm not sure I fully understand Vasili's concern . Maybe if it was more specific with more details, I could better understand it. Django's documentation states:

Re: Can we remove FILE_CHARSET?

I'm the one that proposed this setting be removed. The settings is used in the following areas: > ./django/template/backends/django.py:23: options.setdefault('file_charset', settings.FILE_CHARSET) I suppose this is its main use case. The Django template engine defaults to loading files from

Re: HTML5 and XHTML5 documents

Django started adopting HTML5 features since before 2.1. I found changes as early as 1.11. From the release notes: https://docs.djangoproject.com/en/dev/releases/1.11/#miscellaneous > The checked and selected attribute rendered by form widgets now uses HTML5 boolean syntax rather than XHTML’s

Re: Are there use cases for storing null bytes in CharField/TextField?

On Mon, May 15, 2017 at 10:30 AM, Tim Chase wrote: > On 2017-05-15 08:54, Tim Graham wrote: > > Does anyone know of a use case for using null bytes in > > CharField/TextField? > > Is this not what BinaryField is for? It would seem to me that > attempting to store

Re: should nonexistent template filter arguments resolve to string_if_invalid rather than raise VariableDoesNotExist?

Just my opinion, but I think raising an exception is more helpful to developers and will result in fewer unnoticed bugs. More generally, I know the template engine has a history of silently converting unknown variables to string_if_invalid but this is more harmful than helpful in my experience.

Re: CITextField base class

> Does it make sense to add a CICharField for these cases or you can just override the form/admin. In a past Django developers discussion, Aymeric suggested building this functionality with a mixin so the citext type could apply to multiple DB fields which would then affect how the form field is

Re: CITextField base class

I believe this will also change the default form widget from to . Is that also desired? IME, I most often use citext with short text inputs, such as email. On Wed, Feb 8, 2017 at 7:11 AM, Tim Graham wrote: > Since that's a release blocker for a feature that hasn't been

Re: AbstractBaseUser.set_unusable_password() why a random string instead of an empty string?

> > And the commit that implements it: https://github.com/django/ > django/commit/aeb1389442d0f9669edf6660b747fd10693b63a7 > > Cheers, > Alex > > > On Thu, 20 Oct 2016 at 08:20 Jon Dufresne <jon.dufre...@gmail.com> wrote: > > When set_unusable_password() is called on a use

AbstractBaseUser.set_unusable_password() why a random string instead of an empty string?

When set_unusable_password() is called on a user object, the user's password is set to a random string starting with "!" [0]. The "!" is then used by is_password_usable() [1] to determine that this password isn't usable. My question is, why is a random string used instead of an empty string? An

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

> Has anyone relied on the exception silencing behavior as a "feature" when using {% include %}? Not here. +1 on deprecating the silencing behavior. I have created a ticket [0] and PR [1] so others may get a sense of the bigger picture change and how it could affect Django. Feedback welcome.

Re: Proposal: Use HTML5 boolean attribute for checked on checkbox/radio inputs

> I was wondering if it causes any HTML validation problems for other doctypes? True. A strict validator for XHTML will flag HTML5 syntax as an error. It isn't a part of the XHTML spec. From my testing it seems like modern browsers can handle this, but you're right, validators will catch it. >

Proposal: Use HTML5 boolean attribute for checked on checkbox/radio inputs

Hi, I would like to propose that Django renders the "checked" attribute of checkbox and radio inputs using the HTML5 boolean style attributes. Django has supported HTML5 boolean attributes since 1.8 [0]. It has used them internally for the "disabled" attribute since 1.9 [1] and the "required"

Re: change commit message format to present tense?

On Fri, Jun 24, 2016 at 10:48 AM, Carl Meyer wrote: > To be clear, the recommended git style is not present tense, it is > imperative mood. So it should _not_ be "Fixes #12345 -- Regulates the > frobnicator", it should be "Fix #12345 -- Regulate the frobnicator." > Do you have

Re: Would a patch to add allow_empty_strings=True to CharField be accepted?

Would recent commit solve the problem for you: https://github.com/django/django/commit/267dc4a2882182f71a7f285a06b1d4b15af0 Relevant ticket: https://code.djangoproject.com/ticket/4136 On Fri, Jun 17, 2016 at 3:27 AM, Luke Benstead wrote: > Hi! > > We've recently hit upon

New CharField attribute to handle CharField(null=True, blank=True, unique=True) in model forms

Hi, Occasionally I'll need to define a CharField on a model that is unique but also allow blank values. At the database level, this is easily handled by storing NULL for the blank values. (Storing the empty string multiple times will result in a DB unique constraint violation.) This use case has

Re: Add HTML5 required attribute on form widgets

On Thu, May 5, 2016 at 11:29 AM, Collin Anderson wrote: > If anyone is running into hidden required fields preventing forms from > submitting (like me), I've been using this jQuery code for a somewhat-hacky > quickfix: > > $(':hidden[required]').removeAttr('required') > >

Re: Add HTML5 required attribute on form widgets

On Wed, Mar 30, 2016 at 7:01 AM, Alex Riina wrote: > What's the plan for formsets with extra? > > I could see the required only getting applied to the first min forms but > I'm not sure there is an actual workable case there. It seems like it will > get too messy with

Re: Deprecating User.is_anonymous ?

> Do we know of any custom user models with this unconventional behaviour? FWIW, I have a project with the following code snippet: --- class AuthenticatedAnonymousUser(AnonymousUser): def is_authenticated(self): return True class

Add HTML5 required attribute on form widgets

Hi, I'm working on ticket #22383 to add the HTML5 required attribute to form widgets. The hope is this will add an additional level of validation at the client side. The feedback provided to the user is much faster than a server round trip. This is something I've done manually in my own

% vs {} string formatting for public APIs

Hi, I noticed that some Django public APIs use the % old-style string formatting while others use the {} new-style formatting. For example: {} style * success_url [0] (Converted to {} in 1.8) * format_html [1] % style * ValidationError [2] * related_name [3] Is this difference intentional?

Re: remove support for unsalted password hashers?

On Tue, Feb 2, 2016 at 10:35 AM, charettes wrote: >> That hasher, being the fastest non-plaintext hasher around, is quite >> useful >> when running tests: it allows login checks to be performed much faster. > > This argument came up a couple of time in the past and from what

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

On Wed, Dec 2, 2015 at 10:29 AM, Flávio Junior wrote: > Also, I can't imagine now why, but some > developer might want to disable referer header altogether, and can easily do > so by setting policy to No Referrer. Why is it unimaginable that I may want to maximize

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

welcome change that aligns the exit > status of --exit with long-standing convention. > > > Thanks, > Chris > > > > On Wednesday, October 21, 2015 at 10:20:09 AM UTC-5, Jon Dufresne wrote: >> >> On Tue, Oct 20, 2015 at 9:29 PM, Gavin Wahl <gavi...@gmail.com>

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

On Tue, Oct 20, 2015 at 9:29 PM, Gavin Wahl wrote: > In your case, successfully creating a migration indicates a failure. Only if the --check flag is on. The --check flag indicates that one is explicitly checking that all model changes have migrations. A non-zero exist

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

On Tue, Oct 20, 2015 at 1:48 PM, Jon Dufresne <jon.dufre...@gmail.com> wrote: > On Tue, Oct 20, 2015 at 1:18 PM, Shai Berger <s...@platonix.com> wrote: >> On second thought, I take that back. >> >> As is evident from the discussion Jon cited[1], the --exit fl

makemigrations --exit; exit status feels backwards from conventions

Before posting this, I've read through the full thread "sys.exit(1) from makemigrations if no changes found" at . I fully agree with the spirit of the change. I already find the feature useful in CI. However, after using

Re: Fate of sql* management commands

On Sun, Mar 29, 2015 at 4:57 PM, Russell Keith-Magee wrote: > It would probably be *possible* to refactor manage.py sqlall to use the new > table creation logic; but the question would then be "why do you want it"? Speaking from experience, I have found these commands to

Re: Refactor year, month, day lookups?

On Tue, Mar 24, 2015 at 9:24 PM, Josh Smeaton wrote: > Hi, > > Firstly (and least importantly) opening a PR makes it a lot easier to review > code, especially when there are lots of commits. A [WIP] pull request is > common and useful. If you get a chance, you should open

Refactor year, month, day lookups?

Hi, I have been spending some time learning and investigating the custom lookups feature that was newly introduced in 1.7 [0]. While investigating, I wanted to learn by example so I started looking through the Django code. In the end, I didn't find many examples. However, I did notice that there

Re: CSRF REASON_NO_REFERER with meta referrer tags

On Wed, Feb 4, 2015 at 5:59 AM, Erik Romijn <erom...@solidlinks.nl> wrote: > > On 03 Feb 2015, at 16:44, Jon Dufresne <jon.dufre...@gmail.com> wrote: >> However some URLs are accessed by a unique URL >> containing a nonce without a login. Login is not an option for t

Re: CSRF REASON_NO_REFERER with meta referrer tags

On Tue, Feb 3, 2015 at 11:45 PM, Aymeric Augustin <aymeric.augustin.2...@polytechnique.org> wrote: > Le 4 févr. 2015 à 03:31, Jon Dufresne <jon.dufre...@gmail.com> a écrit : >> >> Prevent the application from being served in an attacker's iframe: use >> X-Frame

Re: CSRF REASON_NO_REFERER with meta referrer tags

On Tue, Feb 3, 2015 at 7:09 PM, Josh Smeaton wrote: > Just quickly, HSTS[0] and X-Frame-Options[1] are supported and recommended > in the security documentation already. As you point out though, HSTS isn't > yet a full solution, and, frankly, it scares me a little.

Re: CSRF REASON_NO_REFERER with meta referrer tags

On Tue, Feb 3, 2015 at 2:12 PM, Paul McMillan wrote: > The referer check is primarily there to help make users who choose not > to use HSTS safer. > > Without HSTS, a mitm can set CSRF cookies (e.g. by serving an HTTP > page emulating your domain in an iframe on a different

Re: CSRF REASON_NO_REFERER with meta referrer tags

On Tue, Feb 3, 2015 at 11:52 AM, Aymeric Augustin wrote: > You can fix that problem by saving some authentication info in the user's > session, most likely with a custom auth backend — see django-sesame for an > example of how to do this. Then redirect

Re: CSRF REASON_NO_REFERER with meta referrer tags

On Tue, Feb 3, 2015 at 11:39 AM, Aymeric Augustin <aymeric.augustin.2...@polytechnique.org> wrote: > Le 3 févr. 2015 à 16:54, Jon Dufresne <jon.dufre...@gmail.com> a écrit : >> Assuming this MITM already has the correct CSRF value, what is >> stopping this MITM from ad

Re: CSRF REASON_NO_REFERER with meta referrer tags

On Tue, Feb 3, 2015 at 6:18 AM, Aymeric Augustin wrote: > We're talking about a MITM of an HTTP connection that is then used for > posting a form over an HTTPS connection. Check the comment in the first > message of this thread for details. Assuming this MITM

Re: CSRF REASON_NO_REFERER with meta referrer tags

On Tue, Feb 3, 2015 at 1:31 AM, Aymeric Augustin wrote: > Your request boils down to "make Django's CSRF protection of HTTPS > pages vulnerable to MITM attacks" which isn't acceptable. Please. That is a very straw-man like way to have a discussion. The first

CSRF REASON_NO_REFERER with meta referrer tags

Hi, In the interest of security, I recently started using meta referrer tags in my HTML [0]. To share the least amount of data as possible, I opted for the "none" policy [1]. This new HTML5 feature breaks Django POST views. The reason: the CSRF mechanism checks that, when serving over HTTPS,

Re: Setting database default values in migrations (postgres)

On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin wrote: > So, bear in mind that you can easily set these defaults yourself in a > migration with RunSQL if you need them for legacy purposes; that way they'll > get applied Absolutely. I effectively have such a system in place at

Re: Setting database default values in migrations (postgres)

On Fri, Oct 31, 2014 at 6:48 AM, Shai Berger wrote: > Peter, you said you're "interested in getting database migrations to support > setting database-level default values", but you haven't said why; unless > there's a convincing use-case, I'm going to be -1 on this (per the new

Re: Should reverse() return a Unicode string?

On Fri, Sep 19, 2014 at 5:13 AM, Tom Christie wrote: > One point of clarity is that we ought to return the same type for each of > `reverse`, `request.path`, `request.get_full_path`, `request.path_info`, and > the values in the `request.GET` dictionary. Given that, the

Should reverse() return a Unicode string?

Hi, In my Django application, I'm making a strong attempt to always deal with Unicode strings at the application layer. Byte strings are only handled at the protocol layer -- sending data out on the "wire". If my application tests if an object is a string, I'll use isinstance(obj, unicode)

Re: Querying across FK produces too many OUTER JOINs (1.6) or FieldError (1.7)

On Fri, Jul 4, 2014 at 7:44 PM, Anssi Kääriäinen wrote: > I wasn't able to reproduce this - are you sure the query is exactly the same > both on 1.6 and 1.7? Are models are set up correctly before generating the > query? If after double-checking you still get the error,

Re: Querying across FK produces too many OUTER JOINs (1.6) or FieldError (1.7)

> ... and this is more appropriate on django-users Sorry, but I felt like I was reporting information interesting to developers. 1.) Wrong JOIN type (OUTER vs INNER) producing inefficient queries 2.) FieldError in 1.7 where there wasn't one in 1.6 If these are of no interest, I will not

Re: Querying across FK produces too many OUTER JOINs (1.6) or FieldError (1.7)

On Fri, Jul 4, 2014 at 2:54 PM, Javier Guerra Giraldez wrote: > what purpose does the "container__item__previous__isnull=True" > argument serve here? To filter on the initial item in the list. I'm looking for flag=True *only* on the first item in the list. flag=True could be

Querying across FK produces too many OUTER JOINs (1.6) or FieldError (1.7)

Suppose I have the following models: --- class Container(models.Model): pass class Item(models.Model): container = models.ForeignKey(Container) previous = models.ForeignKey('self', null=True) current = models.BooleanField() flag = models.BooleanField() --- Item represents a

Re: modelformset_factory and unique_together don't always validate unique fields

On Thu, Jul 3, 2014 at 10:48 AM, Florian Apolloner <f.apollo...@gmail.com> wrote: > > > On Thursday, July 3, 2014 3:03:25 PM UTC+2, Jon Dufresne wrote: >> >> > Also, even if we find a place to show >> > the errors, the user is (usually) in no p

Re: modelformset_factory and unique_together don't always validate unique fields

On Thu, Jul 3, 2014 at 7:02 AM, Tim Graham wrote: > Another suggestion: could you include the field on the form but use a > HiddenInput widget? I could, but originally I wanted to avoid this. The container_id should not be editable by the user. Including this in the form

Re: modelformset_factory and unique_together don't always validate unique fields

On Thu, Jul 3, 2014 at 1:12 AM, Florian Apolloner wrote: > To me this is no shortfall but expected and good behaviour, including other > fields in the validation (i.e. fields not on the form) would be very > confusing. Where would errors show up? Right now unique

modelformset_factory and unique_together don't always validate unique fields

I'm reporting this to the developers list as I feel this shows a shortfall in (to me) expected behavior. I'm not sure this is exactly a bug or simply a use case the unique validation wasn't designed for. Basically, sometimes I want to create model formsets that use a limited number of model

Re: DRY date_format and datetime objects

On Sun, Mar 9, 2014 at 10:36 AM, Jon Dufresne <jon.dufre...@gmail.com> wrote: > On Sun, Mar 9, 2014 at 10:05 AM, Aymeric Augustin > <aymeric.augus...@polytechnique.org> wrote: >> Furthermore, there are two reasons why I'm against making this change >> in Djang

Re: DRY date_format and datetime objects

On Sun, Mar 9, 2014 at 10:05 AM, Aymeric Augustin wrote: > ... assuming your application is only ever used in one locale. We cannot > make this assumption for all Django applications. > > -MM-DD is unambiguous and consistent. You could argue that >

Re: DRY date_format and datetime objects

On Sat, Mar 8, 2014 at 6:39 PM, Shai Berger wrote: > Can you present your use-case in more detail? Why do you have to format the > dates explicitly in Python code, rather than use the template filter "date"? Sometimes this happens in __unicode__ methods for models. A model may

DRY date_format and datetime objects

Hi, I am using Django 1.6. I find myself using date_format semi-regularly to convert datetime objects to strings in the DATE_FORMAT format. I feel like I am repeating myself quite a bit and need to remember to do this, else I receive the format -MM-DD, which, in my opinion, is less pleasant

Re: Question about password salt and encryption

On Sat, Jun 15, 2013 at 2:24 PM, Luke Plant wrote: > 2) Should Django's security be improved by an additional salt that isn't > stored in the database? > > Regarding number 2, this is not likely to happen quickly, due to > backwards compatibility issues, and the need to

Re: Question about password salt and encryption

Thank you Luke. On Sat, Jun 15, 2013 at 12:55 AM, Luke Plant wrote: > The reason that SECRET_KEY is not used is that SECRET_KEY is used for > other applications which might require key cycling - typically for short > lived data where key cycling isn't going to cause too

Question about password salt and encryption

I am in the process of porting an existing application to use Django. I am modifying the authentication portion of the existing application to be compatible with Django's authentication system. One thing that struck me, Django appears to use a single per user salt, stored in the database.