Re: Making max_length argument optional

2016-02-28 Thread Josh Smeaton
This discussion started because a user wants to leave off max_length for 
postgres, which allows the max_length to be omitted right? Is there 
anything wrong with `from django.contrib.postgres.fields import CharField`? 
The postgres specific CharField will allow max_length to be optional 
without interfering with other database backends, confusing the 
implementation of the standard CharField, or having to make seemingly 
difficult or arbitrary decisions on what a default max_length could be.

FWIW, I'm starting to come around to a default max_length of 128 for the 
base CharField, mainly for the reasons Shai has described (mysql max byte 
length for unique indexes, 128 characters being enough for the majority of 
CharField use-cases). There definitely are some issues with *requiring* 
users to arbitrarily define a max_length without having knowledge of all 
the ways that 255 may be a problem across backends, or understanding why 
255 is even the theoretical max. If we were to consider this, I'd err on 
the side of changing CharField to default to max_length=128 rather than 
providing a new type.

Cheers

On Monday, 29 February 2016 06:07:04 UTC+11, Luke Plant wrote:
>
> Regarding custom sentinels for values vs custom sentinels for missing 
> values:
>
> The added complication in this case is migrations, and migrations that 
> support multiple Django versions, as is common in 3rd party apps. I haven't 
> thought through the implications, but it is vital to do so, because getting 
> it wrong can seriously hurt the adoption of a feature, and even the 
> adoption of a new version of Django.
>
> It may not be an option to say "for compatibility generate migrations 
> using the lowest supported Django versions", because sometimes old Django 
> versions have bugs that prevent migration generation. 
>
> We also need to consider the potential need for several different sentinel 
> values e.g. "unlimited" vs "database defined max length". 
>
> Luke 
>
> On 28 February 2016 14:38:40 GMT+00:00, "Loïc Bistuer" <
> loic.b...@gmail.com > wrote:
>>
>> There is a precedent to this (although it seems to happen at startup time 
>> rather than save time), we loop through all the connections and check that 
>> max_length has a value supported by their backend: 
>> https://github.com/django/django/blob/master/django/db/backends/mysql/validation.py.
>>
>> I don’t think we need to create a new sentinel value to mean “unlimited” 
>> when `max_length=None` works well semantically, if we want to keep the 
>> `max_length` value explicit we can just use `NOT_PROVIDED` as the kwarg 
>> default value. It is backwards compatible since `max_length=None` currently 
>> issues an error.
>>
>> Regarding the switch to a default value of 120 or so, I don’t have a strong 
>> opinion against it, but I think it’s an orthogonal problem to supporting 
>> unlimited varchar on backends that can handle it.
>>
>>  On Feb 28, 2016, at 6:50 PM, Florian Apolloner > > wrote:
>>>  
>>>  I do not see how blowing up on save is a good idea (especially not if we 
>>> ran model validation before). We do not do that for MySQL (at least not if 
>>> your project is configured properly, leaving issues with utf8mb4 out for 
>>> now) since our model form validation is able to use the supplied max_length 
>>> to inform the user that the data is invalid __before__ save.
>>>
>>
> -- 
> Sent from my phone 
>

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/02818c88-5b1c-41ee-be86-b48df0580a24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Query about inheritance clash in models

2016-02-28 Thread Dheerendra Rathor
I've a specific set of models:

class Parent(models.Model):
pass


class ChildA(Parent):
pass


class ChildB(Parent):
pass


Here Parent has fields:
(,
 ,
 )

and ChildB has fields:
(,
 )

so fields childa and childb are not inherited in ChildB, which is normal 
and expected. But adding a field '*childa*' in ChildB leads to E006 clash 
with a field in parent. But IMHO there should not be any clash reported as 
ChildBInstance.childa is not a valid field without the presence of local 
childa field. 

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e6376613-5dbf-4ba7-bc9a-81611f27d074%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Problems with cache.get_or_set behaviour

2016-02-28 Thread Raphael Michel
Hi,

I just experienced the following behaviour and would like to ask for
your opinion whether I should file this as a bug or whether this is
intended behaviour. I today had the pleasure to work with a crashed
memcached deaemon that could not restart because of a permission
problem. In this case, django, using the backend
'django.core.cache.backends.memcached.MemcachedCache'
behaved as follows:

>>> cache.set("foo", "bar")
>>> cache.get("foo")

So it fails silently and all get calls will return None. That is
sensible behaviour if one does not want cache calls to raise
exceptions. However, when using the new get_or_set() method from Django
1.9, I got

