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 <[email protected]> 
>> 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 [email protected].
To post to this group, send email to [email protected].
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.

Reply via email to