Mailman 3 February 2015 - Python-Dev

PEP 486: Make the Python Launcher aware of virtual environments
by Paul Moore Feb. 15, 2015

Feb. 15, 2015

On 12 February 2015 at 14:46, Paul Moore <p.f.moore(a)gmail.com> wrote: > If py.exe detected when the environment variable VIRTUAL_ENV was set, > and used that virtualenv as the default Python rather than the > "system" python it normally used, this would be perfect. > > I think I'll write a PEP for this. Do people think it's a reasonable idea? OK, here we go. https://www.python.org/dev/peps/pep-0486/ Reproduced inline below for ease of reading / commenting. It's also available on github at https://github.com/pfmoore/peps should people want to submit corrections or anything there. PEP: 486 Title: Make the Python Launcher aware of virtual environments Version: $Revision$ Last-Modified: $Date$ Author: Paul Moore <p.f.moore(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 12-Feb-2015 Python-Version: 3.5 Post-History: Abstract ======== The Windows installers for Python include a launcher that locates the correct Python interpreter to run (see PEP 397). However, the launcher is not aware of virtual environments (virtualenv [1]_ or PEP 405 based), and so cannot be used to run commands from the active virtualenv. This PEP proposes making the launcher "virtualenv aware". This means that when run without specifying an explicit Python interpreter to use, the launcher will use the currently active virtualenv, if any, before falling back to the configured default Python. Rationale ========= Windows users with multiple copies of Python installed need a means of selecting which one to use. The Python launcher provides this facility by means of a ``py`` command that can be used to run either a configured "default" Python or a specific interpreter, by means of command line arguments. So typical usage would be:: # Run the Python interactive interpreter py # Execute an installed module py -m pip install pytest py -m pytest When using virtual environments, the ``py`` launcher is unaware that a virtualenv is active, and will continue to use the system Python. So different command invocations are needed to run the same commands in a virtualenv:: # Run the Python interactive interpreter python # Execute an installed module (these could use python -m, # which is longer to type but is a little mopre similar to the # launcher approach) pip install pytest py.test Having to use different commands is is error-prone, and in many cases the error is difficult to spot immediately. The PEP proposes making the ``py`` command usable with virtual environments, so that the first form of command can be used in all cases. Implementation ============== Both ``virtualenv`` and the core ``venv`` module set an environment variable ``VIRTUAL_ENV`` when activating a virtualenv. This PEP proposes that the launcher checks for the ``VIRTUAL_ENV`` environment variable whenever it would run the "default" Python interpreter for the system (i.e., when no specific version flags such as ``py -2.7`` are used) and if present, run the Python interpreter for the virtualenv rather than the default system Python. The "default" Python interpreter referred to above is (as per PEP 397) either the latest version of Python installed on the system, or a version configured via the ``py.ini`` configuration file. When the user specifies an explicit Python version on the command line, this will always be used (as at present). Impact on Script Launching ========================== As well as interactive use, the launcher is used as the Windows file association for Python scripts. In that case, a "shebang" (``#!``) line at the start of the script is used to identify the interpreter to run. A fully-qualified path can be used, or a version-specific Python (``python3`` or ``python2``, or even ``python3.5``), or the generic ``python``, which means to use the default interpreter. With the proposed change, scripts that start with ``#!python`` (or one of its equivalent forms) will be run using an active virtualenv. This is a change in behaviour, although it will only affect users running scripts from the command line with a virtualenv activated. Under Unix, the ``#!/usr/bin/env python`` shebang line will use the version of Python found on ``$PATH``, whereas ``#!/usr/bin/python`` will use the system Python. In order to match Unix behaviour as closely as possible, it is proposed that the two shebang forms:: #!/usr/bin/env python #!python use an active virtualenv, if present, whereas the forms:: #!/usr/bin/python #!/usr/local/bin/python use *only* the default system Python, and ignore the ``VIRTUAL_ENV`` environment variable. Exclusions ========== The PEP makes no attempt to promote the use of the launcher for running Python on Windows. Most existing documentation assumes the user of ``python`` as the command to run Python, and (for example) ``pip`` to run an installed Python command. This documentation is not expected to change, and users who choose to manage their ``PATH`` environment variable can continue to use this form. The focus of this PEP is purely on allowing users who prefer to use the launcher when dealing with their system Python installations, to be able to continue to do so when using virtual environments. References ========== .. [1] https://virtualenv.pypa.io/ Copyright ========= This document has been placed in the public domain.

