Re: how to deal with inspect.getargspec() deprecation?

2015-06-13 Thread Tim Graham 
I ended up abstracting our usage of inspect.getargspec() into some utility 
methods in a django.utils.inspect module. Each method has a separate branch 
for Python 2 and Python 3. It's not ideal, but I think it's preferable to 
adding a short-lived dependency or vendored copy, considering that dropping 
Python 2 in master is < 2 years out.

https://github.com/django/django/pull/4846

On Wednesday, June 10, 2015 at 5:45:30 PM UTC-4, Tim Graham wrote:
>
> The APIs are rather different. I will keep working on the conversions 
> (we'll need them no matter which option we pick), but here's a flavor: 
> https://github.com/django/django/pull/4846
>
> On Wednesday, June 10, 2015 at 3:50:52 PM UTC-4, Carl Meyer wrote:
>>
>> On 06/10/2015 01:48 PM, Berker Peksağ wrote: 
>> > On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham  
>> wrote: 
>> >> inspect.getargspec() was deprecated in Python 3.0 and will be removed 
>> in 3.6 
>> >> (ETA late 2016). It started throwing a deprecation warning in Python 
>> 3.5 
>> >> which causes some test failures when we check the number of 
>> deprecation 
>> >> warnings so I'd like to deal with it now and avoid introducing more 
>> usages. 
>> >> 
>> >> Its replacement is inspect.signature() which is in all the versions of 
>> >> Python 3 we support, but not 2.7. Options I see: 
>> >> 1. Add a dependency for the funcsigs backport [1] (only needed on 
>> Python 2) 
>> >> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the 
>> >> historical approach) 
>> >> 3. Write different code for Python 2 & 3 
>> > 
>> > funcsigs doesn't look like an up-to-date backport and we've fixed many 
>> > bugs in inspect.signature() in recent releases. It might be safer to 
>> > go with 3 (instead of adding an unmaintained dependency). 
>>
>> If that's true, then we should write our own backport that covers the 
>> cases we need (and consider contributing it to six, as Marc suggested). 
>> We shouldn't rewrite the compatibility code every place we need an 
>> argument signature (which is how I interpret option 3). 
>>
>> Calr 
>>
>>

-- 
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/9f638152-1312-4c4b-9f6a-18172b14b12f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to deal with inspect.getargspec() deprecation?

2015-06-10 Thread Tim Graham 
The APIs are rather different. I will keep working on the conversions 
(we'll need them no matter which option we pick), but here's a flavor: 
https://github.com/django/django/pull/4846

On Wednesday, June 10, 2015 at 3:50:52 PM UTC-4, Carl Meyer wrote:
>
> On 06/10/2015 01:48 PM, Berker Peksağ wrote: 
> > On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham  > wrote: 
> >> inspect.getargspec() was deprecated in Python 3.0 and will be removed 
> in 3.6 
> >> (ETA late 2016). It started throwing a deprecation warning in Python 
> 3.5 
> >> which causes some test failures when we check the number of deprecation 
> >> warnings so I'd like to deal with it now and avoid introducing more 
> usages. 
> >> 
> >> Its replacement is inspect.signature() which is in all the versions of 
> >> Python 3 we support, but not 2.7. Options I see: 
> >> 1. Add a dependency for the funcsigs backport [1] (only needed on 
> Python 2) 
> >> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the 
> >> historical approach) 
> >> 3. Write different code for Python 2 & 3 
> > 
> > funcsigs doesn't look like an up-to-date backport and we've fixed many 
> > bugs in inspect.signature() in recent releases. It might be safer to 
> > go with 3 (instead of adding an unmaintained dependency). 
>
> If that's true, then we should write our own backport that covers the 
> cases we need (and consider contributing it to six, as Marc suggested). 
> We shouldn't rewrite the compatibility code every place we need an 
> argument signature (which is how I interpret option 3). 
>
> Calr 
>
>

-- 
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/8479b68f-0abe-44bd-9729-abfcca40288f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to deal with inspect.getargspec() deprecation?

2015-06-10 Thread Berker Peksağ 
On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham  wrote:
> inspect.getargspec() was deprecated in Python 3.0 and will be removed in 3.6
> (ETA late 2016). It started throwing a deprecation warning in Python 3.5
> which causes some test failures when we check the number of deprecation
> warnings so I'd like to deal with it now and avoid introducing more usages.
>
> Its replacement is inspect.signature() which is in all the versions of
> Python 3 we support, but not 2.7. Options I see:
> 1. Add a dependency for the funcsigs backport [1] (only needed on Python 2)
> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the
> historical approach)
> 3. Write different code for Python 2 & 3

