Re: Making max_length argument optional

[Podrigal, Aron]

Aymeric, thanks for clarification, my bad I missed that one. We will be
using max_length=255 or 128 for the default as Shia proposed.

BTW how is this handled by integer_ranges on per database backend? Also,
using checks_framework can we validate this setting?
On Sep 22, 2015 1:49 AM, "Aymeric Augustin" <
aymeric.augus...@polytechnique.org> wrote:

> Hi Aron,
>
> On 22 sept. 2015, at 03:12, Podrigal, Aron 
> wrote:
>
> > And for your concern, there will be a MaxLengthValidator added to the
> validators to validate the users input does not exceed the database
> backends maximum length just like when you set max_length explicitly.
>
> This isn’t possible in a project that uses multiple databases, say
> PostgreSQL and Oracle. The form layer cannot say which length is correct
> because it has doesn’t know in what database the data will be saved.
>
> --
> Aymeric.
>
>
>
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2FF1A3B1-0167-4E52-9F99-EB5BDD6B81C5%40polytechnique.org
> .
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yi_6TK5bB-rd5d7XZJAwyKRPQthS%2BM1C0vZyqVK%2BY1d9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Aymeric Augustin]

Hi Shai,

On 22 sept. 2015, at 04:22, Shai Berger  wrote:

> I'd solve the "need to specify" issue by setting a default that is 
> intentionally smaller than the smallest (core) backend limitation, say 128.

I would pick the highest value supported by all core backends (probably 255
for MySQL, unless there’s something about indexes and multi-byte encodings
that I forget) in order to minimize the need to increase it.

If we go for a lower value, I suggest to pick something totally arbitrary like
100 to make it clear that it isn't a technical limitation.

> I"d make an "unlimited length text field" a new type of field, explicitly not 
> supported on MySql and Oracle; and I'd suggest that it can live outside core 
> for a while. so we may get an impression of how popular it really is.

The main use case seems to be “VARCHAR() on PostgreSQL”. What about defining a
slight variant of CharField in django.contrib.postgres that merely makes the
max_length argument default to None?

-- 
Aymeric.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/17C37814-E6A8-4E27-B590-BF9FFF42CB20%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Aymeric Augustin]

Hi Aron,

On 22 sept. 2015, at 03:12, Podrigal, Aron  wrote:

> And for your concern, there will be a MaxLengthValidator added to the 
> validators to validate the users input does not exceed the database backends 
> maximum length just like when you set max_length explicitly.

This isn’t possible in a project that uses multiple databases, say PostgreSQL 
and Oracle. The form layer cannot say which length is correct because it has 
doesn’t know in what database the data will be saved.

-- 
Aymeric.




-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2FF1A3B1-0167-4E52-9F99-EB5BDD6B81C5%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Josh Smeaton]

> While this makes sense, the use of TextField is also for the purpose of 
having rendered a text widget for ModelForms. So we should allow a 
max_length of None for both.

If you use Oracle (or mysql I guess), you get used to manually changing the 
form field widget to be a TextArea if that's what you want for your UI. 
Using TextField with Oracle is a horrible experience unless you must have 
it.

On Tuesday, 22 September 2015 12:33:49 UTC+10, Aron Podrigal wrote:
>
>
>
> On Mon, Sep 21, 2015 at 10:26 PM, Christophe Pettus  > wrote:
>
>>
>> On Sep 21, 2015, at 7:22 PM, Shai Berger > > wrote:
>>
>> > I'd solve the "need to specify" issue by setting a default that is
>> > intentionally smaller than the smallest (core) backend limitation, say 
>> 128.
>>
>> I'd be OK with that.  Not wild, because I think that having to specify 
>> max_length is good discipline, but not everyone likes oatmeal, either. :)
>>
>
> OK, this satisfies me too. 
>
>>
>> > I"d make an "unlimited length text field" a new type of field, 
>> explicitly not
>> > supported on MySql and Oracle; and I'd suggest that it can live outside 
>> core
>> > for a while. so we may get an impression of how popular it really is.
>>
>> We kind of have that: TextField.  The problem is that TextField has very 
>> different performance characteristics and implementation details on 
>> PostgreSQL vs MySQL and Oracle.  I don't think we need another: If you know 
>> you are running on PostgreSQL, you just use TextField, and if you are 
>> either targeting a different database, or writing one that runs on multiple 
>> ones, you probably want CharField with a specific length.
>>
>
> While this makes sense, the use of TextField is also for the purpose of 
> having rendered a text widget for ModelForms. So we should allow a 
> max_length of None for both.
>  
>
>>
>> --
>> -- Christophe Pettus
>>x...@thebuild.com 
>>
>> --
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3542EAF7-C2EB-4A4B-94F4-8C7A9EC4AC4E%40thebuild.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Aron Podrigal
> -
> '101', '1110010', '110', '1101110'   '101', '110', 
> '1100100', '1110010', '1101001', '1100111', '111', '1101100'
>
> P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/86d12c55-934a-4491-9429-583a1e2dcd12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANNOTATIONS WORKING