>>> cache.get_or_set('foo', default='bar')
0

This really is suprising to me. For any reasonable usage I can think of,
I would expect get_or_set() to return the specified default value.

When looking at the implementation of BaseCache.get_or_set, one finds
that in the case of the value not existing, the value is saved
and returned as follows:

if val is None:
val = self.add(key, default, timeout=timeout, version=version) 
if val:
return self.get(key, default, version)
return val

I assume that the last get() call is there to prevent a possible
race condition with other processes that is updating the key right
after our add statement.

However, if val is for some reason not evaluating to True, the result
of add() is being returned. add() is documented as returning True or
False and I don't think it makes any sense to return True/False from a
method that is expected to return a cached value or a default value.

I think we need a better behaviour of get_or_set() if add() fails but
I'm unsure how it exactly should look like, otherwise I would have
prepared a patch.

Cheers
Raphael

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160228232625.0e613084%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpFdwc2qwCzG.pgp
Description: Digitale Signatur von OpenPGP


Re: Making max_length argument optional

2016-02-28 Thread Luke Plant
Regarding custom sentinels for values vs custom sentinels for missing values:

The added complication in this case is migrations, and migrations that support 
multiple Django versions, as is common in 3rd party apps. I haven't thought 
through the implications, but it is vital to do so, because getting it wrong 
can seriously hurt the adoption of a feature, and even the adoption of a new 
version of Django.

It may not be an option to say "for compatibility generate migrations using the 
lowest supported Django versions", because sometimes old Django versions have 
bugs that prevent migration generation. 

We also need to consider the potential need for several different sentinel 
values e.g. "unlimited" vs "database defined max length". 

Luke 

On 28 February 2016 14:38:40 GMT+00:00, "Loïc Bistuer"  
wrote:
>There is a precedent to this (although it seems to happen at startup
>time rather than save time), we loop through all the connections and
>check that max_length has a value supported by their backend:
>https://github.com/django/django/blob/master/django/db/backends/mysql/validation.py.
>
>I don’t think we need to create a new sentinel value to mean
>“unlimited” when `max_length=None` works well semantically, if we want
>to keep the `max_length` value explicit we can just use `NOT_PROVIDED`
>as the kwarg default value. It is backwards compatible since
>`max_length=None` currently issues an error.
>
>Regarding the switch to a default value of 120 or so, I don’t have a
>strong opinion against it, but I think it’s an orthogonal problem to
>supporting unlimited varchar on backends that can handle it.
>
>> On Feb 28, 2016, at 6:50 PM, Florian Apolloner
> wrote:
>> 
>> I do not see how blowing up on save is a good idea (especially not if
>we ran model validation before). We do not do that for MySQL (at least
>not if your project is configured properly, leaving issues with utf8mb4
>out for now) since our model form validation is able to use the
>supplied max_length to inform the user that the data is invalid
>__before__ save.
>
>-- 
>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 stop receiving emails from it, send
>an email to django-developers+unsubscr...@googlegroups.com.
>To post to this group, send email to
>django-developers@googlegroups.com.
>Visit this group at https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/663F6FA1-1D09-4A21-928A-836157386253%40gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my phone 

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F5159BD5-23CD-46EF-92A7-EF10BCCE7890%40cantab.net.
For more options, visit https://groups.google.com/d/optout.


Re: Making max_length argument optional

2016-02-28 Thread Loïc Bistuer
There is a precedent to this (although it seems to happen at startup time 
rather than save time), we loop through all the connections and check that 
max_length has a value supported by their backend: 
https://github.com/django/django/blob/master/django/db/backends/mysql/validation.py.

I don’t think we need to create a new sentinel value to mean “unlimited” when 
`max_length=None` works well semantically, if we want to keep the `max_length` 
value explicit we can just use `NOT_PROVIDED` as the kwarg default value. It is 
backwards compatible since `max_length=None` currently issues an error.

Regarding the switch to a default value of 120 or so, I don’t have a strong 
opinion against it, but I think it’s an orthogonal problem to supporting 
unlimited varchar on backends that can handle it.

> On Feb 28, 2016, at 6:50 PM, Florian Apolloner  wrote:
> 
> I do not see how blowing up on save is a good idea (especially not if we ran 
> model validation before). We do not do that for MySQL (at least not if your 
> project is configured properly, leaving issues with utf8mb4 out for now) 
> since our model form validation is able to use the supplied max_length to 
> inform the user that the data is invalid __before__ save.

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/663F6FA1-1D09-4A21-928A-836157386253%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Making max_length argument optional