funcsigs doesn't look like an up-to-date backport and we've fixed many
bugs in inspect.signature() in recent releases. It might be safer to
go with 3 (instead of adding an unmaintained dependency).

--Berker

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

Re: how to deal with inspect.getargspec() deprecation?

2015-06-10 Thread Carl Meyer 
On 06/10/2015 01:48 PM, Berker Peksağ wrote:
> On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham  wrote:
>> inspect.getargspec() was deprecated in Python 3.0 and will be removed in 3.6
>> (ETA late 2016). It started throwing a deprecation warning in Python 3.5
>> which causes some test failures when we check the number of deprecation
>> warnings so I'd like to deal with it now and avoid introducing more usages.
>>
>> Its replacement is inspect.signature() which is in all the versions of
>> Python 3 we support, but not 2.7. Options I see:
>> 1. Add a dependency for the funcsigs backport [1] (only needed on Python 2)
>> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the
>> historical approach)
>> 3. Write different code for Python 2 & 3
> 
> funcsigs doesn't look like an up-to-date backport and we've fixed many
> bugs in inspect.signature() in recent releases. It might be safer to
> go with 3 (instead of adding an unmaintained dependency).

If that's true, then we should write our own backport that covers the
cases we need (and consider contributing it to six, as Marc suggested).
We shouldn't rewrite the compatibility code every place we need an
argument signature (which is how I interpret option 3).

Calr

-- 
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/5578950F.2060606%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: how to deal with inspect.getargspec() deprecation?

2015-06-10 Thread Marc Tamlyn 
I'm not sure how similar the return values are, is it possible to write
(and contribute upstream) a six move? Perhaps this is impossible without
funcsigs though.

Marc

On 10 June 2015 at 20:09, Carl Meyer  wrote:

> On 06/10/2015 12:49 PM, Tim Graham wrote:
> > inspect.getargspec() was deprecated in Python 3.0 and will be removed in
> > 3.6 (ETA late 2016). It started throwing a deprecation warning in Python
> > 3.5 which causes some test failures when we check the number of
> > deprecation warnings so I'd like to deal with it now and avoid
> > introducing more usages.
> >
> > Its replacement is inspect.signature() which is in all the versions of
> > Python 3 we support, but not 2.7. Options I see:
> > 1. Add a dependency for the funcsigs backport [1] (only needed on Python
> 2)
> > 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the
> > historical approach)
> > 3. Write different code for Python 2 & 3
> >
> > [1] https://github.com/aliles/funcsigs
>
> I'd say either 1 or 2. Personally I feel the ecosystem is ready for
> Django to have dependencies, and we could go with 1. But maybe a 1k LOC
> back-compat lib, which would likely be trivial to vendor, isn't the best
> case for that first required dependency.
>
> Carl
>
> --
> 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/55788B4E.2060409%40oddbird.net
> .
> 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/CAMwjO1HgqEqjoU8%3DypQJpQJP%2BW1_xE0f1Q%3DH4CQv-_NoW2bYwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to deal with inspect.getargspec() deprecation?

2015-06-10 Thread Carl Meyer 
On 06/10/2015 12:49 PM, Tim Graham wrote:
> inspect.getargspec() was deprecated in Python 3.0 and will be removed in
> 3.6 (ETA late 2016). It started throwing a deprecation warning in Python
> 3.5 which causes some test failures when we check the number of
> deprecation warnings so I'd like to deal with it now and avoid
> introducing more usages.
> 
> Its replacement is inspect.signature() which is in all the versions of
> Python 3 we support, but not 2.7. Options I see:
> 1. Add a dependency for the funcsigs backport [1] (only needed on Python 2)
> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the
> historical approach)
> 3. Write different code for Python 2 & 3
> 
> [1] https://github.com/aliles/funcsigs

I'd say either 1 or 2. Personally I feel the ecosystem is ready for
Django to have dependencies, and we could go with 1. But maybe a 1k LOC
back-compat lib, which would likely be trivial to vendor, isn't the best
case for that first required dependency.

Carl

-- 
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/55788B4E.2060409%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature