Re: Add documentation to address OWASP Top 10?

[Anssi Kääriäinen]

It is notable that if the number of items is a secret (say, you don't
want to reveal how many sales items you have), just having information
about sequential numbers is bad. In that case you should use UUID,
which the documentation could point out.

On Wed, Apr 6, 2016 at 4:35 AM, Josh Smeaton  wrote:
> I like the idea of addressing the OWASP top 10. Further, I think the advice
> of obscuring keys is wrong. The problem is actually addressed in the OWASP
> Top 10[0]
>
> 4 Insecure Direct Object References:
> A direct object reference occurs when a developer exposes a reference to an
> internal implementation object, such as a file, directory, or database key.
> Without an access control check or other protection, attackers can
> manipulate these references to access unauthorized data.
>
> The proper solution is *Access Controls* like the Permissions system
> provides. If you're going to rely on obscurity (one time file downloads for
> example), then you want to do so with a UUID or some kind of cryptohash (I
> haven't verified the particulars, don't take my this comment as security
> advice). That's not appropriate for something like a comments system.
>
> [0] https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_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/0ca48548-6c6f-4d80-b166-ff49487ff3cb%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/CALMtK1FWzGhDmmDvJO4bFajMR0fyubjQoP4-%3DgPQwBn7nSpMpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add documentation to address OWASP Top 10?

[Josh Smeaton]

I like the idea of addressing the OWASP top 10. Further, I think the advice 
of obscuring keys is wrong. The problem is actually addressed in the OWASP 
Top 10[0]

*4 Insecure Direct Object References:*
A direct object reference occurs when a developer exposes a reference to an 
internal implementation object, such as a file, directory, *or database key*. 
Without an access control check or other protection, attackers can 
manipulate these references to access unauthorized data.

The proper solution is *Access Controls* like the Permissions system 
provides. If you're going to rely on obscurity (one time file downloads for 
example), then you want to do so with a UUID or some kind of cryptohash (I 
haven't verified the particulars, don't take my this comment as security 
advice). That's not appropriate for something like a comments system.

[0] https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_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/0ca48548-6c6f-4d80-b166-ff49487ff3cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Add documentation to address OWASP Top 10?

[Tim Graham]

>From a Trac ticket [0]: "Using incremental URLs (i.e. /comment/1 is the 
first comment and /comment/2 is the second comment, respectively for base 
64 or other counting systems) is highly dangerous for private information. 
You could simply get all of the, say, private comments by accessing all 
comments sequentially and picking out the ones that are private. This can 
apply to confidential files (link sharing), personal information and more. 
There should be a section in the "Security in Django" about this."

Currently, the "Security in Django" document [1] says "This document is an 
overview of Django’s security features". I don't feel that addressing this 
concern, e.g. by using a randomly generated CharField or UUIDField primary 
key, would be considered a "security feature." Perhaps it would be worth 
creating a document that goes point by point through the OWASP Top 10 
similar to this blog post [2] where something like this could be addressed. 
I know there have been some conferences talks addressing how Django address 
the OWASP Top 10 as well [3,4]. What do you think?

[0] https://code.djangoproject.com/ticket/26464
[1] https://docs.djangoproject.com/en/dev/topics/security/
[2] http://blog.mikeleone.com/2011/10/security-django-and-owasp-top-10.html
[3] Florian at Django Under the Hood 2015: https://opbeat.com/events/duth/
[4] Jacob at Pycon Australia 2013: 
https://www.youtube.com/watch?v=sra9x44lXgU

-- 
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/ba3ddbfa-bdba-4b25-9f24-f9199118d267%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Tim Graham]

Any thoughts about whether or not to make similar simplifications to 
URLValidator? There's an old ticket to add a DomainNameValidator [0] which 
may or may not be worth moving forward with based on the decision.

[0] https://code.djangoproject.com/ticket/18119

On Saturday, April 2, 2016 at 3:05:14 AM UTC-4, Shai Berger wrote:
>
> On Saturday 02 April 2016 09:44:54 Josh Smeaton wrote: 
> > For what reason Zach? 
>
> There is only one reason for which a strict and accurate validation is 
> required, as far as I can see, and that is if your application is not just 
> using existing email addresses (i.e. sending mail to users) but actually 
> manages them (i.e. creates mail addresses). 
>
> Such applications are few and far between... 
>
> > Without a canonical regex implementation to copy or 
> > include, we're stuck poorly reimplementing a bunch of esoteric rules to 
> > what end? The main purpose of email validation is to provide relevant 
> > feedback to the user, and to guard against obviously bad or malicious 
> data. 
> > "Looks vaguely like an email address" is probably too loose to be 
> useful, I 
> > admit. The proposal to copy the regex from the html5 email input widget 
> > seems like a fine compromise to me. 
> > 
> > We should also err on the side of allowing incorrect addresses rather 
> than 
> > rejecting correct addresses. I'd much rather have bad signups that need 
> to 
> > be done again rather than users that can't sign up with their valid 
> > addresses. 
> > 
>
> ...and their needs should not imply a high burden of maintenance on the 
> rest 
> of the community; they can and should implement their own validation. 
>
> +1 everything Josh said. 
>
> Shai. 
>

