Re: Why was CommaSeparatedIntegerField Deprecated?

Hello, Storing a comma-separated list of integers in a text field in a SQL database is a really bad anti-pattern. That's a sufficient reason for Django to stop condoning it, which it did by providing that functionality out of the box. It was widely accepted (at least among the core team) that

Re: Why was CommaSeparatedIntegerField Deprecated?

I agree with the removal, it wasn't providing much value and was making it unclear as to what it actually aws. It could easily be mistaken by a beginner for a performant alternative to M2M models or something like django.contrib.postgres' ArrayField. Additionally it was weird that Django would

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

I also think that this should be handled at serialization level (form fields and (de)serialization framework). Claude -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and

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

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 binary NULL bytes in a CharField/TextField should result in an error condition. -tkc --

Re: Why was CommaSeparatedIntegerField Deprecated?

The CharField(validators=[validate_comma_separated_integer_list]) version is more explicit about how the database stores the data. In my mind, having a separate field could give the impression that the database uses a special field type or validation. Also, I think CommaSeparatedIntegerField

Why was CommaSeparatedIntegerField Deprecated?

I see that CommaSeparatedIntegerField is being deprecated, but I don't see why. I know I'm apparently late to the discussion, but after it 16 months I don't see any actual reasoning. I recognize that a CharField with the validator is functionally equivalent, but it takes a very handy field

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

I agree with Adam, we should never silently change submitted data at the model layer. My preference would be c), a form-level validation error that prevents saving. Luke On 15/05/17 19:11, Adam Johnson wrote: The problem with (a) - data with null bytes in strings from other databases can't

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

I imagine we won't hear of a use case until after the change happens and I'm some what strongly opposed to stripping potentially valid data from all databases because of a limitation of one. I'd be in favor of loaddata checking for null bytes and complaining when the backend doesn't support that

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

The problem with (a) - data with null bytes in strings from other databases can't be loaded into PG as per #28117 . The problem with (b) - data currently in databases in the wild will be modified upon save  (b) is incredibly destructive and could break an unknown number of applications whilst

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

Does anyone know of a use case for using null bytes in CharField/TextField? psycopg2 2.7+ raises ValueError("A string literal cannot contain NUL (0x00) characters.") when trying to save null bytes [0] and this exception is unhandled in Django which allow malicious form submissions to crash [1].

Re: Project report: Test infrastructure and property-based tests for Channels

Nice one!  Happy to see more Hypothesis tests, I've had great experience with it too. On 15 May 2017 at 11:54, wrote: > Hi everyone, > > I did some work on Channels' tests and testing infrastructure as part of > the Mozilla grant. This is my report. > > Channels consists

Project report: Test infrastructure and property-based tests for Channels

Hi everyone, I did some work on Channels' tests and testing infrastructure as part of the Mozilla grant. This is my report. Channels consists of five projects under the Django organization. First of all, I agreed with Andrew on versions of Django, Python and Twisted that we want to support

Re: Django and CSP strict-dynamic

Hi Ran Given that it's still a W3C draft I am not sure it should be added to Django core yet. I don't know of any official policy around what Django implements versus the W3C spec levels though. However it does seem that without a centralized solution for CSP nonces, they won't be usable with

Re: Review of DEP 201 - simplified routing syntax

Thinking about it some more: that is not the solution. Also, there are probably a couple of corner cases to consider (still: the same as for normal regular expressions): * What if the "keys" (named parameters) of a translated path differs from that of the original path? * What if the