Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)
On 26 maj 2013, at 01:07, PJ Eby wrote: > The PEP uses the term "implementation", and I think that > actually makes a lot of sense: a generic function is composed of > functions that implement the same operation for different types. All suggested changes applied. There are still a couple of mentions of "overloads" and "overloading" in the PEP but they are unambiguous now and always refer to the general mechanism. > Last, but not least, there should be a stacking example somewhere in > the doc, as in the PEP I swapped the old examples from the docs and reused the PEP API docs in their entirety. This way it's easier to keep things consistent. > (It may also be useful to note somewhere that, due to caching, > changing the base classes of an existing class may not change what > implementation is selected the next time the generic function is > invoked with an argument of that type or a subclass thereof.) I don't think it's necessary. Abstract base classes present the same behaviour and this isn't documented anywhere: >>> from abc import ABC >>> class FirstABC(ABC): pass >>> class SecondABC(ABC): pass >>> class ImplementsFirst(FirstABC): pass >>> assert FirstABC in ImplementsFirst.__mro__ >>> assert issubclass(ImplementsFirst, FirstABC) If we change bases of the class, it no longer reports the first in the MRO: >>> ImplementsFirst.__bases__ = (SecondABC,) >>> assert FirstABC not in ImplementsFirst.__mro__ >>> assert SecondABC in ImplementsFirst.__mro__ >>> assert issubclass(ImplementsFirst, SecondABC) But it still reports being a subclass: >>> assert issubclass(ImplementsFirst, FirstABC), "sic!" -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ 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
Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)
On 26 maj 2013, at 03:37, Nick Coghlan wrote: > On Sun, May 26, 2013 at 9:07 AM, PJ Eby wrote: >> On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa wrote: >>> So, the latest document is live: >>> http://www.python.org/dev/peps/pep-0443/ >>> >>> The code is here: >>> http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l363 > > Hmm, I find the use of the variable name "dispatch_cache" for a cache > that dispatch() doesn't actually use to be confusing. Why? It's a cache for dispatches, hence "dispatch_cache". It might not be obvious at first, unless you're Polish ;) > It also doesn't make sense to me that dispatch() itself bypasses the > cache - I would expect all the cache manipulation to be in dispatch(), > and there to be a separate "_find_impl()" function that is invoked to > handle cache misses. This is exactly what I did now. I also exposed ._clear_cache() and the uncached ._find_impl() if somebody finds it necessary to use it. Both are left undocumented. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ 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
Re: [Python-Dev] PEP 8 and function names
> But one thing that often confuses people : function naming. The standard > library is kind of inconsistent. Some functions are separated by underscores > and others aren't. I think there are a number of reasons for this: * Despite PEP 8's age, significant chunks of the standard library predate it * Modules which are thin wrappers around various C libraries tend to mimic those libraries' names * Modules which were heavily influenced by similar libraries from other languages often carry over spelling * PEP 8 hasn't always been a checklist item for inclusion (not sure it even is today) * Sometimes Cerberus was sleeping, and they snuck past him In any case, once a module makes it into the standard library, the cost of changing spelling outweighs the benefits of slavish adherence to PEP 8. Skip ___ 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
Re: [Python-Dev] Bilingual scripts
On Sat, May 25, 2013 at 05:57:28PM +1000, Nick Coghlan wrote: > On Sat, May 25, 2013 at 5:56 AM, Barry Warsaw wrote: > > Have any other *nix distros addressed this, and if so, how do you solve it? > > I believe Fedora follows the lead set by our own makefile and just > appends a "3" to the script name when there is also a Python 2 > equivalent (thus ``pydoc3`` and ``pyvenv``). (I don't have any other > system provided Python 3 scripts on this machine, though) > Fedora is a bit of a mess... we try to work with upstream's intent when upstream has realized this problem exists and have a single standard when upstream does not. The full guidelines are here: http://fedoraproject.org/wiki/Packaging:Python#Naming Here's the summary: * If the scripts don't care whether they're running on py2 or py3, just use the base name and choose python2 as the interpreter for now (since we can't currently get rid of python2 on an end user system, that is the choice that brings in less dependencies). ex: /usr/bin/pygmentize * If the script does two different things depending on python2 or python3 being the interpreter (note: this includes both bilingual scripts and scripts which have been modified by 2to3/exist in two separate versions) then we have to look at what upstream is doing: - If upstream already deals with it (ex: pydoc3, easy_install-3.1) then we use upstream's name. We don't love this from an inter-package consistently standpoint as there are other packages which append a version for their own usage (is /usr/bin/foo-3.4 for python-3.4 or the 3.4 version of the foo package?) (And we sometimes have to do this locally if we need to have multiple versions of a package with the multiple versions having scripts... ) We decided to use upstream's name if they account for this issue because it will match with upstream's documentation and nothing else seemed as important in this instance. - If upstream doesn't deal with it, then we use a "python3-" prefix. This matches with our package naming so it seemed to make sense. (But Barry's point about locate and tab completion and such would be a reason to revisit this... Perhaps standardizing on /usr/bin/foo2-python3 [pathological case of having both package version and interpreter version in the name.] - (tangent from a different portion of this thread: we've found that this is a larger problem than we would hope. There are some obvious ones like - ipython (implements a python interpreter so python2 vs python3 is understandably important ad different). - nosetests (the python source being operated on is run through the python interpreter so the version has to match). - easy_install (needs to install python modules to the correct interpreter's site-packages. It decides the correct interpreter according to which interpreter invoked it.) But recently we found a new class of problems: frameworks which are bilinugual. For instance, if you have a web framework which has a /usr/bin/django-admin script that can be used to quickstart a project, run a python shell and automatically load your code, load your ORM db schema and operate on it to make modifications to the db then that script has to know whether your code is compatible with python2 or python3. > > It would be nice if we could have some cross-platform recommendations so > > things work the same wherever you go. To that end, if we can reach some > > consensus, I'd be willing to put together an informational PEP and some > > scripts that might be of general use. > > It seems to me the existing recommendation to use ``#!/usr/bin/env > python`` instead of referencing a particular binary already covers the > general case. The challenge for the distros is that we want a solution > that *ignores* user level virtual environments. > > I think the simplest thing to do is just append the "3" to the binary > name (as we do ourselves for pydoc) and then abide by the > recommendations in PEP 394 to reference the correct system executable. > I'd rather not have a bare 3 for the issues notes above. Something like py3 would be better. There's still room for confusion when distributions have to push multiple versions of a package with scripts that fall into this category. Should the format be: /usr/bin/foo2-py3 (My preference as it places the version next to the thing that it's a version of.) or /usr/bin/foo-py3-2 (Confusing as the 2 is bare. Something like /usr/bin/foo-py3-v2 is slightly better but still not as nice as the previous IMHO) -Toshio pgpOcm8nDJ4cG.pgp Description: PGP signature ___ 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
Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)
On 27 maj 2013, at 15:31, Łukasz Langa wrote: > This is exactly what I did now. I also exposed ._clear_cache() and the > uncached ._find_impl() if somebody finds it necessary to use it. Both > are left undocumented. For the record, I moved _find_impl out of the closure for easier testability. I also simplified it a bit as the results are cached anyway. For the most common case where the function argument is of a type that's directly registered, _find_impl isn't even called now. Anyhow, no remaining issues. Somebody call the BDFL. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ 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
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge with 3.3
2013/5/27 terry.reedy : > http://hg.python.org/cpython/rev/c5d4c041ab47 > changeset: 83942:c5d4c041ab47 > parent: 83940:2ea849fde22b > parent: 83941:24c3e7e08168 > user:Terry Jan Reedy > date:Mon May 27 21:33:40 2013 -0400 > summary: > Merge with 3.3 > > files: > Lib/idlelib/CallTips.py | 4 +- > Lib/idlelib/PathBrowser.py| 3 +- > Lib/idlelib/idle_test/@README.txt | 63 +++ Is @README really the intended name of this file? Would README-TEST or something similar be better? -- Regards, Benjamin ___ 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