-- 
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/78fa8f53-2639-4cde-b86f-b0294f7d1a83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should DecimalField have special rounding to make float assignments match string assignments?

[Daniel Moisset]

I'm not sure when it changed, but decimal.Decimal(some_float) was also an
error in 2.4 and 2.6 at least. I'm seeing that it works in 2.7, 3.3, 3.4,
3.5, so it's probably a recent decision, looking up the rationale for that
could be relevant

On Tue, Apr 5, 2016 at 3:30 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Small corrections:
>
> About 1) — actually decimal.Decimal() was an error Python 3.0 and
> 3.1.
>
> About 2) — I mixed up two options for the factory to build decimals from
> floats:
>
> - the decimal.Decimal.from_float class method — which I assume uses the
> global context
> - the decimal.Context..create_decimal_from_float method — which relies on
> a specific context
>
> https://docs.python.org/3.5/library/decimal.html#decimal.Decimal.from_float
>
> I assume the latter will be more convenient for low level control.
>
> --
> Aymeric.
>
> On 05 Apr 2016, at 16:17, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
> I have three ideas about this.
>
> 1) In my opinion, assigning a float to a decimal field is a programming
> error. Sadly Python doesn’t raise an exception in that case.
>
> >>> decimal.Decimal(2.15)
> Decimal('2.149911182158029987476766109466552734375')
>
> So Django has to support it as well.
>
> 2) Python 3 provides the `create_decimal_from_float()` class method
> on `decimal.Context` for this purpose. I think that’s what Django should
> use.
>
> >>> decimal.Context(prec=10).create_decimal_from_float(2.15)
> Decimal('2.15000')
>
>
> https://docs.python.org/3.5/library/decimal.html#decimal.Context.create_decimal_from_float
>
> (I don’t care much about Python 2 at this point. We should just make sure
> we don’t introduce a debatable behavior in the last LTS release supporting
> Python 2.)
>
> 3) Currently DecimalField accepts max_digits and decimal_places options. I
> think it should accept a decimal context and delegate all operations to
> that context.
>
> I suggest the following behavior:
>
> - start with the decimal context provided in a kwarg to DecimalField or,
> if there is None, the current context returned by `getcontext()`
> - modify that context to take into account max_digits and decimal_places
> - ask the context to perform whatever operations we need
>
> https://docs.python.org/3.5/library/decimal.html#decimal.getcontext
>
> I’m -1 on emulating that with arbitrary string conversions and rounding
> rules and also -1 on deviating from Python’s default behavior, which
> matches the IEEE 754 specification, without providing a way to customize
> that behavior properly.
>
> I hope this helps !
>
> --
> Aymeric.
>
> On 05 Apr 2016, at 15:49, Tim Graham  wrote:
>
> If you assign a float with more decimal places than a DecimalField field
> supports to that field, the value may round differently than if you assign
> the same value as a string. For example:
>
> class Invoice(models.Model):
> gross = models.DecimalField(max_digits=10, decimal_places=1)
>
> invoice.gross = 2.15# saves as 2.1
> invoice.gross = '2.15'  # saves as 2.2
>
> The default behavior of decimal rounding is ROUND_HALF_EVEN (to nearest
> with ties going to nearest even integer). There's a proposal to change this
> to cast floats to string and then use ROUND_HALF_UP to match the value of
> strings [0][1]. Do you have any concerns about this? Is it something we
> should even care about?
>
> [0] https://github.com/django/django/pull/6410
> [1] https://code.djangoproject.com/ticket/26459
>
> --
> 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/3749bbaf-ded7-4de3-912b-3a9e654b0207%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/07CD3A6B-EC86-42CC-A6BC-03D74112A0C3%40polytechnique.org
> 

Re: Should DecimalField have special rounding to make float assignments match string assignments?

[Aymeric Augustin]

Small corrections:

About 1) — actually decimal.Decimal() was an error Python 3.0 and 3.1.

About 2) — I mixed up two options for the factory to build decimals from floats:

- the decimal.Decimal.from_float class method — which I assume uses the global 
context
- the decimal.Context..create_decimal_from_float method — which relies on a 
specific context