[Josh Smeaton]

Hi Varun,

If you believe you've found a bug, then please open a ticket on trac 
here: https://code.djangoproject.com/newticket

We can then discuss on the ticket whether or not the bug exists, and I can 
try to help you figure out how to fix it.

Thanks,

On Tuesday, 22 September 2015 07:06:03 UTC+10, varun naganathan wrote:
>
> hey.I am new to django development.i asked the question with the intention 
> of understanding a bug im trying to solve.i want to understand the process 
> of how to go through the internals of django to solve a bug.The bug i was 
> looking at included the usage of ".annotate".Even after going through the 
> django codebase i could not figure out how exactly is it working.I just 
> wanted guidance in how to proceed towards django development.
>
> On Monday, September 21, 2015 at 11:22:50 PM UTC+5:30, Florian Apolloner 
> wrote:
>>
>> THERE IS NO NEED FOR ALL CAPS IN THE SUBJECT.
>>
>> That said, please write to django-users, this mailing list is for the 
>> development of Django itself…
>>
>> On Monday, September 21, 2015 at 1:16:38 PM UTC+2, varun naganathan wrote:
>>>
>>> Can anyone please explain how annotate works in django??
>>> I'm new to developing django and Ive been going through the source code 
>>> and am unable to figure out how it parses the query and modifies it 
>>> accordingly.
>>> any help would be appreciated
>>>
>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/06eeae46-93fe-4dae-a308-31a304440a3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Josh Smeaton]

Is the concern that 100,000 iterations is too slow on python < 2.7.8 but is 
acceptable on versions after that? If so, then we wouldn't be breaking < 
2.7.8, we'd just be reducing the performance profile, right? We could call 
out such things in the release notes. 

On Tuesday, 22 September 2015 02:12:35 UTC+10, Donald Stufft wrote:
>
> On September 21, 2015 at 10:55:57 AM, Collin Anderson (cmawe...@gmail.com 
> ) wrote: 
> > Is there an external library for Python < 2.7.8? I know we don't 
> officially 
> > support the system version of python in RHEL/CentOS and Ubuntu, but I 
> bet 
> > we could get away with requiring a dependency for those old versions of 
> > Python in new versions of Django. 
> >   
>
>
>
> https://cryptography.io/en/latest/hazmat/primitives/key-derivation-functions/#cryptography.hazmat.primitives.kdf.pbkdf2.PBKDF2HMAC
>   
>
>
> - 
> Donald Stufft 
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e78ccff0-7c15-4cb6-b74b-229060bfaa42%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

On Mon, Sep 21, 2015 at 10:26 PM, Christophe Pettus 
wrote:

>
> On Sep 21, 2015, at 7:22 PM, Shai Berger  wrote:
>
> > I'd solve the "need to specify" issue by setting a default that is
> > intentionally smaller than the smallest (core) backend limitation, say
> 128.
>
> I'd be OK with that.  Not wild, because I think that having to specify
> max_length is good discipline, but not everyone likes oatmeal, either. :)
>

OK, this satisfies me too.

>
> > I"d make an "unlimited length text field" a new type of field,
> explicitly not
> > supported on MySql and Oracle; and I'd suggest that it can live outside
> core
> > for a while. so we may get an impression of how popular it really is.
>
> We kind of have that: TextField.  The problem is that TextField has very
> different performance characteristics and implementation details on
> PostgreSQL vs MySQL and Oracle.  I don't think we need another: If you know
> you are running on PostgreSQL, you just use TextField, and if you are
> either targeting a different database, or writing one that runs on multiple
> ones, you probably want CharField with a specific length.
>

While this makes sense, the use of TextField is also for the purpose of
having rendered a text widget for ModelForms. So we should allow a
max_length of None for both.


