Le Fri, 21 Jun 2013 21:39:10 +1000, Nick Coghlan <ncogh...@gmail.com> a écrit :
> On 21 June 2013 17:25, Victor Stinner <victor.stin...@gmail.com> > wrote: > > 2013/6/21 Nick Coghlan <ncogh...@gmail.com>: > >> Because practicality beats purity. This "wrong" Python code has > >> been good enough for all Python version up until 3.4, it makes > >> sense to keep it as a fallback instead of throwing it away. > > > > How do you plan to handle the following case in Python? > > > > "Looking in more detail: for the S_IFMT flags, OSX/Darwin/FreeBSD > > defines 0xe000 as S_IFWHT (whiteout), but Solaris defines it as > > S_IFPORT (event port)." > > > > We may keep the Python module if it is kept unchanged, but the > > Python and C modules should have the same public API (the C module > > should not have more features). > > I think it's OK to expose additional platform specific features in the > C version, and have them fail cleanly with the pure Python version > (rather than silently giving the wrong answer). PEP 399 says we don't do it: "Acting as a drop-in replacement also dictates that no public API be provided in accelerated code that does not exist in the pure Python code. Without this requirement people could accidentally come to rely on a detail in the accelerated code which is not made available to other VMs that use the pure Python implementation." > What's not OK is for > the standard library to regress for other implementations just because > we added a C implementation for the benefit of CPython. That's exactly > the kind of thing PEP 399 says we *won't* do. For me, PEP 399 should not be considered a requirement but a guideline. stat.py is algorithmically trivial and I don't think it saves much work for authors of third-party Python implementations. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