https://docs.python.org/3.5/library/decimal.html#decimal.Decimal.from_float

I assume the latter will be more convenient for low level control.

-- 
Aymeric.

> On 05 Apr 2016, at 16:17, Aymeric Augustin 
>  wrote:
> 
> I have three ideas about this.
> 
> 1) In my opinion, assigning a float to a decimal field is a programming 
> error. Sadly Python doesn’t raise an exception in that case.
> 
> >>> decimal.Decimal(2.15)
> Decimal('2.149911182158029987476766109466552734375')
> 
> So Django has to support it as well.
> 
> 2) Python 3 provides the `create_decimal_from_float()` class method on 
> `decimal.Context` for this purpose. I think that’s what Django should use.
> 
> >>> decimal.Context(prec=10).create_decimal_from_float(2.15)
> Decimal('2.15000')
> 
> https://docs.python.org/3.5/library/decimal.html#decimal.Context.create_decimal_from_float
>  
> 
> 
> (I don’t care much about Python 2 at this point. We should just make sure we 
> don’t introduce a debatable behavior in the last LTS release supporting 
> Python 2.)
> 
> 3) Currently DecimalField accepts max_digits and decimal_places options. I 
> think it should accept a decimal context and delegate all operations to that 
> context.
> 
> I suggest the following behavior:
> 
> - start with the decimal context provided in a kwarg to DecimalField or, if 
> there is None, the current context returned by `getcontext()`
> - modify that context to take into account max_digits and decimal_places
> - ask the context to perform whatever operations we need
> 
> https://docs.python.org/3.5/library/decimal.html#decimal.getcontext 
> 
> 
> I’m -1 on emulating that with arbitrary string conversions and rounding rules 
> and also -1 on deviating from Python’s default behavior, which matches the 
> IEEE 754 specification, without providing a way to customize that behavior 
> properly.
> 
> I hope this helps !
> 
> -- 
> Aymeric.
> 
>> On 05 Apr 2016, at 15:49, Tim Graham > > wrote:
>> 
>> If you assign a float with more decimal places than a DecimalField field 
>> supports to that field, the value may round differently than if you assign 
>> the same value as a string. For example:
>> 
>> class Invoice(models.Model):
>> gross = models.DecimalField(max_digits=10, decimal_places=1)
>> 
>> invoice.gross = 2.15# saves as 2.1
>> invoice.gross = '2.15'  # saves as 2.2
>> 
>> The default behavior of decimal rounding is ROUND_HALF_EVEN (to nearest with 
>> ties going to nearest even integer). There's a proposal to change this to 
>> cast floats to string and then use ROUND_HALF_UP to match the value of 
>> strings [0][1]. Do you have any concerns about this? Is it something we 
>> should even care about?
>> 
>> [0] https://github.com/django/django/pull/6410 
>> 
>> [1] https://code.djangoproject.com/ticket/26459 
>> 
>> 
>> -- 
>> 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/3749bbaf-ded7-4de3-912b-3a9e654b0207%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 

Re: Should DecimalField have special rounding to make float assignments match string assignments?

[Aymeric Augustin]

I have three ideas about this.

1) In my opinion, assigning a float to a decimal field is a programming error. 
Sadly Python doesn’t raise an exception in that case.

>>> decimal.Decimal(2.15)
Decimal('2.149911182158029987476766109466552734375')

So Django has to support it as well.

2) Python 3 provides the `create_decimal_from_float()` class method on 
`decimal.Context` for this purpose. I think that’s what Django should use.

>>> decimal.Context(prec=10).create_decimal_from_float(2.15)
Decimal('2.15000')

https://docs.python.org/3.5/library/decimal.html#decimal.Context.create_decimal_from_float

(I don’t care much about Python 2 at this point. We should just make sure we 
don’t introduce a debatable behavior in the last LTS release supporting Python 
2.)

3) Currently DecimalField accepts max_digits and decimal_places options. I 
think it should accept a decimal context and delegate all operations to that 
context.

I suggest the following behavior:

- start with the decimal context provided in a kwarg to DecimalField or, if 
there is None, the current context returned by `getcontext()`
- modify that context to take into account max_digits and decimal_places
- ask the context to perform whatever operations we need

https://docs.python.org/3.5/library/decimal.html#decimal.getcontext

I’m -1 on emulating that with arbitrary string conversions and rounding rules 
and also -1 on deviating from Python’s default behavior, which matches the IEEE 
754 specification, without providing a way to customize that behavior properly.

I hope this helps !

-- 
Aymeric.