3 5

Re: [Python-Dev] subclassing builtin data structures
by Isaac Schwabacher Feb. 15, 2015

Feb. 15, 2015

On 15-02-13, Guido van Rossum wrote: > Are you willing to wait 10 days for an answer? I'm out of round tuits for a while. IIUC, the argument is that the Liskov Substitution Principle is a statement about how objects of a subtype behave relative to objects of a supertype, and it doesn't apply to constructors because they aren't behaviors of existing objects. So other overriding methods *should* be able to handle the same inputs that the respective overridden methods do, but constructors don't need to. Even though __init__ is written as an instance method, it seems like it's "morally" a part of the class method __new__ that's only split off for convenience. If this message is unclear, it's because I don't really understand this myself and I'm trying to articulate my best understanding of what's been said on this thread and those it links to. ijs > On Fri, Feb 13, 2015 at 10:22 AM, Alexander Belopolsky <alexander.belopolsky@gmail.com(javascript:main.compose()> wrote: > > > > > On Fri, Feb 13, 2015 at 1:19 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com(javascript:main.compose()> wrote: > > >> > > >> FWIW you're wrong when you claim that "a constructor is no different from any other method". Someone else should probably explain this (it's an old argument that's been thoroughly settled). > > > > > > > > > Well, the best answer I've got in the past [1] was "ask on python-dev since Guido called the operator overriding expectation." :-) > > > > > > And let me repost this bit of history [1]: > > > > Here is the annotated pre-r82065 code: > > > > 39876 gvanrossum def __add__(self, other): > > 39876 gvanrossum if isinstance(other, timedelta): > > 39928 gvanrossum return self.__class__(self.__days + other.__days, > > 39876 gvanrossum self.__seconds + other.__seconds, > > 39876 gvanrossum self.__microseconds + other.__microseconds) > > 40207 tim_one return NotImplemented > > 39876 gvanrossum > > > > > > > > [1] http://bugs.python.org/issue2267#msg125979 > > > > > > > > > -- > --Guido van Rossum (python.org/~guido(http://python.org/~guido))

9 15

Can I replace distutils.msvccompiler?
by Steve Dower Feb. 15, 2015

Feb. 15, 2015

I'm about to start doing a rework on distutils.msvc[9]compiler.MSVCCompiler for Python 3.5 to be able to handle forward-compatibility better. Right now I've tweaked msvc9compiler enough for VS 2015, but it won't handle later VS versions automatically. Is there any reason to keep the old msvccompiler and msvc9compiler modules around? If possible I'd like to drop them completely and just have one implementation (probably distutils.msvccompiler.MSVCCompiler again). Obviously it will be behaviourally compatible with 3.4 and compatible with the CCompiler interface, but it may not be function-for-function compatible with distutils.msvc9compiler (e.g. get_build_version is not useful). Do we need a deprecation period? msvccompiler is mentioned in the docs, but not documented, and msvc9compiler is not even mentioned. Thanks, Steve

1 0

PEP 471 (scandir): Add a new DirEntry.inode() method?
by Victor Stinner Feb. 14, 2015

Feb. 14, 2015

Hi, TL;DR: on POSIX, is it useful to know the inode number (st_ino) without the device number (st_dev)? While reading feedback on the Python 3.5 alpha 1 release, I saw a comment saying that the current design of os.scandir() (PEP 471) doesn't fit a very specific usecase where the inode number is needed: "Ah, turns out we needed even more optimizations than that is able to give us; in particular, the underlying system readdir call gives us the inode number, which we need to compare against a cache of hard links, in order to avoid having to stat the underlying files if we've already done so on another hard link. It looks like the DirEntry API used here only includes the path and name, not the inode number, without invoking another stat call, and we needed to optimize out that extra stat call." https://www.reddit.com/r/Python/comments/2synry/so_8_peps_are_currently_bei… Since the C function readdir() provides the inode number (d_ino field of the dirent structure), I propose add a new DirEntry.inode() method. *** Now the real question: is it useful to know the inode number (st_ino) without the device number (st_dev)? *** On POSIX, you can still get the st_dev from DirEntry.stat(), but it always require a system call. So you loose the whole purpose of DirEntry (no extra syscall). I wrote a script script check_stdev.py, attached to this email, to check if all entries of a directory have the same st_dev value than the directory itself: - same for /usr/bin, /usr/lib, /tmp, /proc, ... - different for /dev What about "union" file systems like UnionFS or thinks like "mount -o bind"? Can someone test? Does anyone have some information? So the answer looks to be: it's useful for all directories except of /dev. Example: --- /dev/hugepages st_dev is different: 35 vs 5 /dev/mqueue st_dev is different: 13 vs 5 /dev/pts st_dev is different: 11 vs 5 /dev/shm st_dev is different: 17 vs 5 --- On POSIX, DirEntry.inode() just exposes the d_ino value from readdir(). On Windows, FirstFindFileW/FindFindFileW returns almost a full stat_result structure, except of st_ino, st_dev and st_nlink fields which are set to 0. So DirEntry.inode() has to call os.lstat() to read the inode number. The inode number will be cached by DirEntry.inode() in the DirEntry object, but the os.lstat() result is dropped. On Windows, I don't want to cache the full os.lstat() result from DirEntry.inode() into DirEntry to replace the previous incomplete stat_result from FirstFindFileW/FindFindFileW, because DirEntry.stat() would return a different result (st_ino, st_dev, st_nlink fields set or not) depending if the inode() methode was called or not. Note: scandir-6.patch of http://bugs.python.org/issue22524 contains an implementation of os.scandir() with DirEntry.inode(), if you want to play. Victor

8 14

PEP 471 (scandir): Poll to choose the implementation (full C or C+Python)
by Victor Stinner Feb. 14, 2015

Feb. 14, 2015

Hi, TL,DR: are you ok to add 800 lines of C code for os.scandir(), 4x faster than os.listdir() when the file type is checked? I accepted the PEP 471 (os.scandir) a few months ago, but it is not implement yet in Python 3.5, because I didn't make a choice on the implementation. Ben Hoyt wrote different implementations: - full C: os.scandir() and DirEntry are written in C (no change on os.py) - C+Python: os._scandir() (wrapper for opendir/readdir and FindFirstFileW/FindNextFileW) in C, DirEntry in Python - ctypes: os.scandir() and DirEntry fully implemented in Python I'm not interested by the ctypes implementation. It's useful for a third party project hosted at PyPI, but for CPython I prefer to wrap C functions using C code. In short, the C implementation is faster than the C+Python implementation. The issue #22524 (*) is full of benchmark numbers. IMO the most interesting benchmark is to compare os.listdir() + os.stat() versus os.scandir() + Direntry.is_dir(). Let me try to summarize results of this benchmark: * C implementation: scandir is at least 3.5x faster than listdir, up to 44.6x faster on Windows * C+Python implementation: scandir is not really faster than listdir, between 1.3x and 1.4x faster (*) http://bugs.python.org/issue22524 Ben Hoyt reminded me that os.scandir() (PEP 471) doesn't add any new feature: pathlib already provides a nice API on top of os and os.path modules. (You may even notice that DirEntry a much fewer methods ;-)) The main (only?) purpose of the PEP is performance. If os.scandir() is "only" 1.4x faster, I don't think that it is interesting to use os.scandir() in an application. I guess that all applications/libraries will want to keep compatibility with Python 3.4 and older and so will anyway have to duplicate the code to use os.listdir() + os.stat(). So is it worth to duplicate code for such small speedup? Now I see 3 choices: - take the full C implementation, because it's much faster (at least 3.4x faster!) - reject the whole PEP 471 (not nice), because it adds too much code for a minor speedup (not true on Windows: up to 44x faster!) - take the C+Python implementation, because maintenance matters more than performances (only 1.3x faster, sorry) => IMO the best option is to take the C implementation. What do you think? I'm concerned by the length of the C code: the full C implementations adds ~800 lines of C code to posixmodule.c. This file is already the longest C file in CPython. I don't want to make it longer, but I'm not motived to start to split it. Last time I proposed to split a file (unicodeobject.c), some developers complained that it makes search harder. I don't understand this, there are so many tools to navigate in C code. But it was enough for me to give up on this idea. A alternative is to add a new _scandir.c module to host the new C code, and share some code with posixmodule.c: remove "static" keyword from required C functions (functions to convert Windows attributes to a os.stat_result object). That's a reasonable choice. What do you think? FYI I ran the benchmark on different hardware (SSD, HDD, tmpfs), file systems (ext4, tmpfs, NFS/ext4), operating systems (Linux, Windows). Victor

11 19

subclassing builtin data structures
by Ethan Furman Feb. 14, 2015

Feb. 14, 2015

I suspect the last big hurdle to making built-in data structures nicely subclassable is the insistence of such types to return new instances as the base class instead of the derived class. In case that wasn't clear ;) --> class MyInt(int): ... def __repr__(self): ... return 'MyInt(%d)' % self ... --> m = MyInt(42) --> m MyInt(42) --> m + 1 43 --> type(m+1) <class 'int'> Besides the work it would take to rectify this, I imagine the biggest hurdle would be the performance hit in always looking up the type of self. Has anyone done any preliminary benchmarking? Are there other concerns? -- ~Ethan~

12 27

Re: [Python-Dev] subclassing builtin data structures
by Isaac Schwabacher Feb. 14, 2015

Feb. 14, 2015

Hmm... super *is* a problem, because if we super, we can end up asking superclasses that we then won't know how to mimic. So what we really want is to move the superclasses we can mimic to the front of the MRO. If none of those can indirectly mimic the base class, then we try the other classes in the MRO to see if we can get a partial upgrade. On 15-02-13, Neil Girdhar wrote: > I think it works as Isaac explained if __make_me__ is an instance method that also accepts the calling class type. > > On Fri, Feb 13, 2015 at 8:12 PM, Ethan Furman <Python-Dev(a)python.org <ethan(a)stoneleaf.us')" target="1">ethan(a)stoneleaf.us> wrote: > > > On 02/13/2015 02:31 PM, Serhiy Storchaka wrote: > > > On 13.02.15 05:41, Ethan Furman wrote: > > >> So there are basically two choices: > > >> > > >> 1) always use the type of the most-base class when creating new instances > > >> > > >> pros: > > >> - easy > > >> - speedy code > > >> - no possible tracebacks on new object instantiation > > >> > > >> cons: > > >> - a subclass that needs/wants to maintain itself must override all > > >> methods that create new instances, even if the only change is to > > >> the type of object returned > > >> > > >> 2) always use the type of self when creating new instances > > >> > > >> pros: > > >> - subclasses automatically maintain type > > >> - much less code in the simple cases [1] > > >> > > >> cons: > > >> - if constructor signatures change, must override all methods which > > >> create new objects > > > > > > And switching to (2) would break existing code which uses subclasses with constructors with different signature (e.g. > > > defaultdict). > > > > I don't think defaultdict is a good example -- I don't see any methods on it that return a new dict, default or > > otherwise. So if this change happened, defaultdict would have to have its own __add__ and not rely on dict's __add__. > > > > > > > The third choice is to use different specially designed constructor. > > > > > > class A(int): > > > > > > --> class A(int): > > > ... def __add__(self, other): > > > ... return self.__make_me__(int(self) + int(other)) > > > > > > ... def __repr__(self): > > > ... return 'A(%d)' % self > > > > How would this help in the case of defaultdict? __make_me__ is a class method, but it needs instance info to properly > > create a new dict with the same default factory. > > > > -- > > ~Ethan~ > > > > > > _______________________________________________ > > Python-Dev mailing list > > https://mail.python.org/mailman/listinfo/python-dev(javascript:main.compose('new', 't=Python-Dev(a)python.org> > > <a href=) > > Unsubscribe: https://mail.python.org/mailman/options/python-dev/mistersheik%40gmail.com > > > >

1 0

Re: [Python-Dev] subclassing builtin data structures
by Isaac Schwabacher Feb. 14, 2015

Feb. 14, 2015

On 15-02-13, Neil Girdhar wrote: > Unlike a regular method, you would never need to call super since you should know everyone that could be calling you. Typically, when you call super, you have something like this: > > A < B, C > > > B < D > > > so you end up with > > > mro: A, B, C, D > > > And then when A calls super and B calls super it gets C which it doesn't know about. But C calls super and gets D. The scenario I'm concerned with is that A knows how to mimic B's constructor and B knows how to mimic D's, but A doesn't know about D. So D asks A if it knows how to mimic D's constructor, and it says no. Via super, B gets a shot, and it does know, so it translates the arguments to D's constructor into arguments to B's constructor, and again asks A if it knows how to handle them. Then A says yes, translates the args, and constructs an A. If C ever gets consulted, it responds "I don't know a thing" and calls super. > But in the case of make_me, it's someone like C who is calling make_me. If it gets a method in B, then that's a straight-up bug. make_me needs to be reimplemented in A as well, and A would never delegate up since other classes in the mro chain (like B) might not know about C. This scheme (as I've written it) depends strongly on all the classes in the MRO having __make_me__ methods with this very precisely defined structure: test base against yourself, then any superclasses you care to mimic, then call super. Any antisocial superclass ruins everyone's party. > Best, > Neil > > > On Fri, Feb 13, 2015 at 7:00 PM, Isaac Schwabacher <alexander.belopolsky(a)gmail.com <ischwabacher(a)wisc.edu')" target="1">ischwabacher(a)wisc.edu> wrote: > > > On 15-02-13, Neil Girdhar wrote: > > > I personally don't think this is a big enough issue to warrant any changes, but I think Serhiy's solution would be the ideal best with one additional parameter: the caller's type. Something like > > > > > > def __make_me__(self, cls, *args, **kwargs) > > > > > > > > > and the idea is that any time you want to construct a type, instead of > > > > > > > > > self.__class__(assumed arguments…) > > > > > > > > > where you are not sure that the derived class' constructor knows the right argument types, you do > > > > > > > > > def SomeCls: > > > def some_method(self, ...): > > > return self.__make_me__(SomeCls, assumed arguments…) > > > > > > > > > Now the derived class knows who is asking for a copy. In the case of defaultdict, for example, he can implement __make_me__ as follows: > > > > > > > > > def __make_me__(self, cls, *args, **kwargs): > > > if cls is dict: return default_dict(self.default_factory, *args, **kwargs) > > > return default_dict(*args, **kwargs) > > > > > > > > > essentially the caller is identifying himself so that the receiver knows how to interpret the arguments. > > > > > > > > > Best, > > > > > > > > > Neil > > > > Such a method necessarily involves explicit switching on classes... ew. > > Also, to make this work, a class needs to have a relationship with its superclass's superclasses. So in order for DefaultDict's subclasses not to need to know about dict, it would need to look like this: > > > > class DefaultDict(dict): > > ....@classmethod # instance method doesn't make sense here > > ....def __make_me__(cls, base, *args, **kwargs): # make something like base(*args, **kwargs) > > ........# when we get here, nothing in cls.__mro__ above DefaultDict knows how to construct an equivalent to base(*args, **kwargs) using its own constructor > > ........if base is DefaultDict: > > ............return DefaultDict(*args, **kwargs) # if DefaultDict is the best we can do, do it > > ........elif base is dict: > > ............return cls.__make_me__(DefaultDict, None, *args, **kwargs) # subclasses that know about DefaultDict but not dict will intercept this > > ........else: > > ............super(DefaultDict, cls).__make_me__(base, *args, **kwargs) # we don't know how to make an equivalent to base.__new__(*args, **kwargs), so keep looking > > > > I don't even think this is guaranteed to construct an object of class cls corresponding to a base(*args, **kwargs) even if it were possible, since multiple inheritance can screw things up. You might need to have an explicit list of "these are the superclasses whose constructors I can imitate", and have the interpreter find an optimal path for you. > > > > > On Fri, Feb 13, 2015 at 5:55 PM, Alexander Belopolsky <http://stackoverflow.com/questions/5490824/should-constructors-comply-with-…'new', 't=alexander.belopolsky(a)gmail.com>(java_script:main.compose()> wrote: > > > > > > > > > > > On Fri, Feb 13, 2015 at 4:44 PM, Neil Girdhar <mistersheik(a)gmail.com <mistersheik(a)gmail.com>(java_script:main.compose()> wrote: > > > > > > > > > Interesting: > > Not every language allows you to call self.__class__(). In the languages that don't you can get away with incompatible constructor signatures. > > > > > > > > > > > > However, let me try to focus the discussion on a specific issue before we go deep into OOP theory. > > > > > > > > > > > > With python's standard datetime.date we have: > > > > > > > > > > > > >>> from datetime import * > > > > >>> class Date(date): > > > > ... pass > > > > ... > > > > >>> Date.today() > > > > Date(2015, 2, 13) > > > > >>> Date.fromordinal(1) > > > > Date(1, 1, 1) > > > > > > > > > > > > Both .today() and .fromordinal(1) will break in a subclass that redefines __new__ as follows: > > > > > > > > > > > > >>> class Date2(date): > > > > ... def __new__(cls, ymd): > > > > ... return date.__new__(cls, *ymd) > > > > ... > > > > >>> Date2.today() > > > > Traceback (most recent call last): > > > > File "<stdin>", line 1, in <module> > > > > TypeError: __new__() takes 2 positional arguments but 4 were given > > > > >>> Date2.fromordinal(1) > > > > Traceback (most recent call last): > > > > File "<stdin>", line 1, in <module> > > > > TypeError: __new__() takes 2 positional arguments but 4 were given > > > > > > > > > > > > > > > > > > > > Why is this acceptable, but we have to sacrifice the convenience of having Date + timedelta > > > > return Date to make it work with Date2: > > > > > > > > > > > > >>> Date2((1,1,1)) + timedelta(1) > > > > datetime.date(1, 1, 2) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

2 1

Re: [Python-Dev] subclassing builtin data structures
by Isaac Schwabacher Feb. 14, 2015

Feb. 14, 2015

On 15-02-13, Neil Girdhar wrote: > I personally don't think this is a big enough issue to warrant any changes, but I think Serhiy's solution would be the ideal best with one additional parameter: the caller's type. Something like > > def __make_me__(self, cls, *args, **kwargs) > > > and the idea is that any time you want to construct a type, instead of > > > self.__class__(assumed arguments…) > > > where you are not sure that the derived class' constructor knows the right argument types, you do > > > def SomeCls: > def some_method(self, ...): > return self.__make_me__(SomeCls, assumed arguments…) > > > Now the derived class knows who is asking for a copy. In the case of defaultdict, for example, he can implement __make_me__ as follows: > > > def __make_me__(self, cls, *args, **kwargs): > if cls is dict: return default_dict(self.default_factory, *args, **kwargs) > return default_dict(*args, **kwargs) > > > essentially the caller is identifying himself so that the receiver knows how to interpret the arguments. > > > Best, > > > Neil Such a method necessarily involves explicit switching on classes... ew. Also, to make this work, a class needs to have a relationship with its superclass's superclasses. So in order for DefaultDict's subclasses not to need to know about dict, it would need to look like this: class DefaultDict(dict): ....@classmethod # instance method doesn't make sense here ....def __make_me__(cls, base, *args, **kwargs): # make something like base(*args, **kwargs) ........# when we get here, nothing in cls.__mro__ above DefaultDict knows how to construct an equivalent to base(*args, **kwargs) using its own constructor ........if base is DefaultDict: ............return DefaultDict(*args, **kwargs) # if DefaultDict is the best we can do, do it ........elif base is dict: ............return cls.__make_me__(DefaultDict, None, *args, **kwargs) # subclasses that know about DefaultDict but not dict will intercept this ........else: ............super(DefaultDict, cls).__make_me__(base, *args, **kwargs) # we don't know how to make an equivalent to base.__new__(*args, **kwargs), so keep looking I don't even think this is guaranteed to construct an object of class cls corresponding to a base(*args, **kwargs) even if it were possible, since multiple inheritance can screw things up. You might need to have an explicit list of "these are the superclasses whose constructors I can imitate", and have the interpreter find an optimal path for you. > On Fri, Feb 13, 2015 at 5:55 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com(javascript:main.compose()> wrote: > > > > > On Fri, Feb 13, 2015 at 4:44 PM, Neil Girdhar <mistersheik@gmail.com(javascript:main.compose()> wrote: > > > > > Interesting: http://stackoverflow.com/questions/5490824/should-constructors-comply-with-… > > > > > > > > > Let me humbly conjecture that the people who wrote the top answers have background in less capable languages than Python. > > > > > > Not every language allows you to call self.__class__(). In the languages that don't you can get away with incompatible constructor signatures. > > > > > > However, let me try to focus the discussion on a specific issue before we go deep into OOP theory. > > > > > > With python's standard datetime.date we have: > > > > > > >>> from datetime import * > > >>> class Date(date): > > ... pass > > ... > > >>> Date.today() > > Date(2015, 2, 13) > > >>> Date.fromordinal(1) > > Date(1, 1, 1) > > > > > > Both .today() and .fromordinal(1) will break in a subclass that redefines __new__ as follows: > > > > > > >>> class Date2(date): > > ... def __new__(cls, ymd): > > ... return date.__new__(cls, *ymd) > > ... > > >>> Date2.today() > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > TypeError: __new__() takes 2 positional arguments but 4 were given > > >>> Date2.fromordinal(1) > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > TypeError: __new__() takes 2 positional arguments but 4 were given > > > > > > > > > > Why is this acceptable, but we have to sacrifice the convenience of having Date + timedelta > > return Date to make it work with Date2: > > > > > > >>> Date2((1,1,1)) + timedelta(1) > > datetime.date(1, 1, 2) > > > > > > > > > > > > > > > > > > > >

2 1

Building on Windows - importlib.h changed
by Paul Moore Feb. 13, 2015

Feb. 13, 2015

I'm working on a patch for the Python launcher. I built Python (current tip, on MS Windows, with VS 2015), and I've just noticed that hg status shows: >>hg status -mard M Doc\using\windows.rst M PC\launcher.c M Python\importlib.h I didn't change importlib.h, and I don't see that the changes I did make would affect importlib. I presume I'm OK *not* including the importlib.h change in my patch? Paul PS By the way, the Windows build process is beautifully clean these days. Many thanks to Steve Dower and whoever else has worked on streamlining it!

3 4