>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3542EAF7-C2EB-4A4B-94F4-8C7A9EC4AC4E%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yj28u18uT8b0V5DunyfyC2fe5m1ftnTLrfEo8nE3U1UVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Christophe Pettus]

On Sep 21, 2015, at 7:22 PM, Shai Berger  wrote:

> I'd solve the "need to specify" issue by setting a default that is 
> intentionally smaller than the smallest (core) backend limitation, say 128. 

I'd be OK with that.  Not wild, because I think that having to specify 
max_length is good discipline, but not everyone likes oatmeal, either. :)

> I"d make an "unlimited length text field" a new type of field, explicitly not 
> supported on MySql and Oracle; and I'd suggest that it can live outside core 
> for a while. so we may get an impression of how popular it really is.

We kind of have that: TextField.  The problem is that TextField has very 
different performance characteristics and implementation details on PostgreSQL 
vs MySQL and Oracle.  I don't think we need another: If you know you are 
running on PostgreSQL, you just use TextField, and if you are either targeting 
a different database, or writing one that runs on multiple ones, you probably 
want CharField with a specific length.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3542EAF7-C2EB-4A4B-94F4-8C7A9EC4AC4E%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Shai Berger]

Hi,

I just went over the ticket and thread. There seem to be two concerns mixed 
here.

Most people who expressed support for the feature have just been annoyed at 
the need to specify a length when all they want to say is "a reasonably short 
string" or "a one-liner".

Aron, on the other hand, seems to aim mostly at an option to remove the length 
limitation completely.

I can see why "unlimited" makes sense, sometimes, on Postgres. But I think 
it's a bad default for general use, especially in reusable apps.

I also don't like the interpretation of "unlimited" as "backend-specified max", 
basically for the reasons Christoph mentioned (same schema on different 
backends), and also because I'm concerned about the performance implications 
of unnecessarily large fields and about the ambiguity of introspection.

I'd solve the "need to specify" issue by setting a default that is 
intentionally smaller than the smallest (core) backend limitation, say 128. 
I"d make an "unlimited length text field" a new type of field, explicitly not 
supported on MySql and Oracle; and I'd suggest that it can live outside core 
for a while. so we may get an impression of how popular it really is.

My 2 cents,
Shai.

Re: Making max_length argument optional

[Christophe Pettus]

On Sep 21, 2015, at 7:10 PM, "Podrigal, Aron"  wrote:

> There is actually another reason to not have to specify a max_length which 
> was mentioned earlier, is because most of the time you don't care about that 
> and is just tedious to have to specify that when you can get it to work 
> without it. Default values has always been here for that reason.

I'm afraid I must disagree that "most of the time you don't care about it."  I 
certainly do.  I'm always reasonably careful to specify a max_length that 
corresponds to the underlying data.

There's no "sensible" default for max_length.  It entirely depends on the data 
you are storing.  Picking a backend-specific max_length means that application 
writers now have no idea how much data the CharField can store: 
1GB-ish-depending-on-encoding?  255?  4000 or something less depending on 
Oracle's encoding?

Requiring a max_length is enforcing a good practice.
--
-- Christophe Pettus
   x...@thebuild.com

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/46F57CA5-459B-4B2D-B610-EF3FF1190256%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

There is actually another reason to not have to specify a max_length which
was mentioned earlier, is because most of the time you don't care about
that and is just tedious to have to specify that when you can get it to
work without it. Default values has always been here for that reason.

On Mon, Sep 21, 2015 at 10:03 PM, Christophe Pettus 
wrote:

>
> On Sep 21, 2015, at 6:12 PM, "Podrigal, Aron" 
> wrote:
>
> > The reason for having a max_length set to None, is because that's what I
> want for my database columns to be in Postgres, and for MySQL I don't care
> about the length too, I always choose varchar(255) just for because it is
> required for the database backend.
>
> Well, that's not a practice I think we need to go to great lengths to
> support.  If you *really* *must* have a VARCHAR field without a length, you
> can always use a migration to strip it off.
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/95E76678-2FAB-46B4-B830-0AC877886EE4%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yi2mc4bVompW8kL_QYdr80kWEr42r7sj9pOjnitc%3DV0%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Christophe Pettus]

On Sep 21, 2015, at 6:12 PM, "Podrigal, Aron"  wrote:

> The reason for having a max_length set to None, is because that's what I want 
> for my database columns to be in Postgres, and for MySQL I don't care about 
> the length too, I always choose varchar(255) just for because it is required 
> for the database backend.

Well, that's not a practice I think we need to go to great lengths to support.  
If you *really* *must* have a VARCHAR field without a length, you can always 
use a migration to strip it off.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/95E76678-2FAB-46B4-B830-0AC877886EE4%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?

[Shai Berger]

Hi,

(edited a little)

On Tuesday 22 September 2015 03:07:37 Tim Graham wrote:
> On Monday, September 21, 2015 at 6:52:08 PM UTC-4, Paulo Maciel wrote:
> > Why confused? It's optional, if the developer wanna put null=True, he
> > could.
> > I don't think need to be putting null = True, this is redundant. If this
> > is a standard behavior, you need not be explicit.
>
> As Yo-Yo mentioned, there are valid use cases for blank=True, null=False,
> and I believe having one field option implicitly change another actually
> adds complexity instead of simplifying things.
> 
Even if we did accept some sort of implication there, it would be the other 
way around. "null=True" is a feature of the model field itself, while 
"blank=True" only sets the default behavior of form fields generated for it. It 
would make some sense for null=True to imply blank=True, but not as you 
suggest.

Shai.

Re: Making max_length argument optional

[Podrigal, Aron]

The reason for having a max_length set to None, is because that's what I
want for my database columns to be in Postgres, and for MySQL I don't care
about the length too, I always choose varchar(255) just for because it is
required for the database backend. And for validation of the max length, I
would argue that just like validating the max I want to validate the min.
In short, I want to have more control on my database schema.

And for your concern, there will be a MaxLengthValidator added to the
validators to validate the users input does not exceed the database
backends maximum length just like when you set max_length explicitly. Also
you can manually provide a validator if your user input validation rule is
to be less than the db maximum length. See [1]. The
MaxLengthValidator should actually only be added if there isn't yet
any MaxLengthValidator explicitly given.


[1]
https://github.com/django/django/blob/9a97f847109d377995a2312e3d569a3dad1da677/django/db/models/fields/__init__.py#L1102-L1109


On Mon, Sep 21, 2015 at 8:52 PM, Christophe Pettus  wrote:

>
> On Sep 21, 2015, at 5:49 PM, "Podrigal, Aron" 
> wrote:
>
> > Different schemas?? Schema will always be different for each database
> backend according to its datatypes.
>
> It means if you specify a CharField without a length, you don't know how
> many characters it can accept without error.  That doesn't seem like
> something we should make a change to accept.
>
> > I really don't understand what your concern is.
>
> The current behavior seems entirely reasonable, and I'm not sure I
> understand what problems it is causing.  Specifying a maximum length on a
> CharField is not just a random habit; it should be done as a way of sanity
> checking the value to a reasonable length.  Sometimes, that's natural to
> the data (there are no 50 character telephone numbers or 5000 character
> email addresses), sometimes it's just a way of making sure that something
> bad doesn't get into the database.
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/15D5715A-3EF5-4CC0-830C-8EB714424335%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yjm-wLsR4neSjM5q_-9d5LNOfDXUmnyAan1zB2emdR%3D_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.9 release blockers

[Tim Graham]

Let's consider master feature frozen for now. There are two more patches 
I'd like to merge before we cut the 1.9 branch.

#21231 -- Enforced a max size for POST values read into memory
https://github.com/django/django/pull/3852
Status: Needs final code reviews and probably some doc enhancements (docs 
could possibly be deferred until after alpha). Florian & Shai, as you've 
been taking the lead on reviewing this, please let us know your thoughts.

#24509 -- Added Expression support to SQLInsertCompiler
https://github.com/django/django/pull/5324 
Status: Josh working on some doc enhancements now, I will review in the 
morning.

On Friday, September 18, 2015 at 10:03:45 AM UTC-4, Marc Tamlyn wrote:
>
> Sorry everyone :(
>
> On 18 September 2015 at 15:01, Tim Graham  > wrote:
>
>> The major features are officially deferred. Let's try for the feature 
>> freeze by end of day on Monday and the alpha release on Tuesday.
>>
>> There aren't any critical blockers at this time. Jani hasn't completed 
>> the Oracle GIS work, but this isn't a must-have for alpha.
>>
>>
>> On Saturday, September 12, 2015 at 7:50:31 PM UTC-4, Tim Graham wrote:
>>>
>>> With 1 week to go until alpha:
>>>
>>> I haven't heard anything from Marc or Preston on the major features from 
>>> the last mail.
>>>
>>> Jani continues to give updates in #django-dev about his progress on 
>>> getting the Oracle GIS backend working. Things seem to be on track for 
>>> finishing up by alpha.
>>>
>>> On Friday, September 4, 2015 at 3:55:22 PM UTC-4, Tim Graham wrote:

 Status with 2 weeks and a weekend to go until alpha (Monday, September 
 21).

 Planned major features for 1.9:

 PostgreSQL Full Text Search (Marc Tamlyn)

 I haven't seen any recent activity on the pull request, nor have I 
 heard anything from Marc about it.
 https://github.com/django/django/pull/4726

 Custom indexes (Marc Tamlyn)

 I haven't see any work on revising the DEP, so this seem out for 1.9.

 https://github.com/django/deps/pull/6

 Template-based widget rendering (Preston Timmons)
 I think the code is in fairly good shape. It seems the main work left 
 to is to write documentation.
 https://github.com/django/django/pull/4848

 Release blockers:

 - Add Oracle support for new-style GIS functions
 https://code.djangoproject.com/ticket/24688
 Owner: Jani Tiainen
 Status: In progress (from recent IRC discussion, it sounds like Jani is 
 making good progress)

 On Monday, August 24, 2015 at 3:40:22 PM UTC-4, Tim Graham wrote:
>
> Time to kickoff the progress tracker for the next major release!
>
> Here's the status with 4 weeks to go until alpha (September 21).
>
> Release blockers:
>
> - Add Oracle support for new-style GIS functions
> https://code.djangoproject.com/ticket/24688
> Owner: Jani Tiainen
> Status: In progress (test suite runs on Oracle now, which is an 
> improvement from last week)
>
>
> Other tickets tagged for 1.9:
>
> - No way to create tables for apps without migrations
> https://code.djangoproject.com/ticket/25144
> Status: Awaiting replies to "Keeping apps without migrations?" thread 
> for a decision on what to do
> Mailing list thread: 
> https://groups.google.com/d/topic/django-developers/qHP4ZQSK9xM/discussion
> Owner: pending discussion
>
> - Replace admin icons images by inline SVG
> https://code.djangoproject.com/ticket/20597
> Owner: elky
> Status: In progress
>
> - Update tutorial screenshots for new admin theme
> https://code.djangoproject.com/ticket/25200
> Status: to be done after previous item is completed
>
>
> Relevant ticket filters:
>
> Release blockers affecting master:
>
> https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker
>
> Tickets tagged 1.9:
>
> https://code.djangoproject.com/query?status=assigned=new=~1.9
>
 -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/261819cf-fb09-4e6b-b162-d2cdc76f3807%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 

Re: Making max_length argument optional

[Christophe Pettus]

On Sep 21, 2015, at 5:49 PM, "Podrigal, Aron"  wrote:

> Different schemas?? Schema will always be different for each database backend 
> according to its datatypes.

It means if you specify a CharField without a length, you don't know how many 
characters it can accept without error.  That doesn't seem like something we 
should make a change to accept.

> I really don't understand what your concern is.

The current behavior seems entirely reasonable, and I'm not sure I understand 
what problems it is causing.  Specifying a maximum length on a CharField is not 
just a random habit; it should be done as a way of sanity checking the value to 
a reasonable length.  Sometimes, that's natural to the data (there are no 50 
character telephone numbers or 5000 character email addresses), sometimes it's 
just a way of making sure that something bad doesn't get into the database.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/15D5715A-3EF5-4CC0-830C-8EB714424335%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

Different schemas?? Schema will always be different for each database
backend according to its datatypes. I really don't understand what your
concern is. In any case your free to specify a max_length=N where it will
be the same for all backends.

On Mon, Sep 21, 2015 at 8:42 PM, Christophe Pettus  wrote:

>
> On Sep 21, 2015, at 2:49 PM, "Podrigal, Aron" 
> wrote:
>
> > We're not talking about representing all CharFields as TEXT, it is about
> choosing a sane length as the default for the varchar datatype.
>
> But that means notably different schemas on different backends, for not an
> obvious gain.  What's the benefit there?
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/FE33D41D-30F7-497F-9E2D-4ABC396E4BE6%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yg%2Be6Oco8D74Fd1K4QWrZwv8itp5nNZc75y3uoDiKMmwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Christophe Pettus]

On Sep 21, 2015, at 2:49 PM, "Podrigal, Aron"  wrote:

> We're not talking about representing all CharFields as TEXT, it is about 
> choosing a sane length as the default for the varchar datatype.

But that means notably different schemas on different backends, for not an 
obvious gain.  What's the benefit there?

--
-- Christophe Pettus
   x...@thebuild.com

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/FE33D41D-30F7-497F-9E2D-4ABC396E4BE6%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?

[Tim Graham]

As Yo-Yo mentioned, there are valid use cases for blank=True, null=False, 
and I believe having one field option implicitly change another actually 
adds complexity instead of simplifying things.

On Monday, September 21, 2015 at 6:52:08 PM UTC-4, Paulo Maciel wrote:
>
> Why confused? It's optional, if the developer wanna put null=True, he 
> could.
> I don't think need to be putting null = True, this is redundant. If this 
> is a standard behavior, you need not be explicit.
> I think this should be optional, by default these fields should always be 
> null=True implicitly.
> Django's philosophy is to simplify.
>
> Em quinta-feira, 17 de setembro de 2015 10:23:49 UTC-3, Tom Christie 
> escreveu:
>>
>> That kind of implicit behavior would just leave things more confused.
>> Writing a few characters less code isn't a benefit if it comes at the 
>> expense of making the behavior less obvious.
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e6d1503d-1707-4715-8e15-c8cc268d372c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?

[Paulo Maciel]

Why confused? It's optional, if the developer wanna put null=True, he could.
I don't think need to be putting null = True, this is redundant. If this is 
a standard behavior, you need not be explicit.
I think this should be optional, by default these fields should always be 
null=True implicitly.
Django's philosophy is to simplify.

Em quinta-feira, 17 de setembro de 2015 10:23:49 UTC-3, Tom Christie 
escreveu:
>
> That kind of implicit behavior would just leave things more confused.
> Writing a few characters less code isn't a benefit if it comes at the 
> expense of making the behavior less obvious.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9c5b75d3-d993-4871-800e-d25b6b72731c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

We're not talking about representing all CharFields as TEXT, it is about
choosing a sane length as the default for the varchar datatype. So if you
would not specify max_length, for MySQL it would be varchar(255), for
oracle it would be varchar(4000 / bytes_per_char_for NLS_CHARACTERSET) and
for PostgreSQL it would be just VARCHAR without a length.

I would like some comments / help for how to compute the size of the string
in bytes for Oracle. unless we can opt for using a default length of 255
for all database backends besides postgres.

On Mon, Sep 21, 2015 at 2:46 PM, Christophe Pettus  wrote:

>
> On Sep 21, 2015, at 9:54 AM, 'Tom Evans' via Django developers
> (Contributions to Django itself) 
> wrote:
> > I'm slightly worried from a DB point of view.
>
> I have to agree, even speaking as PostgreSQL geek.  While VARCHAR and TEXT
> are implemented the same way in PostgreSQL, conceptually they're different
> things.  I don't think the relatively modest benefit of having no default
> justifies the problems that result on other platforms.
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/DA725AF8-A7CA-449F-B92A-0BCCDB124AD6%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yiKv1iop5nJ%2BkH444L4iJKCATHt%2Bdkd%3DFiC872mgYUVmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANNOTATIONS WORKING

[varun naganathan]

hey.I am new to django development.i asked the question with the intention 
of understanding a bug im trying to solve.i want to understand the process 
of how to go through the internals of django to solve a bug.The bug i was 
looking at included the usage of ".annotate".Even after going through the 
django codebase i could not figure out how exactly is it working.I just 
wanted guidance in how to proceed towards django development.

On Monday, September 21, 2015 at 11:22:50 PM UTC+5:30, Florian Apolloner 
wrote:
>
> THERE IS NO NEED FOR ALL CAPS IN THE SUBJECT.
>
> That said, please write to django-users, this mailing list is for the 
> development of Django itself…
>
> On Monday, September 21, 2015 at 1:16:38 PM UTC+2, varun naganathan wrote:
>>
>> Can anyone please explain how annotate works in django??
>> I'm new to developing django and Ive been going through the source code 
>> and am unable to figure out how it parses the query and modifies it 
>> accordingly.
>> any help would be appreciated
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dce981bb-5a83-4126-ac15-01b6b407a0b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Christophe Pettus]

On Sep 21, 2015, at 9:54 AM, 'Tom Evans' via Django developers (Contributions 
to Django itself)  wrote:
> I'm slightly worried from a DB point of view.

