We Keep Coding

Would like to relate commit in official cpython library to a python release

I'm currently using a package provided to me in a whl file. I was able to install this package using pip. However, when I looked through the source code, it appears that the package expects the _special attribute to exist in the _GenericAlias class of the typing module. In the latest version of python's typing module, it looks like this attribute is not present. However, it looks like it did exist at a certain point in time as shown in this link.
I would like to figure out which version of python I need to install for this attribute to exist in the typing module. I can see from the link above that this was the case in commit 6292be7adf but I haven't a clue how to relate this commit to a specific python version that I can pip or conda install in my environment.
How can I come up with the exact version that contains the above code?

Ok I cloned the whole cpython repo and did a search:
$ git log -S 'self._special = special'
commit c1c7d8ead9eb214a6149a43e31a3213c52448877
Author: Serhiy Storchaka <storchaka#gmail.com>
Date: Thu May 7 04:09:33 2020 +0300
bpo-40397: Refactor typing._GenericAlias (GH-19719)
Make the design more object-oriented.
Split _GenericAlias on two almost independent classes: for special
generic aliases like List and for parametrized generic aliases like List[int].
Add specialized subclasses for Callable, Callable[...], Tuple and Union[...].
commit d911e40e788fb679723d78b6ea11cabf46caed5a
Author: Ivan Levkivskyi <levkivskyi#gmail.com>
Date: Sat Jan 20 11:23:59 2018 +0000
bpo-32226: PEP 560: improve typing module (#4906)
This PR re-designs the internal typing API using the new PEP 560 features.
However, there are only few minor changes in the public API.
So this attribute was introduced in d911e40e788fb679723d78b6ea11cabf46caed5a which is in 3.7.0b1 and removed in c1c7d8ead9eb214a6149a43e31a3213c52448877 which is in 3.9.0b1. Anything in 3.7 or 3.8 should have it.

ABC depreciated - where to inherit abstractmethod decorator from?

I am getting the following warning:
DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working
return isinstance(x, collections.Callable)
when I run my unit tests for my project. I replaced:
from abc import ABC, abstractmethod
with:
from collections.abc import Callable
from abc import abstractmethod
and am still getting the same warning. Is there somewhere else I should be importing abstractmethod from?

I had the same issue with pytest. Check the warning message once again and make sure it is an issue with your imports. In my Python 3.7 environment it was some dependency package called pyreadlines that caused the error:
======== warnings summary ===============
C:\Users\Me\anaconda3\envs\myenv\lib\site-packages\pyreadline\py3k_compat.py:8
C:\Users\Me\anaconda3\envs\myenv\lib\site-packages\pyreadline\py3k_compat.py:8: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3,and in 3.9 it will stop working
return isinstance(x, collections.Callable)
-- Docs: https://docs.pytest.org/en/stable/warnings.html
Unfortunately pyreadline was already "up-to-date" and only supports Python up to 3.5 so there's no need to blame the maintainers.
Replacing the import statement in that file as you described in you post fixed the issue for me.

Why there are __version__ strings in some modules of Python standard library?

By accident I noticed that both csv and re modules of python standard library have their .__version__ attribute:
>>> import re, csv
>>> re.__version__
'2.2.1'
>>> csv.__version__
'1.0'
It surprises me as they are part of the standard library, so I would expect their version to be defined by sys.version (and sys.version_info).
I have noticed the values of the attributes are same for both Python 2.7.13 and 3.6.1, despite the modules have changed.
Are they just a kind of "code fossils" or are they somehow meaningful and programmers should pay attention to their values?

I can assume that the source version of the module on C did not change, only the source code of the python module has changed across different versions of python itself. Looking for source code in python repository can shed light into whole situation.
For example:
CSV C source code
CSV Python source code

Signature method in Inspect module for python 2

I am trying to run a Python 3 library in Python 2. It uses inspect module and signature method which is not implemented in Python 2 version of the module.
signature = inspect.signature(initializer)
There is no implementation in __future__ that can help (at least, I haven't found one).
How can I replace this method?

Package funcsigs on PyPI is a backport of PEP-362 (which adds signature introspection) to Python 2.6+. So change the line in question to
import funcsigs
signature = funcsigs.signature(initializer)

inspect2 is backport of the entire Python 3.6 inspect module to Python 2.7. Like funcsigs it is also available from PyPI, and inspect2 is more recently maintained. (As I'm writing this, inspect2 was last updated in 2019, while funcsigs was last updated in 2016.)

ENUM module and cStringIO module in PYVISA

I have some trouble to fix. I am using Python 3.2 with pyvisa for Python 3.2 32bits. When i used:
import pyvisa
It displayed:
ImportError: No module named enum
But when I use:
import pyqtgraph, pyvisa
I get:
ImportError: No module named cStringIO
I just want to use pyvisa for using an Agilent 33250a by GPIB.

The enum module wasn't part of Python until Python 3.4, so 3.2 is too early; you need to upgrade, or you need to live without enum (upgrading is a good idea mind you; the performance and features of Python have improved markedly since then; on performance in particular, strings and user defined class instances dramatically reduced their memory overhead). I'm guessing pyvisa dropped support for Python versions older than 3.4 if they're depending on enum.
cStringIO is a Python 2.x only accelerator module for StringIO; in Python 3.0 and higher, you just import io and use io.StringIO, and it will automatically use the C accelerated code under the hood when available, and pure Python code otherwise. If you're only targeting Python 3, just do import io or from io import StringIO. For code that should run under both Python 2 and Python 3, and use str in both, you can do the following for imports:
try:
from cStringIO import StringIO # Py2 C accelerated version
except ImportError:
try:
from StringIO import StringIO # Py2 fallback version
except ImportError:
from io import StringIO # Py3 version
If you want to handle Unicode text regardless of Python version (well, in 2.6 and up), you can just use io.StringIO exclusively; it works with unicode in Py2, and str in Py3, which means it handles all text in both versions (where cStringIO only handles str in Py2, so it can't handle the whole Unicode range).
I suspect your other import error for pyqtgraph would be because you tried installing a version of pyqtgraph written for Python 2; the pyqtgraph page claims Python 3.x compatibility, and use of cStringIO without a fallback would not meet that claim, so either you installed the wrong version, or it was installed incorrectly (e.g. if they were using a single code base and 2to3-ing it, but you somehow installed it without 2to3-ing it; no idea how you'd do that).