> On 05 Apr 2016, at 15:49, Tim Graham  wrote:
> 
> If you assign a float with more decimal places than a DecimalField field 
> supports to that field, the value may round differently than if you assign 
> the same value as a string. For example:
> 
> class Invoice(models.Model):
> gross = models.DecimalField(max_digits=10, decimal_places=1)
> 
> invoice.gross = 2.15# saves as 2.1
> invoice.gross = '2.15'  # saves as 2.2
> 
> The default behavior of decimal rounding is ROUND_HALF_EVEN (to nearest with 
> ties going to nearest even integer). There's a proposal to change this to 
> cast floats to string and then use ROUND_HALF_UP to match the value of 
> strings [0][1]. Do you have any concerns about this? Is it something we 
> should even care about?
> 
> [0] https://github.com/django/django/pull/6410 
> 
> [1] https://code.djangoproject.com/ticket/26459 
> 
> 
> -- 
> 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/3749bbaf-ded7-4de3-912b-3a9e654b0207%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/46F228D1-C8D0-4D98-9155-8751AAF409C1%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Should DecimalField have special rounding to make float assignments match string assignments?

[Javier Guerra Giraldez]

On 5 April 2016 at 14:49, Tim Graham  wrote:
> The default behavior of decimal rounding is ROUND_HALF_EVEN (to nearest with
> ties going to nearest even integer). There's a proposal to change this to
> cast floats to string and then use ROUND_HALF_UP to match the value of
> strings [0][1]. Do you have any concerns about this? Is it something we
> should even care about?


Am I reading it wrong, or the ticket/patch assume that the "correct"
rounding is ROUND_HALF_UP?  In my experience, ROUND_HALF_EVEN produces
less accumulated error after a string of operations.


-- 
Javier

-- 
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/CAFkDaoTv3T5PikjLvddX6W3dmyY48qo7tqEwpzYQCpjRv_R2Hg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Should DecimalField have special rounding to make float assignments match string assignments?

[Tim Graham]

If you assign a float with more decimal places than a DecimalField field 
supports to that field, the value may round differently than if you assign 
the same value as a string. For example:

class Invoice(models.Model):
gross = models.DecimalField(max_digits=10, decimal_places=1)

invoice.gross = 2.15# saves as 2.1
invoice.gross = '2.15'  # saves as 2.2

The default behavior of decimal rounding is ROUND_HALF_EVEN (to nearest 
with ties going to nearest even integer). There's a proposal to change this 
to cast floats to string and then use ROUND_HALF_UP to match the value of 
strings [0][1]. Do you have any concerns about this? Is it something we 
should even care about?

[0] https://github.com/django/django/pull/6410
[1] https://code.djangoproject.com/ticket/26459

-- 
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/3749bbaf-ded7-4de3-912b-3a9e654b0207%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New `pre_handler()` method on Class-Based Views

[Tim Graham]

See the discussion on the pull request: 
https://github.com/django/django/pull/6416

Aymeric says, "The GCBV API is already widely criticized for being too 
complicated. I think that adding one method to save one line of code is a 
bad trade-off. I'm -1."

On Sunday, April 3, 2016 at 3:35:26 PM UTC-4, Ryan Hiebert wrote:
>
> I have taken to using a prepare method called from dispatch which takes 
> the request  args, and I use it primarily to resolve ids in the url to db 
> objects. This sounds like it fills a similar purpose.
>
> Sent from my iPhone
>
> On Apr 3, 2016, at 14:07, Pablo Recio  > wrote:
>
> Hey there,
>
> Wanted to share an idea I had during some discussions in DjangoCon EU. 
> When using CBV, sometimes we have to replicate behaviour between different 
> handlers. For instance setting up certain objects, extra user checks... 
> Normally the way to achieve this is to override the `dispatch()`, but it's 
> a bit error-prone and doesn't feel too clean sometimes.
>
> So I wrote a little piece of code that adds a `pre_handler()` method that 
> gets called before the handler method, whatever that is. Here is the code: 
> https://github.com/pablorecio/django/tree/pre-handler-view-method, if 
> it's something that would get merged I'll happily submit a PR.
>
> Thanks!
> Pablo Recio
>
>
> -- 
> 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/df0c7703-b496-4bfa-ad31-68b35be482fa%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/087bc5f9-6aed-4614-ba66-b40815405d2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring multipledispatch

[James Pic]

Adding dependencies would definitely be a huge step forward. I think
Django doesn't have them because pip wasn't as awesome as it is today
back in the early days, but nowadays it would definitely make sense.
That would mean a bit more work for distribution package maintainers
but if we can start communicating with them about it then would there
be any reason not to do this move ?

-- 
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/CALC3Kae1Mt5LzYRq0PQbQcEMKwvbK%2Begr4FuC6baB5NZZtSbtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.