how to deal with inspect.getargspec() deprecation?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

how to deal with inspect.getargspec() deprecation?

Tim Graham-2
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

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/5b405721-619d-4288-9c5e-c1fad1162f28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Carl Meyer-4
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 [hidden email].
To post to this group, send email to [hidden email].
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 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

Berker Peksağ
In reply to this post by Tim Graham-2
On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

Carl Meyer-4
On 06/10/2015 01:48 PM, Berker Peksağ wrote:

> On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
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 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Tim Graham-2
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="51D6iodNwgQJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">timog...@...> 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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

Tim Graham-2
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: <a href="https://github.com/django/django/pull/4846" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F4846\46sa\75D\46sntz\0751\46usg\75AFQjCNGtzQ2m2YrRU9JW2QU3T6MYYf7zmQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F4846\46sa\75D\46sntz\0751\46usg\75AFQjCNGtzQ2m2YrRU9JW2QU3T6MYYf7zmQ';return true;">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 <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
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.