I have to agree, even speaking as PostgreSQL geek.  While VARCHAR and TEXT are 
implemented the same way in PostgreSQL, conceptually they're different things.  
I don't think the relatively modest benefit of having no default justifies the 
problems that result on other platforms.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/DA725AF8-A7CA-449F-B92A-0BCCDB124AD6%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANNOTATIONS WORKING

[Florian Apolloner]

THERE IS NO NEED FOR ALL CAPS IN THE SUBJECT.

That said, please write to django-users, this mailing list is for the 
development of Django itself…

On Monday, September 21, 2015 at 1:16:38 PM UTC+2, varun naganathan wrote:
>
> Can anyone please explain how annotate works in django??
> I'm new to developing django and Ive been going through the source code 
> and am unable to figure out how it parses the query and modifies it 
> accordingly.
> any help would be appreciated
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9641377a-1bd0-4cb0-93ac-59a5486d9ed1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

['Tom Evans' via Django developers (Contributions to Django itself)]

On Mon, Sep 21, 2015 at 5:21 PM, Paulo Maciel
 wrote:
> +1 max_length optional
>

I'm slightly worried from a DB point of view. Whilst blessed
PostgreSQL supports variable length fields seemingly without issues,
other DB engines (MySQL, for instance), have significant performance
issues using a TEXT field versus a VARCHAR field - particularly on
indexed fields, it must do a row read to retrieve data, rather than
use an indexed value.

Remember that VARCHAR columns can be fully indexed, whilst TEXT
columns can only have the first N (specified by user) characters
indexed, and reading the data will always require a row read, even if
the text is shorter than the indexed size.

In the ticket, it states that

"""
If I read the oracle docs correctly, specifying a length is mandatory
for VARCHAR2, and the maximum is 4000 bytes. For MySQL, it's 65K
bytes, for PostgreSQL and SQLite it's very large.
"""

For MySQL, it is 64k (65,535 bytes is *not* 65k!), and that is not the
whole story - 64k is the maximum record size - all your columns must
fit within that limit, not just one column in the record.

http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

I'm slightly concerned as a MySQL/MariaDB user that this will lead to
"reusable" apps that are not performant on MySQL. Given that we
(generally) let Django define the database tables based upon models,
it seems much more important that the definition is correct and high
performing in all supported backends than to avoid choosing what
database columns you require in the tables - after all, that is what
the TextField is for, to allow the programmer to specify "this is an
arbitrary length text field".

I'm all for DB engines that support arbitrary length varchar fields to
use that when you specify a TextField. I'm very not keen on having
MySQL represent the majority of char fields as TEXT because no-one
could be bothered to specify the appropriate length.

Cheers

Tom

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1KnWTfw6Hk18Buu3hZOiHVB2RW4JNk_PFdaO_QoLK6CmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Paulo Maciel]

+1 max_length optional

Em quarta-feira, 29 de julho de 2015 01:27:59 UTC-3, Aron Podrigal escreveu:
>
> Hi, 
>
> I am using postgresql and I prefer my VARCHAR columns not to have a length 
> limit. Is there any particular reason why max_length arg to fields is 
> required. If for  compatibility with other database backends we can have 
> some sane default if it is None. 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b0cfde2d-195d-487b-90de-55219030f898%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Donald Stufft]

On September 21, 2015 at 10:55:57 AM, Collin Anderson (cmawebs...@gmail.com) 
wrote:
> Is there an external library for Python < 2.7.8? I know we don't officially
> support the system version of python in RHEL/CentOS and Ubuntu, but I bet
> we could get away with requiring a dependency for those old versions of
> Python in new versions of Django.
>  


https://cryptography.io/en/latest/hazmat/primitives/key-derivation-functions/#cryptography.hazmat.primitives.kdf.pbkdf2.PBKDF2HMAC
 

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.56002c64.29abc385.ead3%40Draupnir.home.
For more options, visit https://groups.google.com/d/optout.

ANNOTATIONS WORKING

[varun naganathan]

Can anyone please explain how annotate works in django??
I'm new to developing django and Ive been going through the source code and 
am unable to figure out how it parses the query and modifies it accordingly.
any help would be appreciated

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ff019dfd-b7b0-4550-9650-57822af49ba1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: request for API review of streaming responses additions

[Yann Fouillat]

Hi, sorry for the delay,

