Re: django

[Angelo Dini]

Hello, please 
checkout http://docs.django-cms.org/en/stable/introduction/install.html

On Sunday, 1 January 2017 17:11:12 UTC+1, Manish Jain wrote:
>
> Hello, please i am new in django so please tell me fresh installation 
> step. 
>

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/22113605-2b1b-4192-9bb5-ad0677e3d8a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MariaDB, official support

[Adam Johnson]

Hi,

Sorry I missed this thread!

Adam is (or is planning..) writing a DB backend that includes MySQL and 
> MariaDB
>

Not technically, I'm actually writing a backend to use the newer MySQL 
DBAPI library pymysql at 
https://github.com/adamchainz/django-pymysql-backend . For the first pass 
at least it won't do anything differently on MariaDB. I haven't worked on 
it since before DUTH unfortunately :(

As for whether Django core should have a support policy for MariaDB, I 
think it definitely should do. I also think it's probably best if it's done 
with switches *inside* the MySQL backend, rather than as a separate 
backend. Now here's why:

   1. MariaDB *is* MySQL on some Linux distros, e.g. Red Hat. When you 
   install the mysql package, you get MariaDB. These are listed 
   at https://mariadb.com/kb/en/mariadb/distributions-which-include-mariadb/ . 
   Thus some users don't even know they're using MariaDB instead of MySQL.
   2. MariaDB may have a smaller user base at current, but it's growing 
   pretty quickly compared to MySQL (though I guess it's hard to grow when 
   you're so popular). 
   See http://db-engines.com/en/ranking_trend/system/MariaDB 
   versus http://db-engines.com/en/ranking_trend/system/MySQL .
   3. The policy of creating one tool that works on both MySQL + MariaDB, 
   with detection for which it is, is pretty much the standard practice in the 
   community, e.g. this line in the popular mydumper 
   utility: 
https://bazaar.launchpad.net/~max-bubenick/mydumper/0.9/view/head:/mydumper.c#L334
   4. I don't expect there too be too many MariaDB specific checks in 
   Django, since MariaDB still keeps MySQL compatibility. The TEXT / BLOB 
   column defaults ( https://code.djangoproject.com/ticket/27676 ) are one 
   example of a relatively small change.



On Tuesday, November 15, 2016 at 7:41:17 AM UTC, Josh Smeaton wrote:
>
> I believe Adam is (or is planning..) writing a DB backend that includes 
> MySQL and MariaDB. Adam, did I remember correctly? If so, are you going to 
> suggest adding this new backend to core as a replacement? Mads, perhaps you 
> can help with this effort?
>
> Regards,
>
> On Tuesday, 15 November 2016 08:44:57 UTC+11, Mads Jensen wrote:
>>
>> Hi, 
>>
>> I got interest in contributing to Django. I started working on a bigger 
>> ticket than the smaller contributions I've previously made. 
>>
>> Adam Chainz pointed out that MariaDB will include support for window 
>> expressions (#26608) from 10.2. I asked on #django-dev what the official 
>> policy for MariaDB is, and was told it's ad-hoc. Also, the test 
>> environment does include MariaDB which to me would make sense to add. I 
>> think the implemented features for MySQL is also available for MariaDB. 
>>
>> I know the existence of django-mysql. 
>> -- 
>> Med venlig hilsen / Kind regards, 
>> Mads Jensen 
>>
>>  Saajan Fernandes: I think we forget things if there is nobody to 
>>tell them. 
>>  -- The Lunchbox (2013) 
>>
>>

-- 
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/3451d7ea-457d-48b8-8575-87caed2d2051%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Josh Smeaton]

I agree with Tim. I think the intent is to add dependencies as part of a 
feature, not specifically as part of another DEP (which I don't believe 
this feature needs). I don't think `overloading` was considered as a 
dependency, but it's interesting. If this feature doesn't make 1.11 (it 
potentially could if it's cleaned up) then perhaps we could take a better 
look at overloading for 2.0.
>
>

-- 
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/14cf6efb-ae23-4cdb-86db-82b220249344%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Channel asgi specs - question on how to handle a websocket connection

[Oskar Hahn]

Hi,

this is a question on how to interpret the asgi specs of django channels:

https://channels.readthedocs.io/en/latest/asgi.html

If this is the wrong place to discuss it, then please point me to the
right place.

I used some free time to learn the language "go" and tried to write a
protocol servers in go. This works quite well, thanks for the asgi specs
and daphne as an example. Most parts already work. But I do not
understand how to handle incoming websocket connections.

https://channels.readthedocs.io/en/latest/asgi.html#connection

If I understand the specs right, then the protocol server should not
respond to an incoming websocket connection right away but keep the
http-connection open with no response at all. But it should send a
connection message to the channel layer,  wait for the responding
Send/Close/Accept message and handle the websocket-request accordingly.

But there are some cases which I do not understand:

What should happen if the python application does not send a
Send/Close/Accept at all? Should the websocket-handshake stay in an
incomplete state?

It seems, that the reconnecting-websocket javascript library[1], that is
used by the django channels examples[2], closes and reconnects an
websocket handshake, if there is no response after one second.

[1] https://github.com/joewalnes/reconnecting-websocket
[2] https://github.com/andrewgodwin/channels-examples



The specs says, that the Send/Close/Accept message has a "close" and a
"accept" flag. What should the protocol server do while the connection
is waiting for acceptance and

* accept AND close are both set to true?
* neither accept nor close  (nor byte nor text) is set to true?

When I compare the "stable" specs with the "latest" specs I see, that
the "accept" flag has not been there in the "stable" version. I do not
understand way it was introduced. If I understand the Send/Close/Accept
message correctly it should be possible to remove the "accept" flag by
merge it with the "close" flag into one "close/reject" flag.

* If this flag is set while the connection is waiting for acceptance,
then the websocket connection is rejected.
* If the flag is set to true while the connection is established, then
the connection should be closed.
* If it is set to false while the connection is waiting for acceptance,
then the connection is accepted
* If it is set to false while the connection is established, then it is
kept open.



The specs say, that close can be a positive integer specifying the
response code. What should the protocol server do while the connection
is waiting for acceptance when it receives an Send/Close/Accept message
like this one:

{"close": 1006}

At this moment the websocket handshake was not finished, so the usual
way to "close" it would be not to open it at all. The protocol server
can just send an http 403 response. So should the "close" value be
ignored? Is there a way for the python application to specify the http
status code? I think this is not possible because the specs allow the
protocol server to open the websocket connection before the
Send/Close/Accept message was received and buffer all incoming messages.
In this case it is not possible for the protocol server to send an http
status code to the client. Maybe the specs should be more strict and say
that it is not allowed for the protocol server to finish the websocket
handshake before the first Send/Close/Accept message was received. In
this case the close-value of the first Send/Close/Accept message could
be interpreted as an http response code.

Best regards,
Oskar

-- 
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/26bf7c7e-bc74-618f-818a-bd7b6538caf2%40oshahn.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

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

[Tim Graham]

Maybe the dependencies DEP (currently at draft status) needs a revision to 
allow for dependencies without requiring a feature DEP. I interpret the 
current wording to imply that dependencies are only added as part of major 
features, however, I don't think the current feature for multidispatch nor 
the pytz requirement would require a DEP otherwise.

On Monday, January 2, 2017 at 1:13:13 PM UTC-5, Adam Johnson wrote:
>
> I agree, it doesn't seem likely there will be breaking changes in it 
> either.
>
> According to DEP007 ( 
> https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst 
> ), dependencies should go through on the feature DEP rather than just via 
> the mailing list.
>
> And btw was https://pypi.python.org/pypi/overloading considered? That's 
> the syntax that the deferred PEP 3124 ( 
> http://legacy.python.org/dev/peps/pep-3124/ ) suggested, implemented as a 
> third party library. Python 3 only but Django 2.0 is now very close...
>
> On 2 January 2017 at 16:47, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Hello,
>>
>> I think it would be best for Django to depend on the current version, 
>> that is, no version specifier. If something breaks, we can update Django 
>> and add a minimum version specifier.
>>
>> I dislike maximum version specifiers because they tend to get forgotten 
>> until something else depends on an incompatible minimum version number. 
>> Then users who want both libs hit a wall.
>>
>> To avoid unexpected upgrades, projects should pin their dependencies 
>> recursively, typically with pip-tools, and test when updating dependencies. 
>> This is a project-level concern. Django shouldn’t add constraints.
>>
>> I hope this helps,
>>
>> -- 
>> Aymeric.
>>
>> On 2 Jan 2017, at 17:23, Tim Graham  
>> wrote:
>>
>> The main question for me is what version specifier (if any) to use in 
>> Django's setup.py. One didn't seem appropriate for pytz since the latest 
>> version should always be fine and it doesn't follow semantic versioning 
>> anyway. I see multidispatch is now at version 0.4.9 but it's not clear to 
>> me in what version it might introduce some potentially braking changes 
>> (1.0? 0.5?).
>>
>> On Monday, January 2, 2017 at 8:07:52 AM UTC-5, Florian Apolloner wrote:
>>>
>>> Jupp, dependency is fine imo.
>>>
>>> On Sunday, January 1, 2017 at 7:13:24 PM UTC+1, Aymeric Augustin wrote:

 Hello Josh,

 I prefer adding this library as a dependency to vendoring it.

 Best regards,

 -- 
 Aymeric.

 On 1 Jan 2017, at 06:36, Josh Smeaton  wrote:

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

 The brief overview of the patch is to allow operators on different 
 expressions to generate different SQL. An example:

 .annotate(combined=F('cost') + F('tax')) -> SELECT .. cost + tax as 
 combined ..
 .annotate(combined=F('first_name') + F('last_name')) -> SELECT .. 
 CONCAT(first_name, last_name) ..

 As you can see, the operators are the same (+) but most (all?) SQL 
 dialects don't allow you to use the + symbol for concatenation.

 As for whether or not to add the dependency we can look to 
 https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst
  for guidance. I'll copy the guidelines below:

- Stable *- there aren't many releases. Seems to keep up to date 
with Python releases but not much else.*
- Maintained *- last release was 3 months ago, but see point above.*
- Takes security seriously* - N/A to date*
- Works on all the same platforms as Django does* - Yes*
- Backwards compatible in minor releases*. - Yes*
- Confident that point-releases of won't break Django. *- Yes.*

 I believe multipledispatch meets all the criteria for being an 
 acceptable dependency. I don't see much value in vendoring the library if 
 we're going to need to remember to keep it up to date with Django 
 releases. 
 The precedent was set with pytz recently.

 Does anyone have a problem with declaring multipledispatch as a 
 dependency?

 Thanks

 -- 
 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 https://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 

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

[Adam Johnson]

I agree, it doesn't seem likely there will be breaking changes in it either.

According to DEP007 (
https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst
), dependencies should go through on the feature DEP rather than just via
the mailing list.

And btw was https://pypi.python.org/pypi/overloading considered? That's the
syntax that the deferred PEP 3124 (
http://legacy.python.org/dev/peps/pep-3124/ ) suggested, implemented as a
third party library. Python 3 only but Django 2.0 is now very close...

On 2 January 2017 at 16:47, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I think it would be best for Django to depend on the current version, that
> is, no version specifier. If something breaks, we can update Django and add
> a minimum version specifier.
>
> I dislike maximum version specifiers because they tend to get forgotten
> until something else depends on an incompatible minimum version number.
> Then users who want both libs hit a wall.
>
> To avoid unexpected upgrades, projects should pin their dependencies
> recursively, typically with pip-tools, and test when updating dependencies.
> This is a project-level concern. Django shouldn’t add constraints.
>
> I hope this helps,
>
> --
> Aymeric.
>
> On 2 Jan 2017, at 17:23, Tim Graham  wrote:
>
> The main question for me is what version specifier (if any) to use in
> Django's setup.py. One didn't seem appropriate for pytz since the latest
> version should always be fine and it doesn't follow semantic versioning
> anyway. I see multidispatch is now at version 0.4.9 but it's not clear to
> me in what version it might introduce some potentially braking changes
> (1.0? 0.5?).
>
> On Monday, January 2, 2017 at 8:07:52 AM UTC-5, Florian Apolloner wrote:
>>
>> Jupp, dependency is fine imo.
>>
>> On Sunday, January 1, 2017 at 7:13:24 PM UTC+1, Aymeric Augustin wrote:
>>>
>>> Hello Josh,
>>>
>>> I prefer adding this library as a dependency to vendoring it.
>>>
>>> Best regards,
>>>
>>> --
>>> Aymeric.
>>>
>>> On 1 Jan 2017, at 06:36, Josh Smeaton  wrote:
>>>
>>> This has been briefly discussed before, but we need to form a consensus
>>> on whether we vendor or depend on the multipledispatch
>>>  library for the
>>> following PR: https://github.com/django/django/pull/6395
>>>
>>> The brief overview of the patch is to allow operators on different
>>> expressions to generate different SQL. An example:
>>>
>>> .annotate(combined=F('cost') + F('tax')) -> SELECT .. cost + tax as
>>> combined ..
>>> .annotate(combined=F('first_name') + F('last_name')) -> SELECT ..
>>> CONCAT(first_name, last_name) ..
>>>
>>> As you can see, the operators are the same (+) but most (all?) SQL
>>> dialects don't allow you to use the + symbol for concatenation.
>>>
>>> As for whether or not to add the dependency we can look to
>>> https://github.com/django/deps/blob/master/draft/0007-dep
>>> endency-policy.rst for guidance. I'll copy the guidelines below:
>>>
>>>- Stable *- there aren't many releases. Seems to keep up to date
>>>with Python releases but not much else.*
>>>- Maintained *- last release was 3 months ago, but see point above.*
>>>- Takes security seriously* - N/A to date*
>>>- Works on all the same platforms as Django does* - Yes*
>>>- Backwards compatible in minor releases*. - Yes*
>>>- Confident that point-releases of won't break Django. *- Yes.*
>>>
>>> I believe multipledispatch meets all the criteria for being an
>>> acceptable dependency. I don't see much value in vendoring the library if
>>> we're going to need to remember to keep it up to date with Django releases.
>>> The precedent was set with pytz recently.
>>>
>>> Does anyone have a problem with declaring multipledispatch as a
>>> dependency?
>>>
>>> Thanks
>>>
>>> --
>>> 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 https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.
>>> com/d/msgid/django-developers/d46cfb10-1698-4534-8a0f-ec5d75
>>> b5226d%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 

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

[Aymeric Augustin]

Hello,

I think it would be best for Django to depend on the current version, that is, 
no version specifier. If something breaks, we can update Django and add a 
minimum version specifier.

I dislike maximum version specifiers because they tend to get forgotten until 
something else depends on an incompatible minimum version number. Then users 
who want both libs hit a wall.

To avoid unexpected upgrades, projects should pin their dependencies 
recursively, typically with pip-tools, and test when updating dependencies. 
This is a project-level concern. Django shouldn’t add constraints.

I hope this helps,

-- 
Aymeric.

> On 2 Jan 2017, at 17:23, Tim Graham  wrote:
> 
> The main question for me is what version specifier (if any) to use in 
> Django's setup.py. One didn't seem appropriate for pytz since the latest 
> version should always be fine and it doesn't follow semantic versioning 
> anyway. I see multidispatch is now at version 0.4.9 but it's not clear to me 
> in what version it might introduce some potentially braking changes (1.0? 
> 0.5?).
> 
> On Monday, January 2, 2017 at 8:07:52 AM UTC-5, Florian Apolloner wrote:
> Jupp, dependency is fine imo.
> 
> On Sunday, January 1, 2017 at 7:13:24 PM UTC+1, Aymeric Augustin wrote:
> Hello Josh,
> 
> I prefer adding this library as a dependency to vendoring it.
> 
> Best regards,
> 
> -- 
> Aymeric.
> 
>> On 1 Jan 2017, at 06:36, Josh Smeaton > wrote:
>> 
>> This has been briefly discussed before, but we need to form a consensus on 
>> whether we vendor or depend on the multipledispatch 
>>  library for the following PR: 
>> https://github.com/django/django/pull/6395 
>> 
>> 
>> The brief overview of the patch is to allow operators on different 
>> expressions to generate different SQL. An example:
>> 
>> .annotate(combined=F('cost') + F('tax')) -> SELECT .. cost + tax as combined 
>> ..
>> .annotate(combined=F('first_name') + F('last_name')) -> SELECT .. 
>> CONCAT(first_name, last_name) ..
>> 
>> As you can see, the operators are the same (+) but most (all?) SQL dialects 
>> don't allow you to use the + symbol for concatenation.
>> 
>> As for whether or not to add the dependency we can look to 
>> https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst 
>> 
>>  for guidance. I'll copy the guidelines below:
>> Stable - there aren't many releases. Seems to keep up to date with Python 
>> releases but not much else.
>> Maintained - last release was 3 months ago, but see point above.
>> Takes security seriously - N/A to date
>> Works on all the same platforms as Django does - Yes
>> Backwards compatible in minor releases. - Yes
>> Confident that point-releases of won't break Django. - Yes.
>> I believe multipledispatch meets all the criteria for being an acceptable 
>> dependency. I don't see much value in vendoring the library if we're going 
>> to need to remember to keep it up to date with Django releases. The 
>> precedent was set with pytz recently.
>> 
>> Does anyone have a problem with declaring multipledispatch as a dependency?
>> 
>> Thanks
>> 
>> -- 
>> 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 https://groups.google.com/group/django-developers 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/d46cfb10-1698-4534-8a0f-ec5d75b5226d%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/a9e5a106-8733-4b62-bb7c-9b70accfe478%40googlegroups.com
>  
> 

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

[Tim Graham]

The main question for me is what version specifier (if any) to use in 
Django's setup.py. One didn't seem appropriate for pytz since the latest 
version should always be fine and it doesn't follow semantic versioning 
anyway. I see multidispatch is now at version 0.4.9 but it's not clear to 
me in what version it might introduce some potentially braking changes 
(1.0? 0.5?).

On Monday, January 2, 2017 at 8:07:52 AM UTC-5, Florian Apolloner wrote:
>
> Jupp, dependency is fine imo.
>
> On Sunday, January 1, 2017 at 7:13:24 PM UTC+1, Aymeric Augustin wrote:
>>
>> Hello Josh,
>>
>> I prefer adding this library as a dependency to vendoring it.
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>> On 1 Jan 2017, at 06:36, Josh Smeaton  wrote:
>>
>> This has been briefly discussed before, but we need to form a consensus 
>> on whether we vendor or depend on the multipledispatch 
>>  library for the following 
>> PR: https://github.com/django/django/pull/6395
>>
>> The brief overview of the patch is to allow operators on different 
>> expressions to generate different SQL. An example:
>>
>> .annotate(combined=F('cost') + F('tax')) -> SELECT .. cost + tax as 
>> combined ..
>> .annotate(combined=F('first_name') + F('last_name')) -> SELECT .. 
>> CONCAT(first_name, last_name) ..
>>
>> As you can see, the operators are the same (+) but most (all?) SQL 
>> dialects don't allow you to use the + symbol for concatenation.
>>
>> As for whether or not to add the dependency we can look to 
>> https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst 
>> for guidance. I'll copy the guidelines below:
>>
>>- Stable *- there aren't many releases. Seems to keep up to date with 
>>Python releases but not much else.*
>>- Maintained *- last release was 3 months ago, but see point above.*
>>- Takes security seriously* - N/A to date*
>>- Works on all the same platforms as Django does* - Yes*
>>- Backwards compatible in minor releases*. - Yes*
>>- Confident that point-releases of won't break Django. *- Yes.*
>>
>> I believe multipledispatch meets all the criteria for being an acceptable 
>> dependency. I don't see much value in vendoring the library if we're going 
>> to need to remember to keep it up to date with Django releases. The 
>> precedent was set with pytz recently.
>>
>> Does anyone have a problem with declaring multipledispatch as a 
>> dependency?
>>
>> Thanks
>>
>> -- 
>> 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/d46cfb10-1698-4534-8a0f-ec5d75b5226d%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/a9e5a106-8733-4b62-bb7c-9b70accfe478%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tim Graham]

Now that Python 2 is dropped in Django 2.0 and a faster implementation of 
pbkdf2 is guaranteed to be available (from what I understand), it's time to 
reevaluate our strategy for increasing the number of iterations each 
release.

I'm not sure how to evaluate potential performance issues from bumping the 
number of iterations too aggressively. I'd be happy to do some benchmarks 
but I'm not sure what will be meaningful.

The Python docs say, "As of 2013, at least 100,000 iterations of SHA-256 
are suggested." [0]

Here are the number of iterations in recent versions of Django:
Django 1.8: 2
Django 1.9: 24000
Django 1.10: 3
Django 1.11: 36000

[0] https://docs.python.org/3/library/hashlib.html#hashlib.pbkdf2_hmac

On Tuesday, September 22, 2015 at 5:15:37 PM UTC-4, Aymeric Augustin wrote:
>
> On 22 sept. 2015, at 21:21, Tim Graham  
> wrote: 
>
> > At this point, I'm inclined to continue with the 20-25% iterations 
> increase per release methodology we've been using unless someone wants to 
> advocate for one of the other proposals. 
>
>
> I agree. 
>
> -- 
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fd777015-3d60-4a60-9e41-a7fd1d421200%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Window expressions, #26608

[Mads Jensen]

I think this has cleaned up to request input (I'm a bit zealous to make 
something that will be merged). I left a note in 1.11.txt but when 2.0.txt 
is introduced, I'll move it there. Also, now everything is in places that 
are not PostgreSQL-only. I realized in the process that the only thing the 
list of functions in the features-list of a backend is to prevent the test 
suite to run tests for unsupported functions. Mostly because MariaDB won't 
include FIRST_VALUE and LAST_VALUE and a few more. Perhaps a single list 
would be better?

I have a few questions to clear this up before asking for a more formal 
review:

1. PostgreSQL and MariaDB don't include support for RESPECT|IGNORE NULLS 
for certain functions (details are provided in
https://www.postgresql.org/docs/current/static/functions-window.html). Any 
thoughts if adding ignore_nulls=False|True to the constructor would be an 
idea, and then specify it's only possible for Oracle, or "as_oracle" with a 
special template? I noticed that nulls_last and nulls_first was added to 
OrderBy, however that is valid in all implementations. The Oracle virtual 
box was too big to fit on my machine, so I haven't tested locally for more 
than PostgreSQL, and on Python 3.

2. About __repr__ and __str__, in general, I'm in doubt what would be good 
ways to represent things, and how to test them? Also, I am in doubt what 
are intuitive input values that translate to CURRENT ROW, UNBOUNDED 
FOLLOWING etc.? I had a look at sqlalchemy which uses a mix of null-values 
and integers as valid input. In general, the frames-part is a bit of 
headache, and still slightly messy (the generated SQL is fine, so I suppose 
the current test data is adequate).

And probably, django/db/backends/mysql/features.py should be left untouched?

I know 1.11 is in the works, so I'm fine with this being on hold.

Thank you,
~ Mads

-- 
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/822595ee-e75e-4979-8873-7b6488ee2d31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Florian Apolloner]

Jupp, dependency is fine imo.

On Sunday, January 1, 2017 at 7:13:24 PM UTC+1, Aymeric Augustin wrote:
>
> Hello Josh,
>
> I prefer adding this library as a dependency to vendoring it.
>
> Best regards,
>
> -- 
> Aymeric.
>
> On 1 Jan 2017, at 06:36, Josh Smeaton  
> wrote:
>
> This has been briefly discussed before, but we need to form a consensus on 
> whether we vendor or depend on the multipledispatch 
>  library for the following 
> PR: https://github.com/django/django/pull/6395
>
> The brief overview of the patch is to allow operators on different 
> expressions to generate different SQL. An example:
>
> .annotate(combined=F('cost') + F('tax')) -> SELECT .. cost + tax as 
> combined ..
> .annotate(combined=F('first_name') + F('last_name')) -> SELECT .. 
> CONCAT(first_name, last_name) ..
>
> As you can see, the operators are the same (+) but most (all?) SQL 
> dialects don't allow you to use the + symbol for concatenation.
>
> As for whether or not to add the dependency we can look to 
> https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst 
> for guidance. I'll copy the guidelines below:
>
>- Stable *- there aren't many releases. Seems to keep up to date with 
>Python releases but not much else.*
>- Maintained *- last release was 3 months ago, but see point above.*
>- Takes security seriously* - N/A to date*
>- Works on all the same platforms as Django does* - Yes*
>- Backwards compatible in minor releases*. - Yes*
>- Confident that point-releases of won't break Django. *- Yes.*
>
> I believe multipledispatch meets all the criteria for being an acceptable 
> dependency. I don't see much value in vendoring the library if we're going 
> to need to remember to keep it up to date with Django releases. The 
> precedent was set with pytz recently.
>
> Does anyone have a problem with declaring multipledispatch as a dependency?
>
> Thanks
>
> -- 
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/d46cfb10-1698-4534-8a0f-ec5d75b5226d%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/a29eb8cc-6858-4b9d-92bf-b3036d91302e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.