2016-02-28 Thread Shai Berger
On Sunday 28 February 2016 12:23:50 Florian Apolloner wrote:
> On Sunday, February 28, 2016 at 9:57:27 AM UTC+1, Luke Plant wrote:
> > We could also potentially add another sentinel like
> > DB_MAX_UNICODE_SAFE_LENGTH that works as you expect and is clearly
> > documented, for the sake of 3rd party apps, and comes with the caveat
> > that it produces different behaviour on different databases.
> 
> This is simply not an option as someone (I think Aymeric) already pointed
> out. Technically we do not know DB_MAX_UNICODE_SAFE_LENGTH till the call of
> model.save (since you can supply a using argument there), this means forms
> will never know the max length and could not perform any validation.

...or it could just mean we take the minimum of all defined databases (we would 
probably like to ask the routers for the db_for_write, but this requires the 
model to be defined already, so we can't do that).

No, this is still a problem: During the development, you decide to add a 
second database, and all of the sudden get migrations for the whole project, 
because the minimum over all defined databases changed. No good. So, I'd modify 
it to something like 

django.db.max_unicode_safe_length(database=DEFAULT_DB_ALIAS)

However, as I explained earlier, DB_MAX_UNICODE_SAFE_LENGTH is not a suitable 
default for max_length, so this is a little besides the point here.

On Sunday 28 February 2016 10:57:17 Luke Plant wrote:
> 
> Django should not be settling low arbitrary limits for the sake of a
> database I'm not even using, that's just crazy. Limits as high as 120 are
> not "big enough for anyone"

Defaults are not limits, and I don't think anybody setting a default expects 
that it would fit everyone. If we did, we'd consider removing the argument 
completely.

> Maximum field length is a critical value that must not be left
> to some default, because as soon as you come to interoperate with other
> systems, it *does* matter.
> 
> So, this needs to be explicit.

Erg, again -- nobody is suggesting to make users unable to set their own 
max_length; but many Django projects actually do not need interaction with 
other systems. These are probably the majority of projects, and even a bigger 
part of the projects done by beginners. We can remove an obstacle by saying, 
"unless you have reason to think otherwise, we suggest that 120 is a good 
length for a field intended to hold one line of text". It is an obstacle both 
because beginners these days are not used to think of length limits (since the 
programming language has a string type), and because they are quite likely to 
get it wrong (either make it too short, or go over MySql's limit of 191).

So, to summarise: I think the database-relative constants you proposed are a 
good idea; but I don't think any of them fits the bill of a default, and I do 
think a default will do more good than harm.

Shai. 


Re: Making max_length argument optional

2016-02-28 Thread Florian Apolloner
On Sunday, February 28, 2016 at 11:33:16 AM UTC+1, Loïc Bistuer wrote:
>
> I don't think this is a problem, we could validate that the backend 
> supports it during save then blow up if we detect it doesn't. I think we do 
> that for truncation on MySQL. If the model specifies something that the db 
> doesn't support it's a configuration problem, not a user validation 
> problem.  
>

I do not see how blowing up on save is a good idea (especially not if we 
ran model validation before). We do not do that for MySQL (at least not if 
your project is configured properly, leaving issues with utf8mb4 out for 
now) since our model form validation is able to use the supplied max_length 
to inform the user that the data is invalid __before__ save.

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/23ce2d62-45ed-48f7-9fc1-bc1eb4c47ef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Making max_length argument optional

2016-02-28 Thread Loïc Bistuer
I don't think this is a problem, we could validate that the backend supports it 
during save then blow up if we detect it doesn't. I think we do that for 
truncation on MySQL. If the model specifies something that the db doesn't 
support it's a configuration problem, not a user validation problem.  

Sent from my iPhone

> On Feb 28, 2016, at 6:23 PM, Florian Apolloner  wrote:
> 
> 
> 
>> On Sunday, February 28, 2016 at 9:57:27 AM UTC+1, Luke Plant wrote:
>> We could also potentially add another sentinel like 
>> DB_MAX_UNICODE_SAFE_LENGTH that works as you expect and is clearly 
>> documented, for the sake of 3rd party apps, and comes with the caveat that 
>> it produces different behaviour on different databases.
> 
> This is simply not an option as someone (I think Aymeric) already pointed 
> out. Technically we do not know DB_MAX_UNICODE_SAFE_LENGTH till the call of 
> model.save (since you can supply a using argument there), this means forms 
> will never know the max length and could not perform any validation.
> -- 
> 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 stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/b744bca5-e02e-411e-b9b6-971213aafaa3%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5F8A3D88-9CF4-4800-BA65-61D658EB34F2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Making max_length argument optional

2016-02-28 Thread Florian Apolloner


On Sunday, February 28, 2016 at 9:57:27 AM UTC+1, Luke Plant wrote:
>
> We could also potentially add another sentinel like 
> DB_MAX_UNICODE_SAFE_LENGTH that works as you expect and is clearly 
> documented, for the sake of 3rd party apps, and comes with the caveat that 
> it produces different behaviour on different databases. 
>

This is simply not an option as someone (I think Aymeric) already pointed 
out. Technically we do not know DB_MAX_UNICODE_SAFE_LENGTH till the call of 
model.save (since you can supply a using argument there), this means forms 
will never know the max length and could not perform any validation.

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b744bca5-e02e-411e-b9b6-971213aafaa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Making max_length argument optional

2016-02-28 Thread Luke Plant
Replying to this and the other emails in the thread:

Django should not be settling low arbitrary limits for the sake of a database 
I'm not even using, that's just crazy. Limits as high as 120 are not "big 
enough for anyone", and will cause problems. (I can give lots of examples). 
Maximum field length is a critical value that must not be left to some default, 
because as soon as you come to interoperate with other systems, it *does* 
matter. 


So, this needs to be explicit. 

We also need to cover the case of unlimited length Charfield for the databases 
that support it. This can be covered with a simple sentinel value 
UNLIMITED_LENGTH or similar. This is a 4th option not listed below. 

We could also potentially add another sentinel like DB_MAX_UNICODE_SAFE_LENGTH 
that works as you expect and is clearly documented, for the sake of 3rd party 
apps, and comes with the caveat that it produces different behaviour on 
different databases. 

Explicit is better than implicit etc., and in this case there is simply no 
sensible default behaviour that will cover all our use cases. 

Luke 






On 27 February 2016 12:55:23 GMT+00:00, Wim Feijen  wrote:
>Hi guys,
>
>I'd like to reach consensus about 
>https://code.djangoproject.com/ticket/14094
>
>In the discussion, I saw three options:
>
>1. Adding a default max_length = None, which may in practice differ per
>
>database backend.
>2. Adding a default max_length of a value which can be used across 
>databases. Lengths which have been mentioned are: 100, 128, 191 and 255
>
>characters and 4000 bytes.
>3. Keep everything as is, being as explicit as possible.
>
>Option 1 does not allow for apps and data to be reused across several
>apps 
>and several core developers do not support this idea.
>
>I'm in favour of option 2, because it makes for shorter code and more 
>importantly, it helps programmers choose a value which actually can be 
>reused across multiple databases (I didn't know about the possible
>limit of 
>191 characters on mysql! Did you?).
>
>I dislike how it is now (option 3), and I don't think it is beneficial
>here 
>to force people to be explicit, because people are now using arbitrary 
>values anyway. 255 is commonly used, the poll app of the Django
>tutorial 
>uses 200. Actually I believe it is a big mess in practice, I see
>defaults 
>of 100, 200, 255, 300, 1000 seemingly randomly used. For example, try 
>searching for CharField in your favourite apps or CMSes.
>
>In addition, adding a default for max_length still allows to be
>explicit 
>when it matters. And it makes life simple when it doesn't matter, and 
>simple is better than complex.
>
>What would be a good default then? I am in favour of making it as big
>as 
>possible while still working on all databases, which would either be
>191 of 
>255 in order to support mysql.
>
>Wim
>
>
>
>On Wednesday, 23 September 2015 19:02:20 UTC+2, Tom Christie wrote:
>>
>> I'm with Tom here.
>> Forcing `max_length` to always be set on CharField feels like the
>right 
>> decision. Having a default there seems unnecessary obscure, and more
>likely 
>> to lead to untested/unnoticed failure cases.
>> It *could* be that we'd allow `max_length=None` to explicitly turn
>off the 
>> validation, but I'm not sure if that's better than forcing developers
>who 
>> want unvalidated lengths to use TextField.
>>
>
>-- 
>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 stop receiving emails from it, send
>an email to django-developers+unsubscr...@googlegroups.com.
>To post to this group, send email to
>django-developers@googlegroups.com.
>Visit this group at https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/a2cfad14-4384-4118-bc28-d89099433ca5%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my phone 

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/EBD26DDE-B91E-4CB6-950F-8E67B98AB97E%40cantab.net.
For more options, visit https://groups.google.com/d/optout.


Re: Making max_length argument optional

2016-02-28 Thread Shai Berger
On Saturday 27 February 2016 23:57:19 Florian Apolloner wrote:
> Hi Shai,
> 
> On Saturday, February 27, 2016 at 4:44:18 PM UTC+1, Shai Berger wrote:
> > I think this is why we should be a little more cautious and go for 128 or
> > 100,
> > rather than "the current maximum all-backend-compatible value".
> 
> Which somewhat speaks for my point, cause we do not know if the next
> backend will need less than 100 chars (But I do agree that this is not
> likely). Tough I think that 100 (or 191 for matter) is a ridiculously low
> limit.

No, it isn't, if you think of the default char-field as a one-liner; even in 
code, we don't like lines longer than 120 chars... and the default should be 
friendly to backends with odd limitations, like Oracle's 8KB limitation on the 
sum of inline fields in a row (which means the "max acceptable for oracle 
charfield" value, which takes half of that, is a horrible default).

> In that sense, allowing max_length=None is probably the safest
> solution -- even though we do not know when database backends will crash on
> this, but we do not know this for text fields either currently.
> 

The SQL Standard has many deficiencies, but it's the best resource to work 
against in this regard; and the only unlimited-length character field it 
supports are LOBs (see [1]). While PG treats LOBs and char-fields the same, it 
is the exception rather than the rule, and I suspect it is part of the reason 
for why, when push comes to shove, it does not perform as well as the 
proprietary databases (don't get me wrong: I prefer it to any of them -- but 
it's a bit like comparing Python with C; you pay for expressivity with 
performance).

> > > That all said, if it were for me I'd deprecate CharField and only
> > > support TextField and give it an optional max_length (and a way to
> > > switch between TextArea and LineEdit for UI) -- but that is probably
> > > just because on Postgres there is no fundamental difference between them.
> > > From an enduser perspective, it is all text, the only difference is a
> > > constraint in length,
> > 
> > No, that's not the only difference. There's also an understanding that
> > CharField's are one-liners, that is, there is an implicit limitation
> > (usually
> > only enforced by UI) that newlines are not allowed in the text.
> 
> This is a leaky abstraction at best in my opinion. The "understanding" is
> mostly coined by the documentation in the sense that it mentions 
> for TextField and  for CharField. So it is kind of illogical to not
> allow a max_length on TextField.

I am not opposed to a max_length on TextField. I am opposed to setting the 
default string field in Django to an unlimited-length one.

> Even with model.full_clean there is no
> restriction aside from the length, in that sense a CharField behaves
> completely the same as TextField (database issues with index lengths etc
> excluded).

Databse issues with LOBs are plenty. PG has spoiled you :) Other databases do 
not do functional dependencies properly, and as a result, when you include a 
LOB in a grouping or uniqune query you get either database errors (Oracle) or 
terrible performance (everyone else except PG, AFAIK).

> 
> For example, I don't
> 
> > think there are many CharField's whose contents are interpreted as
> > markup.
> 
> Maybe, maybe not, I do not see how this makes a difference here though.
> (Same goes for Regex validation).
> 

The point was: They are regarded as different data types, have different 
operations etc.

> > In a user perspective, these are really different data types.
> 
> Which can be dangerous on it's own, I'd have to check, but I am pretty sure
> that nothing prevents the user from submitting newlines in a CharField.
> 

I, too would be surprised if something does. Agreed on "leaky abstraction".

> > I find your suggestion
> > analogous to a suggestion to remove IntegerField, because "it's just a
> > FloatField with a constraint on scale".
> 
> I'd suggest a DecimalField cause I do not like FloatFields either, but yeah
> ;)
> 
> Do not get me wrong, I somewhat agree with everything you say (in the end I
> think it is just a matter of taste) -- but I also think that explicit is
> better than implicit. 

I tend to agree with original posters in this thread -- explicit here just 
means "unnecessary room for error". Django is opinionated about database 
design, and I think we stand to gain by expressing on opinion about the 
default length of a "regular, one-line charfield".

> From a security point of view, I agree that length
> validation should be done whenever it makes sense [which is basically
> always, there is no point in allowing to post the maximum length of a
> TextField, especially not if it contains markup which you have to render
> again ;)], so a CharField with a default max_length seems like a good idea.
> On the other hand I think that it will make the distinction for new users
> even harder. Assume we change the CharField to have a default