On Monday, 7 September 2015 16:05:35 UTC+2, Aymeric Augustin wrote:
>
> Hello,
>
> 2015-09-07 10:00 GMT+02:00 Yann Fouillat 
> :
>
>> First I will say that most of this pull request is a port of 
>> https://github.com/django/django/pull/1037 which I ported more or less 
>> blindly.
>>
>
> As far as I can tell, this previous PR was never discussed on 
> django-developers. Someone threw the code on GitHub, that's all; you can't 
> make any assumptions about its suitability for inclusion in Django. Usually 
> we discuss how a feature should be implement, look for consensus, and then 
> submit the code ;-)
>  
>
> 1) About the general API design
>>>
>>> This patch adds 7 new “stream” public APIs that duplicate the current 
>>> “render”
>>> APIs. Adding a stream=False argument to the current APIs would be a more
>>> lightweight alternative. Passing stream=True would enable the streaming
>>> behavior. Was this alternative considered and if so, why was it rejected?
>>>
>>
>> I'm not sure it was considered, but I don't think it would really be less 
>> intrusive. The documentation would be better, but the code would be less 
>> readable with a lot more conditions in the rendering logic (as opposed to 
>> keeping the same logic in stream and joining the streams in render).
>>
>
> The point of Django is to handle the painful stuff in the framework to 
> make our users' lives easier. If we need to write slightly more complicated 
> code to improve the API, that's just fine.
>
> Also I doubt there will be many more conditions. The higher levels will 
> just pass the stream keyword argument to the lower levels and eventually to 
> the template engine. The only conditional should be be `response_class = 
> StreamingHttpResponse if stream else HttpResponse`.
>
> I'm aware of the irony of me making this argument. I set a bad precedent 
> when I added StreamingHttpResponse. I didn't think of 
> HttpResponse(stream=True) at the time. The prospect of having 25 
> StreamingFooBar classes in Django makes me realize this wasn't a great 
> idea. Let's learn from this mistake. (The stakes are a bit low to consider 
> fixing it through a deprecation path, though.)
>   
>
> I think it would make the patch less intrusive and keep the documentation 
>>> more
>>> readable. Specifically I'm concerned about making several parts of the
>>> documentation twice longer for a relatively uncommon need.
>>>
>>> It's unclear to me why TemplateView gets a StreamingTemplateView sibling 
>>> while
>>> other generic class base views that inherit TemplateResponseMixin don't. 
>>> All
>>> GCBVs except View and RedirectView could get a Streaming version. Even 
>>> if the
>>> initial patch doesn't do it, someone will do it eventually, which 
>>> amounts to
>>> 13 additional classes.
>>>
>>
>> As I said, it was done on the original PR so I did it too. Maybe putting 
>> it as an example in the doc would be enough, so users know how to use 
>> streaming templates in GCBVs.
>>
>
> I'm proposing to add a `stream = False` attribute to TemplateResponseMixin.
>
>
I think documenting that changing the `response_class` attribute should be 
enough. Adding a `stream` attribute would make two attributes for selecting 
the response class (the stream attribute would not change anything else).
 

>
> 2) About third-party template engines
>>>
>>> How should third-party template engines that don't support streaming 
>>> rendering
>>> behave? Neither the code nor the release notes provide any guidance on 
>>> this
>>> issue. I suggest to add a stream() method that raises 
>>> NotImplementedError to
>>> the base class for template backends.
>>>
>>>
>> The Template class in the backends doesn't inherits from another class 
>> though, unless I'm missing something ?
>>
>
> I'm talking about template backends e.g. 
> https://github.com/django/django/blob/aaacaeb0/django/template/backends/django.py#L21
> .
>
>
These backends don't have any render method. The render method is on the 
Template 
class: 
https://github.com/django/django/blob/aaacaeb0963c406c4fe6f68c6ae51f4a65878250/django/template/backends/django.py#L54
 

>  
>
>> The current patch implements a stream() method that doesn't actually 
>>> stream in
>>> the DummyBackend and a boilerplate render() method that concatenates a 
>>> list of
>>> one element. This is bad, all the more since the dummy backend is 
>>> intended to
>>> be a template for third-party engines.
>>>
>>>
>> Should the NotImplemented be in the DummyBackend stream method then ?
>>
>
> Yes, in order to keep 
> https://github.com/django/django/blob/adff499e/django/template/backends/dummy.py#L17
>  
> a simple example of how to implement a Django template backend.
>
>  
>
>> All template backends have the same copy-pasted render() method. Perhaps 
>>> it's
>>> a symptom of a problem with the API. Perhaps it should just be pulled to 
>>> the
>>> base class.
>>>
>>>
>> So we should have a base class for