Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Hello, On Fri, 11 Oct 2013 07:39:48 +0200 (CEST) raymond.hettinger wrote: > http://hg.python.org/cpython/rev/f014b5f0773f > changeset: 86209:f014b5f0773f > user:Raymond Hettinger > date:Thu Oct 10 22:39:39 2013 -0700 > summary: > Rename contextlib.ignored() to contextlib.ignore(). I don't think that this contextlib.ignore() thing has been discussed a lot. Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my -1 too. This is a useless addition (the traditional idiom is perfectly obvious) and makes reading foreign code more tedious by adding superfluous API calls. Please consider reverting. There is absolutely zero use case for this that wasn't already solved by the traditional "except ...: pass" idiom. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Let me answer here to Nick's argument on the tracker (made last year, before the patch was committed): > As with many context managers, a key benefit here is in the priming > effect for readers. In this code: > > try: ># Whatever > except (A, B, C): >pass > > the reader doesn't know that (A, B, C) exceptions will be ignored > until the end. The with statement form makes it clear before you > start reading the code that certain exceptions won't propagate: > > with ignored(A, B, C): > # Whatever The problem with this argument is that it assumes a very specific idiom: i.e. writing long "try" blocks in the purpose of silencing exceptions. I'd like to make the following points: - when catching an exception, the common (and recommended) behaviour is to do something else - not merely silencing it. Silencing is not very common in my experience, except in badly written code - when catching an exception, it is recommended for the "try" block to be as slim as possible - so that you don't catch other unintended exceptions by mistake. This is a point I already made in PEP 3151. Many exception classes (OSError, KeyError, RuntimeError...) are polysemic. The bottom line is that there shouldn't be any long "try" blocks followed by a single "except FooException: pass" clause in well-written code. The presence of such an idiom is a strong code smell. Therefore contextlib.ignore() seems aimed at making it easier to write bad code, not good code. I don't think it should exist in the stdlib. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
[We are discussing issue #15806.] 2013/10/11 Antoine Pitrou : > I don't think that this contextlib.ignore() thing has been discussed a > lot. If we decide to keep the feature, I would prefer a less generic name: contextlib.ignore_excep(), contextlib.ignore_exception() or contextlib.ignore_exceptions(). > Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my > -1 too. This is a useless addition (the traditional idiom is perfectly > obvious) and makes reading foreign code more tedious by adding > superfluous API calls. > > Please consider reverting. There is absolutely zero use case for this > that wasn't already solved by the traditional "except ...: pass" idiom. The purpose of the new context manager is to reduce the number of line of code? It goes a little bit against a Zen Principle: There should be one-- and preferably only one --obvious way to do it. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 5:00 AM, Antoine Pitrou wrote: > > Let me answer here to Nick's argument on the tracker (made last year, > before the patch was committed): > >> As with many context managers, a key benefit here is in the priming >> effect for readers. In this code: >> >> try: >># Whatever >> except (A, B, C): >>pass >> >> the reader doesn't know that (A, B, C) exceptions will be ignored >> until the end. The with statement form makes it clear before you >> start reading the code that certain exceptions won't propagate: >> >> with ignored(A, B, C): >> # Whatever > > The problem with this argument is that it assumes a very specific idiom: > i.e. writing long "try" blocks in the purpose of silencing exceptions. > > I'd like to make the following points: > > - when catching an exception, the common (and recommended) behaviour is > to do something else - not merely silencing it. Silencing is not very > common in my experience, except in badly written code > > - when catching an exception, it is recommended for the "try" block to > be as slim as possible - so that you don't catch other unintended > exceptions by mistake. This is a point I already made in PEP 3151. > Many exception classes (OSError, KeyError, RuntimeError...) are > polysemic. > > The bottom line is that there shouldn't be any long "try" blocks > followed by a single "except FooException: pass" clause in well-written > code. The presence of such an idiom is a strong code smell. > > Therefore contextlib.ignore() seems aimed at making it easier to write > bad code, not good code. I don't think it should exist in the stdlib. In case anyone wants to look at the original issue, it's http://bugs.python.org/issue15806 And Antoine has again taught me a new word: polysemic: having more than one meaning; having multiple meanings -- Eric. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEPs shouldn't be considered docs
I wanted to teach a co-worker about "from __future__ import absolute_import" today, so I thought I'd point them at the docs. The page for "__future__" starts with a bunch of internal details that almost no one needs to know. There's a table at the end that mentions the actual importable names, including "absolute_import", but says nothing about then except to link to a PEP. The absolute imports PEP has no simple description of what it does. Like many PEPs, it's mostly a summary of the debate around the design of the feature. The closest the PEP comes to describing the behavior of "absolute_import" is this parenthetical: For the second problem, it is proposed that all import statements be absolute by default (searching sys.path only) with special syntax (leading dots) for accessing package-relative imports. And notice: that sentence describes it as a "proposal." I'd like to suggest that we not consider PEPs to be documentation. If a PEP has a good succinct description of how something works, then let's copy that text into the documentation at an appropriate place. If a PEP doesn't have such a description, then all the more reason not to send readers there. A link to the PEP is appropriate as a "see also" in the docs, but we shouldn't pretend that a PEP addresses the needs of people new to the feature. --Ned. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
11.10.13 13:33, Eric V. Smith написав(ла): And Antoine has again taught me a new word: polysemic: having more than one meaning; having multiple meanings There is no such word in my dictionaries. :( Only polysemous and polysemantic. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] C extension import time
Hi,
recently there has been some talk about reducing import times. It seems
that the current import strategy for C extensions (i.e. importing the
extension at the bottom of the .py file) is quite slow:
import sys
for i in range(1):
import decimal
del sys.modules('decimal')
del sys.modules('_decimal')
With the regular decimal.py the script is about 9 times slower than running
it with a modified decimal.py that just contains "from _decimal import *".
I don't know enough about the import mechanism to say whether this is
a particularly good benchmark. If it is, perhaps we should devise another
strategy for loading C extensions.
Stefan Krah
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C extension import time
Stefan Krah wrote:
> import sys
>
> for i in range(1):
> import decimal
> del sys.modules('decimal')
> del sys.modules('_decimal')
^^^
This happens when a Linux user is forced to use Putty :(
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 11/10/2013 11:33, Eric V. Smith wrote: And Antoine has again taught me a new word: polysemic: having more than one meaning; having multiple meanings IMHO a poor word to use. I'm a middle aged Brit who's never heard of it so people who have English as a second language have little or no chance :( -- Roses are red, Violets are blue, Most poems rhyme, But this one doesn't. Mark Lawrence ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C extension import time
Le Fri, 11 Oct 2013 14:24:29 +0200,
Stefan Krah a écrit :
> Hi,
>
> recently there has been some talk about reducing import times. It
> seems that the current import strategy for C extensions (i.e.
> importing the extension at the bottom of the .py file) is quite slow:
>
>
>
>
> import sys
>
> for i in range(1):
> import decimal
> del sys.modules('decimal')
> del sys.modules('_decimal')
>
>
Try the following:
$ ./python -m timeit -s "modname='decimal'; import sys" \
"__import__(modname); del sys.modules[modname]"
1000 loops, best of 3: 2.21 msec per loop
$ ./python -m timeit -s "modname='_decimal'; import sys" \
"__import__(modname); del sys.modules[modname]"
1 loops, best of 3: 112 usec per loop
Now compare with the time taken to simply find the module loader:
$ ./python -m timeit -s "modname='_decimal'; import importlib" \
"importlib.find_loader(modname)"
1 loops, best of 3: 87.2 usec per loop
So find_loader() is the bigger contributor here. Note that find_loader()
can have varying performance:
$ touch empty.py
$ ./python -m timeit -s "modname='empty'; import importlib" \
"importlib.find_loader(modname)"
1 loops, best of 3: 24.4 usec per loop
When trying to improve import performance, I noticed that merely
diagnosing the bottlenecks is not always easy.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
2013/10/11 Mark Lawrence : > On 11/10/2013 11:33, Eric V. Smith wrote: >> >> >> And Antoine has again taught me a new word: >> polysemic: having more than one meaning; having multiple meanings >> > > IMHO a poor word to use. I'm a middle aged Brit who's never heard of it so > people who have English as a second language have little or no chance :( OTOH, it's etymology is quite clear, so those with a little in experience in Greek should have no trouble. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs shouldn't be considered docs
2013/10/11 Ned Batchelder : > I wanted to teach a co-worker about "from __future__ import absolute_import" > today, so I thought I'd point them at the docs. The page for "__future__" > starts with a bunch of internal details that almost no one needs to know. > There's a table at the end that mentions the actual importable names, > including "absolute_import", but says nothing about then except to link to a > PEP. > > The absolute imports PEP has no simple description of what it does. Like > many PEPs, it's mostly a summary of the debate around the design of the > feature. The closest the PEP comes to describing the behavior of > "absolute_import" is this parenthetical: > > For the second problem, it is proposed that all import statements be > absolute by default (searching sys.path only) with special syntax (leading > dots) for accessing package-relative imports. > > And notice: that sentence describes it as a "proposal." > > I'd like to suggest that we not consider PEPs to be documentation. If a PEP > has a good succinct description of how something works, then let's copy that > text into the documentation at an appropriate place. If a PEP doesn't have > such a description, then all the more reason not to send readers there. +1 The writing required to specificy and adovocate a feature are usually quite different from that needed to document it. PEPs also get out of date rather quickly. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs shouldn't be considered docs
On Oct 11, 2013, at 07:24 AM, Ned Batchelder wrote: >I'd like to suggest that we not consider PEPs to be documentation. Absolutely +1. That was never the intention behind PEPs. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Le Fri, 11 Oct 2013 13:51:24 +0100, Mark Lawrence a écrit : > On 11/10/2013 11:33, Eric V. Smith wrote: > > > > And Antoine has again taught me a new word: > > polysemic: having more than one meaning; having multiple meanings > > > > IMHO a poor word to use. I'm a middle aged Brit who's never heard of > it so people who have English as a second language have little or no > chance :( English is my second language. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 11, 2013, at 09:24 AM, Antoine Pitrou wrote: >I don't think that this contextlib.ignore() thing has been discussed a >lot. > >Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my >-1 too. This is a useless addition (the traditional idiom is perfectly >obvious) and makes reading foreign code more tedious by adding >superfluous API calls. > >Please consider reverting. There is absolutely zero use case for this >that wasn't already solved by the traditional "except ...: pass" idiom. I'm +0; I think it's a nice little addition that could be useful, but I don't care enough to wait for 3.4 to delete similar code in a my own programs. To bikeshed though: why was `ignored` changed to `ignore`? The former reads better to me, and I don't think *that* particular change was discussed at all in the tracker afaict. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C extension import time
Antoine Pitrou wrote: > Try the following: > > $ ./python -m timeit -s "modname='decimal'; import sys" \ > "__import__(modname); del sys.modules[modname]" > 1000 loops, best of 3: 2.21 msec per loop > > $ ./python -m timeit -s "modname='_decimal'; import sys" \ > "__import__(modname); del sys.modules[modname]" > 1 loops, best of 3: 112 usec per loop > > > Now compare with the time taken to simply find the module loader: > > $ ./python -m timeit -s "modname='_decimal'; import importlib" \ > "importlib.find_loader(modname)" > 1 loops, best of 3: 87.2 usec per loop > > > So find_loader() is the bigger contributor here. I'm getting about the same values as above. I may be misunderstanding something, but I wanted to reduce the difference between the 2.21 msec and the 112 usec. So the first step I tried is something horrible (typing from memory): try: import _decimal except ImportError: else: from _decimal import * That way the 2.21 msec are reduced to 912 usec, but the indentation is an abomination. Another radical way would be to have importlib detect that the C version is present and load it in the first place. For _decimal this should work, since it's self-contained. For other modules probably not, so there would need to be some way of distiguishing between modules that are self-contained and modules that are not. Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C extension import time
Le Fri, 11 Oct 2013 17:01:35 +0200, Stefan Krah a écrit : > > I'm getting about the same values as above. I may be misunderstanding > something, but I wanted to reduce the difference between the 2.21 msec > and the 112 usec. So you aren't complaining about C extension import time, but Python code import time, right? > So the first step I tried is something horrible (typing from memory): > > try: > import _decimal > except ImportError: > > else: > from _decimal import * > > That way the 2.21 msec are reduced to 912 usec, but the indentation is > an abomination. Just create a _pydecimal module (like _pyio). Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyCon US 2014
On 10 Oct 2013, at 01:53, Eric Snow wrote: > Registration is now open for PyCon US 2014. Are there any plans yet > for the language summit? Just the day (e.g. Thursday April 10) will > suffice. Then we can make arrangements appropriately. Thanks. Sorry for the late reply. Yes there will be a language summit. I'm pretty sure it will be on Thursday as the last few years. I'm getting definite confirmation of this. Michael > > -eric > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python IDEL issue
Hi, When I open IDLE(Python GUI) from the windows start menu, it always open Python Shell. When I right click on a *.py file, I cannot see the menu item "open with IDLE". Even after I uninstall and reinstall Python several times with different versions, the issue remains. I guess it is because something prerequisite is not installed on my computer. But do you know what is it? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C extension [PEP 399] import time
Antoine Pitrou wrote: > > > > I'm getting about the same values as above. I may be misunderstanding > > something, but I wanted to reduce the difference between the 2.21 msec > > and the 112 usec. > > So you aren't complaining about C extension import time, but Python > code import time, right? Right, that wasn't clear from the title. Somehow I thought that PEP 399 explicitly recommended importing the C extension at the end of the file, but in fact it only says "This [importing] is typically done at the end of the module". > Just create a _pydecimal module (like _pyio). Thanks, I'll try that. Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-10-04 - 2013-10-11) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4240 (-16) closed 26757 (+75) total 30997 (+59) Open issues with patches: 1960 Issues opened (37) == #18229: attribute headers of http.server.BaseHTTPRequestHandler someti http://bugs.python.org/issue18229 reopened by joru #18716: Deprecate the formatter module http://bugs.python.org/issue18716 reopened by brett.cannon #19167: sqlite3 cursor.description varies across Linux (3.3.1), Win32 http://bugs.python.org/issue19167 opened by mpb #19170: telnetlib: use selectors http://bugs.python.org/issue19170 opened by neologix #19172: selectors: add keys() method http://bugs.python.org/issue19172 opened by neologix #19173: Expose Queue maxsize parameter to multiprocessing.Pool class http://bugs.python.org/issue19173 opened by noxdafox #19175: Erroneous reference to "integer" in format string grammar http://bugs.python.org/issue19175 opened by davidchambers #19176: DeprecationWarning for doctype() method when subclassing _elem http://bugs.python.org/issue19176 opened by vadmium #19179: doc bug: confusing table of values http://bugs.python.org/issue19179 opened by georg.brandl #19180: some RFC references could be updated http://bugs.python.org/issue19180 opened by georg.brandl #19183: PEP 456 Secure and interchangeable hash algorithm http://bugs.python.org/issue19183 opened by christian.heimes #19184: dis module has incorrect docs for RAISE_VARARGS http://bugs.python.org/issue19184 opened by nedbat #19185: Allow multiprocessing Pool initializer to return values http://bugs.python.org/issue19185 opened by noxdafox #19186: expat symbols should be namespaced in pyexpat again http://bugs.python.org/issue19186 opened by athompson #19189: Improve cross-references in pickle documentation. http://bugs.python.org/issue19189 opened by serhiy.storchaka #19191: os.path.splitext in windows , a little question http://bugs.python.org/issue19191 opened by xiaowei.py #19192: Move test_current_time from test_xmlrpc_net to test_xmlrpc http://bugs.python.org/issue19192 opened by vajrasky #19197: Improve cross-references in shlex documentation http://bugs.python.org/issue19197 opened by serhiy.storchaka #19198: Improve cross-references in cgi documentation http://bugs.python.org/issue19198 opened by serhiy.storchaka #19201: lzma and 'x' mode open http://bugs.python.org/issue19201 opened by oylenshpeegul #19202: Additions to docs http://bugs.python.org/issue19202 opened by Esa.Peuha #19203: Improve cross-references in curses howto http://bugs.python.org/issue19203 opened by serhiy.storchaka #19204: Improve cross-references in urllib documentation http://bugs.python.org/issue19204 opened by serhiy.storchaka #19205: Don't import re and sysconfig in site.py http://bugs.python.org/issue19205 opened by christian.heimes #19206: Support disabling file I/O when doing traceback formatting http://bugs.python.org/issue19206 opened by itamarst #19207: Improve cross-references in os documentation http://bugs.python.org/issue19207 opened by serhiy.storchaka #19209: Remove import copyreg from os module http://bugs.python.org/issue19209 opened by christian.heimes #19213: platform.linux_distribution detects Oracle Linux as Red Hat En http://bugs.python.org/issue19213 opened by javawizard #19214: shutil.make_archive should recognize extensions in filenames http://bugs.python.org/issue19214 opened by andreas-h #19216: stat cache for import bootstrap http://bugs.python.org/issue19216 opened by christian.heimes #19217: Calling assertEquals for moderately long list takes too long http://bugs.python.org/issue19217 opened by Jacek.Bzdak #19218: Use of MutableMapping in os module slows down interpreter star http://bugs.python.org/issue19218 opened by eric.snow #19219: speed up marshal.loads() http://bugs.python.org/issue19219 opened by pitrou #19222: gzip and 'x' mode open http://bugs.python.org/issue19222 opened by oylenshpeegul #19223: bz2 and 'x' mode open http://bugs.python.org/issue19223 opened by oylenshpeegul #19224: Make hash(None) consistent among processes http://bugs.python.org/issue19224 opened by hongqn #19225: lack of PyExc_BufferError doc http://bugs.python.org/issue19225 opened by xwhhsprings Most recent 15 issues with no replies (15) == #19223: bz2 and 'x' mode open http://bugs.python.org/issue19223 #19222: gzip and 'x' mode open http://bugs.python.org/issue19222 #19214: shutil.make_archive should recognize extensions in filenames http://bugs.python.org/issue19214 #19207: Improve cross-references in os documentation http://bugs.python.org/issue19207 #19204: Improve cross-references in urllib documentation http://bugs.python.org/issue19204 #19203: Improve cross-references in
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Am 11.10.2013 11:43, schrieb Victor Stinner: > [We are discussing issue #15806.] > > 2013/10/11 Antoine Pitrou : >> I don't think that this contextlib.ignore() thing has been discussed a >> lot. > > If we decide to keep the feature, I would prefer a less generic name: > contextlib.ignore_excep() Srsly? :) Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Am 11.10.2013 16:47, schrieb Barry Warsaw: > On Oct 11, 2013, at 09:24 AM, Antoine Pitrou wrote: > >>I don't think that this contextlib.ignore() thing has been discussed a >>lot. >> >>Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my >>-1 too. This is a useless addition (the traditional idiom is perfectly >>obvious) and makes reading foreign code more tedious by adding >>superfluous API calls. >> >>Please consider reverting. There is absolutely zero use case for this >>that wasn't already solved by the traditional "except ...: pass" idiom. > > I'm +0; I think it's a nice little addition that could be useful, but I don't > care enough to wait for 3.4 to delete similar code in a my own programs. Same here. > To bikeshed though: why was `ignored` changed to `ignore`? The former reads > better to me, and I don't think *that* particular change was discussed at all > in the tracker afaict. Maybe to fit in with other verb-like APIs used as context managers: it's open() not opened(). Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: >Maybe to fit in with other verb-like APIs used as context managers: >it's open() not opened(). open() predates context managers, but maybe we need a new convention. with ignore(FileNotFoundError): vs with ignored(FileNotFoundError): To me anyway, the latter sounds better. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Fri, Oct 11, 2013 at 11:00 AM, Antoine Pitrou wrote: > > Let me answer here to Nick's argument on the tracker (made last year, > before the patch was committed): > > > As with many context managers, a key benefit here is in the priming > > effect for readers. In this code: > > > > try: > ># Whatever > > except (A, B, C): > >pass > > > > the reader doesn't know that (A, B, C) exceptions will be ignored > > until the end. The with statement form makes it clear before you > > start reading the code that certain exceptions won't propagate: > > > > with ignored(A, B, C): > > # Whatever > > The problem with this argument is that it assumes a very specific idiom: > i.e. writing long "try" blocks in the purpose of silencing exceptions. > > I'd like to make the following points: > > - when catching an exception, the common (and recommended) behaviour is > to do something else - not merely silencing it. Silencing is not very > common in my experience, except in badly written code > > - when catching an exception, it is recommended for the "try" block to > be as slim as possible - so that you don't catch other unintended > exceptions by mistake. This is a point I already made in PEP 3151. > Many exception classes (OSError, KeyError, RuntimeError...) are > polysemic. > > The bottom line is that there shouldn't be any long "try" blocks > followed by a single "except FooException: pass" clause in well-written > code. The presence of such an idiom is a strong code smell. > > Therefore contextlib.ignore() seems aimed at making it easier to write > bad code, not good code. I don't think it should exist in the stdlib. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > I'm with Antoine here. Despite "with ignore(OSError): os.remove" looks appealing to the eye I think many people will end up thinking it's fine to write long "ignore" blocks, because that's perfectly fine when using the "with" statement. Point is this is actually a "try" block disguised as a "with", and "try" blocks should usually be followed by very few indented lines (usually just 1) for a very good reason. -1 --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 12:43 PM, Barry Warsaw wrote: > On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: > >> Maybe to fit in with other verb-like APIs used as context managers: >> it's open() not opened(). > > open() predates context managers, but maybe we need a new convention. > > with ignore(FileNotFoundError): > > vs > > with ignored(FileNotFoundError): > > To me anyway, the latter sounds better. I'm still -0, and maybe now -1 on the idea, mostly because it encourages an anti-pattern. But, to continue to paint the shed, shouldn't it be "ignoring", to match "closing"? Eric. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 11, 2013, at 01:19 PM, Eric V. Smith wrote: >But, to continue to paint the shed, shouldn't it be "ignoring", to match >"closing"? Maybe so. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
11.10.13 10:24, Antoine Pitrou написав(ла): Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my -1 too. This is a useless addition (the traditional idiom is perfectly obvious) and makes reading foreign code more tedious by adding superfluous API calls. I am -1 too. But I want to hear more about interact with ExitStack (note that ExitStack itself is not widely used in the stdlib). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Fri, 11 Oct 2013 20:32:45 +0300, Serhiy Storchaka wrote: > 11.10.13 10:24, Antoine Pitrou напиÑав(ла): > > Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my > > -1 too. This is a useless addition (the traditional idiom is perfectly > > obvious) and makes reading foreign code more tedious by adding > > superfluous API calls. > > I am -1 too. But I want to hear more about interact with ExitStack (note > that ExitStack itself is not widely used in the stdlib). I'm inclined to be -1 as well, because of the anti-pattern encouragement. It seems at first blush like using it with ExitStack would make that tendency worse, so I too would like to hear more about Nick's thoughts on the subject. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 05:51 AM, Mark Lawrence wrote: On 11/10/2013 11:33, Eric V. Smith wrote: And Antoine has again taught me a new word: polysemic: having more than one meaning; having multiple meanings IMHO a poor word to use. I'm a middle aged Brit who's never heard of it so people who have English as a second language have little or no chance :( Even us natives can learn! Dictionaries just aren't hard to find any more. ;) -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
-1 to contextlib.ignore(s|d|ing|etc) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 11, 2013, at 08:32 PM, Serhiy Storchaka wrote: >I am -1 too. But I want to hear more about interact with ExitStack (note that >ExitStack itself is not widely used in the stdlib). Yet. :) -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 09:43 AM, Barry Warsaw wrote: On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: Maybe to fit in with other verb-like APIs used as context managers: it's open() not opened(). open() predates context managers, but maybe we need a new convention. with ignore(FileNotFoundError): vs with ignored(FileNotFoundError): To me anyway, the latter sounds better. The practice I follow is to use present tense, singular, unless there's a really good reason not to. Makes remembering a lot easier: was it ignore? ignoring? ignores? ignored? Answer: ignore. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Am 11.10.2013 19:24, schrieb Barry Warsaw: > On Oct 11, 2013, at 01:19 PM, Eric V. Smith wrote: > >>But, to continue to paint the shed, shouldn't it be "ignoring", to match >>"closing"? > > Maybe so. Would at least be consistent since both actions (close/ignore) are done at the end of the execution of the block... Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 10:19 AM, Eric V. Smith wrote: On 10/11/2013 12:43 PM, Barry Warsaw wrote: On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: Maybe to fit in with other verb-like APIs used as context managers: it's open() not opened(). open() predates context managers, but maybe we need a new convention. with ignore(FileNotFoundError): vs with ignored(FileNotFoundError): To me anyway, the latter sounds better. I'm still -0, and maybe now -1 on the idea, mostly because it encourages an anti-pattern. But, to continue to paint the shed, shouldn't it be "ignoring", to match "closing"? Seriously, "with" is the wrong spelling for this using. It should be while ignorning(FileNotFoundError) Insistence on using "with" for the anti-pattern, and proper English, would require: with ignorance_of(FileNotFoundError) :) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
11.10.13 21:41, Glenn Linderman написав(ла): Seriously, "with" is the wrong spelling for this using. It should be while ignorning(FileNotFoundError) We need extended bool for while condition: http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 11/10/2013 18:39, Ethan Furman wrote: On 10/11/2013 09:43 AM, Barry Warsaw wrote: On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: Maybe to fit in with other verb-like APIs used as context managers: it's open() not opened(). open() predates context managers, but maybe we need a new convention. with ignore(FileNotFoundError): vs with ignored(FileNotFoundError): To me anyway, the latter sounds better. The practice I follow is to use present tense, singular, unless there's a really good reason not to. Makes remembering a lot easier: was it ignore? ignoring? ignores? ignored? Answer: ignore. Singular would be "ignores". In this instance, "ignore" is imperative. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 11/10/2013 19:41, Glenn Linderman wrote: On 10/11/2013 10:19 AM, Eric V. Smith wrote: On 10/11/2013 12:43 PM, Barry Warsaw wrote: On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: Maybe to fit in with other verb-like APIs used as context managers: it's open() not opened(). open() predates context managers, but maybe we need a new convention. with ignore(FileNotFoundError): vs with ignored(FileNotFoundError): To me anyway, the latter sounds better. I'm still -0, and maybe now -1 on the idea, mostly because it encourages an anti-pattern. But, to continue to paint the shed, shouldn't it be "ignoring", to match "closing"? Seriously, "with" is the wrong spelling for this using. It should be while ignorning(FileNotFoundError) Insistence on using "with" for the anti-pattern, and proper English, would require: with ignorance_of(FileNotFoundError) :) "Ignorance" means not knowing, but we _do_ know about FileNotFoundError. What we want is to ignore it. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python IDEL issue
On 10/11/2013 3:37 AM, Hu, Hao (NSN - CN/Beijing) wrote: This list is for development *of* Python and CPython. Usage questions should be directed elsewhere, such as python-list. Idle questions can be directed to the idle-sig list. Both can be accessed through news.gmane.org as gmane.comp.python.general and .idle. When I open IDLE(Python GUI) from the windows start menu, All questions should include the python version. > it always open Python Shell. When I right click on a *.py file, I cannot see the menu item “open with IDLE”. I used to see that, but do not at present. Please continue the discussion on one of the two lists mentioned above. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Fri, 11 Oct 2013 20:01:07 +0100, MRAB wrote:
> On 11/10/2013 19:41, Glenn Linderman wrote:
> > On 10/11/2013 10:19 AM, Eric V. Smith wrote:
> >> On 10/11/2013 12:43 PM, Barry Warsaw wrote:
> >>> On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote:
> >>>
> Maybe to fit in with other verb-like APIs used as context managers:
> it's open() not opened().
> >>> open() predates context managers, but maybe we need a new convention.
> >>>
> >>> with ignore(FileNotFoundError):
> >>>
> >>> vs
> >>>
> >>> with ignored(FileNotFoundError):
> >>>
> >>> To me anyway, the latter sounds better.
> >> I'm still -0, and maybe now -1 on the idea, mostly because it encourages
> >> an anti-pattern.
> >>
> >> But, to continue to paint the shed, shouldn't it be "ignoring", to match
> >> "closing"?
> >
> > Seriously, "with" is the wrong spelling for this using. It should be
> >
> > while ignorning(FileNotFoundError)
> >
> > Insistence on using "with" for the anti-pattern, and proper English,
> > would require:
> >
> > with ignorance_of(FileNotFoundError)
> >
> > :)
> >
> "Ignorance" means not knowing, but we _do_ know about FileNotFoundError.
> What we want is to ignore it.
Isn't "ignore" in any form really a lie here, though? We are not
ignoring it, we are catching it and taking an early exit out of
the with block:
with ignore(FileNotFoundError):
with open('f') as f:
print("hello world")
print("goodbye world")
This does not print anything, whereas for either intuitive meaning
I can think of for "ignoring" the error, it ought to print something.
You really can't *ignore* errors inside a with block.
This incorrect intuition is exactly why this is an anti-pattern.
'ignore' is an attractive nuisance.
This having occurred to me, I am now definitely -1.
--David
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 8:04 AM, Serhiy Storchaka wrote: 11.10.13 13:33, Eric V. Smith написав(ла): And Antoine has again taught me a new word: polysemic: having more than one meaning; having multiple meanings There is no such word in my dictionaries. :( Only polysemous and polysemantic. http://www.merriam-webster.com/dictionary/polysemic Says polysemic is a variant of polysemous. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451: ModuleSpec
On Fri, Oct 4, 2013 at 11:18 PM, Eric Snow wrote: > After a few rounds on import-sig PEP 451 is really for general > consumption. I also have a patch up now. > > HTML: http://www.python.org/dev/peps/pep-0451/ > implementation: http://bugs.python.org/issue18864 > > Your comments would be appreciated. > > -eric > > = > > PEP: 451 > Title: A ModuleSpec Type for the Import System > Version: $Revision$ > Last-Modified: $Date$ > Author: Eric Snow > Discussions-To: [email protected] > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 8-Aug-2013 > Python-Version: 3.4 > Post-History: 8-Aug-2013, 28-Aug-2013, 18-Sep-2013, 24-Sep-2013 > Resolution: > > > Abstract > > > This PEP proposes to add a new class to importlib.machinery called > "ModuleSpec". It will provide all the import-related information used > to load a module and will be available without needing to load the > module first. Finders will directly provide a module's spec instead of > a loader (which they will continue to provide indirectly). The import > machinery will be adjusted to take advantage of module specs, including > using them to load modules. Any comments? Usually silence implies no disapproval. ;) PEP 451 did go through several rounds of review on import-sig, so I'm not going to stress over low feedback at this point. However, I'd particularly appreciate knowing if there are any objections to ModuleSpec for 3.4. Otherwise I'd like to get pronouncement on the PEP. Thanks! -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C extension import time
Antoine Pitrou wrote: > Just create a _pydecimal module (like _pyio). That's very fast indeed. There's one minor problem: For backwards compatibility and pickling [1] I'd need to add __module__ = 'decimal' to every class of the Python version. Are there any reasons not to do that? Stefan Krah [1] _decimal has always set the module name to 'decimal' because of that. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C extension import time
On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote: > Antoine Pitrou wrote: >> Just create a _pydecimal module (like _pyio). > > That's very fast indeed. There's one minor problem: For backwards > compatibility > and pickling [1] I'd need to add > > __module__ = 'decimal' > > to every class of the Python version. Are there any reasons not to do that? Try just putting "__name__ = 'decimal'" at the top of the source file. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C extension import time
2013/10/11 Antoine Pitrou : >> So the first step I tried is something horrible (typing from memory): >> >> try: >> import _decimal >> except ImportError: >> >> else: >> from _decimal import * >> >> That way the 2.21 msec are reduced to 912 usec, but the indentation is >> an abomination. > > Just create a _pydecimal module (like _pyio). +1 but both modules must be tested (as io and _pyio). Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs shouldn't be considered docs
On 10/11/2013 04:24 AM, Ned Batchelder wrote: I'd like to suggest that we not consider PEPs to be documentation. +1 The few times I've tried to use the PEPs to understand current Python it was confusing, wrong, and a waste of time. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 12:00 PM, MRAB wrote: On 11/10/2013 18:39, Ethan Furman wrote: On 10/11/2013 09:43 AM, Barry Warsaw wrote: On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: Maybe to fit in with other verb-like APIs used as context managers: it's open() not opened(). open() predates context managers, but maybe we need a new convention. with ignore(FileNotFoundError): vs with ignored(FileNotFoundError): To me anyway, the latter sounds better. The practice I follow is to use present tense, singular, unless there's a really good reason not to. Makes remembering a lot easier: was it ignore? ignoring? ignores? ignored? Answer: ignore. Singular would be "ignores". In this instance, "ignore" is imperative. Then let's go with imperative. ;) -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Fri, Oct 11, 2013 at 11:41 AM, Glenn Linderman wrote: > On 10/11/2013 10:19 AM, Eric V. Smith wrote: > > On 10/11/2013 12:43 PM, Barry Warsaw wrote: > > On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: > > > Maybe to fit in with other verb-like APIs used as context managers: > it's open() not opened(). > > open() predates context managers, but maybe we need a new convention. > > with ignore(FileNotFoundError): > > vs > > with ignored(FileNotFoundError): > > To me anyway, the latter sounds better. > > I'm still -0, and maybe now -1 on the idea, mostly because it encourages > an anti-pattern. > > But, to continue to paint the shed, shouldn't it be "ignoring", to match > "closing"? > > > Seriously, "with" is the wrong spelling for this using. It should be > > while ignorning(FileNotFoundError) > > Insistence on using "with" for the anti-pattern, and proper English, would > require: > > with ignorance_of(FileNotFoundError) > I was thinking more along the lines of: with no_chance_in_hell_of_seeing(FileNotFoundError): but seriously, we have plenty of antipattern enablers in the language and standard library itself. contextlib.ignore vs ignored vs all of these others isn't a big deal to me. Just document it as not recommended for most things and let people shoot themselves if they've used "with contextlib.ignored(Documentation):" while writing code. I don't care what it is called and I think it is fine to have in contextlib. I'm unlikely to use it anytime soon as I don't have a 3.4+ only code base. Though suspect I could re-factor code to this in a few places within 3.4's Lib/subprocess.py. -gps ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
: On Fri, Oct 11, 2013 at 08:01:07PM +0100, MRAB wrote: > On 11/10/2013 19:41, Glenn Linderman wrote: > >Insistence on using "with" for the anti-pattern, and proper English, > >would require: > > > >with ignorance_of(FileNotFoundError) > > > "Ignorance" means not knowing, but we _do_ know about FileNotFoundError. > What we want is to ignore it. Suggestions: with disregard_for(...): with indifference_to(...): with nonchalance_regarding(...): with blithe_disdain_concerning(...): -[]z. -- Zero Piraeus: dictatum erat http://etiol.net/pubkey.asc ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Fri, 11 Oct 2013 16:09:56 -0300, Zero Piraeus wrote: > : > > On Fri, Oct 11, 2013 at 08:01:07PM +0100, MRAB wrote: > > On 11/10/2013 19:41, Glenn Linderman wrote: > > >Insistence on using "with" for the anti-pattern, and proper English, > > >would require: > > > > > >with ignorance_of(FileNotFoundError) > > > > > "Ignorance" means not knowing, but we _do_ know about FileNotFoundError. > > What we want is to ignore it. > > Suggestions: > > with disregard_for(...): > > with indifference_to(...): > > with nonchalance_regarding(...): > > with blithe_disdain_concerning(...): with an_immediate_exit_from_the_with_if_we_see(...): --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Thanks everybody (was Summary of Python tracker Issues)
On 11/10/2013 17:07, Python tracker wrote: ACTIVITY SUMMARY (2013-10-04 - 2013-10-11) Python tracker at http://bugs.python.org/ Issues counts and deltas: open4240 (-16) closed 26757 (+75) total 30997 (+59) Looking at the figures above I'd just like to say thank you to everybody involved for the work that has been put in. I for one certainly appreciate your efforts. -- Roses are red, Violets are blue, Most poems rhyme, But this one doesn't. Mark Lawrence ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 12 Oct 2013 03:58, "R. David Murray" wrote: > > On Fri, 11 Oct 2013 20:32:45 +0300, Serhiy Storchaka wrote: > > 11.10.13 10:24, Antoine Pitrou написав(ла): > > > Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my > > > -1 too. This is a useless addition (the traditional idiom is perfectly > > > obvious) and makes reading foreign code more tedious by adding > > > superfluous API calls. > > > > I am -1 too. But I want to hear more about interact with ExitStack (note > > that ExitStack itself is not widely used in the stdlib). > > I'm inclined to be -1 as well, because of the anti-pattern > encouragement. It seems at first blush like using it with ExitStack > would make that tendency worse, so I too would like to hear more about > Nick's thoughts on the subject. In conjunction with ExitStack itself, I see it as a building block for dynamic exception handling, decoupled from the syntactic layout of code. I also see reducing a four line idiom to a two line one that is easier to grep for as a benefit, as well as providing another place in the docs to nudge people towards improved exception handling practices (even if we didn't take advantage of that opportunity in the original patch). For example, a counterpart in logging that *logged* suppressed exceptions rather than ignoring them completely would be a good resource to point to, while being more discoverable than just offering the manager in logging (such a manager would *also* mix nicely with ExitStack). I'm not too fussy about the name (clearly). We originally picked ignored(), Raymond asked if he could change it to ignore() (and I said yes), and there's a valid argument to be made that closing() sets the precedent that it should be ignoring(). (RDM is also right that the exception still has the effect of terminating the block early, but I view names as mnemonics rather than necessarily 100% accurate descriptions of things). Cheers, Nick. > > --David > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C extension import time
On 12 Oct 2013 05:49, "Eric Snow" wrote: > > On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote: > > Antoine Pitrou wrote: > >> Just create a _pydecimal module (like _pyio). > > > > That's very fast indeed. There's one minor problem: For backwards compatibility > > and pickling [1] I'd need to add > > > > __module__ = 'decimal' > > > > to every class of the Python version. Are there any reasons not to do that? > > Try just putting "__name__ = 'decimal'" at the top of the source file. In this case the fixup needs to be conditional on the absence of "_decimal". Aside from that, yes, lying about name is the easiest way to preserve pickle compatibility while still moving code around. Cheers, Nick. > > -eric > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Support keyword in PEP URL?
Hi,
What do you think of adding an optional identifier to a PEP to get a
readable URL?
Example:
http://www.python.org/dev/peps/qualname/
instead of
http://www.python.org/dev/peps/pep-0395/
Other examples:
305: csv
450: statistics
3156: asyncio
An identifier must only contain lower case letters (a-z), digits
(0-9), dot (.) and underscore (_). It should be short (max. 20
characters)... and unique. Regex: ^[a-z0-9._]{1,20}$.
For draft PEP, the identifier may change. If it's an issue (dead URL),
we may allow multiple identifiers (ex: add also "tulip" for 3156), or
only add an identifier to accepted PEPs.
I don't know yet how it can be implemented at server side.
Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
What's the use case? I just use Google search if I don't recall the PEP
number.
On Fri, Oct 11, 2013 at 4:13 PM, Victor Stinner wrote:
> Hi,
>
> What do you think of adding an optional identifier to a PEP to get a
> readable URL?
>
> Example:
>http://www.python.org/dev/peps/qualname/
> instead of
>http://www.python.org/dev/peps/pep-0395/
>
> Other examples:
>
> 305: csv
> 450: statistics
> 3156: asyncio
>
> An identifier must only contain lower case letters (a-z), digits
> (0-9), dot (.) and underscore (_). It should be short (max. 20
> characters)... and unique. Regex: ^[a-z0-9._]{1,20}$.
>
> For draft PEP, the identifier may change. If it's an issue (dead URL),
> we may allow multiple identifiers (ex: add also "tulip" for 3156), or
> only add an identifier to accepted PEPs.
>
> I don't know yet how it can be implemented at server side.
>
> Victor
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On 12/10/2013 00:13, Victor Stinner wrote:
Hi,
What do you think of adding an optional identifier to a PEP to get a
readable URL?
Example:
http://www.python.org/dev/peps/qualname/
instead of
http://www.python.org/dev/peps/pep-0395/
Other examples:
305: csv
450: statistics
3156: asyncio
An identifier must only contain lower case letters (a-z), digits
(0-9), dot (.) and underscore (_). It should be short (max. 20
characters)... and unique. Regex: ^[a-z0-9._]{1,20}$.
For draft PEP, the identifier may change. If it's an issue (dead URL),
we may allow multiple identifiers (ex: add also "tulip" for 3156), or
only add an identifier to accepted PEPs.
I don't know yet how it can be implemented at server side.
Victor
If it's easy to do why not? If it's difficult why bother, I find it
easy enough to find stuff by searching directly on the PEP index?
--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.
Mark Lawrence
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs shouldn't be considered docs
On 11 Oct 2013 21:25, "Ned Batchelder" wrote: > > I wanted to teach a co-worker about "from __future__ import absolute_import" today, so I thought I'd point them at the docs. The page for "__future__" starts with a bunch of internal details that almost no one needs to know. There's a table at the end that mentions the actual importable names, including "absolute_import", but says nothing about then except to link to a PEP. > > The absolute imports PEP has no simple description of what it does. Like many PEPs, it's mostly a summary of the debate around the design of the feature. The closest the PEP comes to describing the behavior of "absolute_import" is this parenthetical: >> >> For the second problem, it is proposed that all import statements be absolute by default (searching sys.path only) with special syntax (leading dots) for accessing package-relative imports. > > And notice: that sentence describes it as a "proposal." > > I'd like to suggest that we not consider PEPs to be documentation. If a PEP has a good succinct description of how something works, then let's copy that text into the documentation at an appropriate place. If a PEP doesn't have such a description, then all the more reason not to send readers there. > > A link to the PEP is appropriate as a "see also" in the docs, but we shouldn't pretend that a PEP addresses the needs of people new to the feature. Aside from PEPs that describe development practices and versioned interoperability standards, this is already the case. The only major deviation from this practice was the import system, and that was because it was such an incoherent organically grown mess in CPython prior to the importlib migration in Python 3.3 that nobody was prepared to take on the task of writing the reference docs. Providing the missing reference docs for the import system was one of the conditions placed on the introduction of namespace packages in PEP 420. There's no grand policy change or clarification needed here, it's just another consequence of the fact that the import system isn't documented properly in versions prior to 3.3. Cheers, Nick. > --Ned. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19209: Remove import of copyreg from the os module to speed up
On 12 Oct 2013 09:27, "christian.heimes" wrote:
>
> http://hg.python.org/cpython/rev/29c4a6a11e76
> changeset: 86216:29c4a6a11e76
> user:Christian Heimes
> date:Sat Oct 12 01:27:08 2013 +0200
> summary:
> Issue #19209: Remove import of copyreg from the os module to speed up
> interpreter startup. stat_result and statvfs_result are now hard-coded to
> reside in the os module.
> The patch is based on Victor Stinner's patch.
>
> files:
> Lib/os.py | 27 ---
> Lib/test/test_os.py | 22 ++
> Lib/test/test_site.py | 5 -
> Misc/NEWS | 4
> Modules/posixmodule.c | 4 ++--
> 5 files changed, 32 insertions(+), 30 deletions(-)
>
>
> diff --git a/Lib/os.py b/Lib/os.py
> --- a/Lib/os.py
> +++ b/Lib/os.py
> @@ -945,33 +945,6 @@
> __all__.extend(["spawnlp", "spawnlpe"])
>
>
> -import copyreg as _copyreg
> -
> -def _make_stat_result(tup, dict):
> -return stat_result(tup, dict)
> -
> -def _pickle_stat_result(sr):
> -(type, args) = sr.__reduce__()
> -return (_make_stat_result, args)
> -
> -try:
> -_copyreg.pickle(stat_result, _pickle_stat_result, _make_stat_result)
> -except NameError: # stat_result may not exist
> -pass
> -
> -def _make_statvfs_result(tup, dict):
> -return statvfs_result(tup, dict)
> -
> -def _pickle_statvfs_result(sr):
> -(type, args) = sr.__reduce__()
> -return (_make_statvfs_result, args)
> -
> -try:
> -_copyreg.pickle(statvfs_result, _pickle_statvfs_result,
> - _make_statvfs_result)
> -except NameError: # statvfs_result may not exist
> -pass
> -
> # Supply os.popen()
> def popen(cmd, mode="r", buffering=-1):
> if not isinstance(cmd, str):
> diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py
> --- a/Lib/test/test_os.py
> +++ b/Lib/test/test_os.py
> @@ -26,6 +26,7 @@
> import codecs
> import decimal
> import fractions
> +import pickle
> try:
> import threading
> except ImportError:
> @@ -264,6 +265,13 @@
> warnings.simplefilter("ignore", DeprecationWarning)
> self.check_stat_attributes(fname)
>
> +def test_stat_result_pickle(self):
> +result = os.stat(self.fname)
> +p = pickle.dumps(result)
> +self.assertIn(b'\x03cos\nstat_result\n', p)
> +unpickled = pickle.loads(p)
> +self.assertEqual(result, unpickled)
> +
> def test_statvfs_attributes(self):
> if not hasattr(os, "statvfs"):
> return
> @@ -310,6 +318,20 @@
> except TypeError:
> pass
>
> [email protected](hasattr(os, 'statvfs'),
> + "need os.statvfs()")
> +def test_statvfs_result_pickle(self):
> +try:
> +result = os.statvfs(self.fname)
> +except OSError as e:
> +# On AtheOS, glibc always returns ENOSYS
> +if e.errno == errno.ENOSYS:
> +return
> +p = pickle.dumps(result)
> +self.assertIn(b'\x03cos\nstatvfs_result\n', p)
> +unpickled = pickle.loads(p)
> +self.assertEqual(result, unpickled)
> +
> def test_utime_dir(self):
> delta = 100
> st = os.stat(support.TESTFN)
> diff --git a/Lib/test/test_site.py b/Lib/test/test_site.py
> --- a/Lib/test/test_site.py
> +++ b/Lib/test/test_site.py
> @@ -431,10 +431,13 @@
> modules = eval(stdout.decode('utf-8'))
> self.assertIn('site', modules)
>
> +# http://bugs.python.org/issue19205
> re_mods = {'re', '_sre', 'sre_compile', 'sre_constants',
'sre_parse'}
> self.assertFalse(modules.intersection(re_mods))
> -
> +# http://bugs.python.org/issue9548
> self.assertNotIn('locale', modules)
This looks like it snuck in from a separate patch.
Cheers,
Nick.
> +# http://bugs.python.org/issue19209
> +self.assertNotIn('copyreg', modules)
>
>
> if __name__ == "__main__":
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -36,6 +36,10 @@
> Library
> ---
>
> +- Issue #19209: Remove import of copyreg from the os module to speed up
> + interpreter startup. stat_result and statvfs_result are now hard-coded
to
> + reside in the os module.
> +
> - Issue #19205: Don't import the 're' module in site and sysconfig
module to
>to speed up interpreter start.
>
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -11974,7 +11974,7 @@
> return NULL;
> #endif
>
> -stat_result_desc.name = MODNAME ".stat_result";
> +stat_result_desc.name = "os.stat_result"; /* see issue #19209 */
> stat_result_desc.fields[7].name = PyStructSequence_UnnamedField;
> stat_result_desc.fields[8].name = PyStructSequence_UnnamedField;
> stat_result_desc.fields[9].name = PyStructSequence_UnnamedField;
> @@ -11983,7 +11983,7 @@
> structseq_new =
Re: [Python-Dev] Support keyword in PEP URL?
Victor Stinner writes: > For draft PEP, the identifier may change. For an idea implemented in several PEPs, the obvious identifier may be taken first, but the preferred PEP for that identifier may later change. For example, PEP 354 would have the obvious keyword “enum” when it was being discussed. Then it was rejected. Later, PEP 435 was introduced, and accepted. It is now even *more* deserving of the keyword “enum” than the earlier PEP. What do you propose in cases like this? Should the keyword always refer to the same PEP it did in the past, even when that PEP is no longer as relevant given later PEPs? Or should the keyword reach a different, newer PEP if that newer PEP becomes a “more relevant” PEP for the keyword? -- \“There are only two ways to live your life. One is as though | `\ nothing is a miracle. The other is as if everything is.” | _o__) —Albert Einstein | Ben Finney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On 12 Oct 2013 09:32, "Mark Lawrence" wrote:
>
> On 12/10/2013 00:13, Victor Stinner wrote:
>>
>> Hi,
>>
>> What do you think of adding an optional identifier to a PEP to get a
>> readable URL?
>>
>> Example:
>> http://www.python.org/dev/peps/qualname/
>> instead of
>> http://www.python.org/dev/peps/pep-0395/
>>
>> Other examples:
>>
>> 305: csv
>> 450: statistics
>> 3156: asyncio
>>
>> An identifier must only contain lower case letters (a-z), digits
>> (0-9), dot (.) and underscore (_). It should be short (max. 20
>> characters)... and unique. Regex: ^[a-z0-9._]{1,20}$.
>>
>> For draft PEP, the identifier may change. If it's an issue (dead URL),
>> we may allow multiple identifiers (ex: add also "tulip" for 3156), or
>> only add an identifier to accepted PEPs.
>>
>> I don't know yet how it can be implemented at server side.
>>
>> Victor
>>
>
> If it's easy to do why not?
> If it's difficult why bother, I find it easy enough to find stuff by
searching directly on the PEP index?
Agreed, doesn't seem worth the hassle to me.
Cheers,
Nick.
>
> --
> Roses are red,
> Violets are blue,
> Most poems rhyme,
> But this one doesn't.
>
> Mark Lawrence
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19209: fix structseq test
On 12 Oct 2013 09:42, "christian.heimes" wrote:
>
> http://hg.python.org/cpython/rev/89e405e6a7a9
> changeset: 86218:89e405e6a7a9
> parent: 86216:29c4a6a11e76
> user:Christian Heimes
> date:Sat Oct 12 01:38:52 2013 +0200
> summary:
> Issue #19209: fix structseq test
>
> files:
> Lib/test/test_structseq.py | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Lib/test/test_structseq.py b/Lib/test/test_structseq.py
> --- a/Lib/test/test_structseq.py
> +++ b/Lib/test/test_structseq.py
> @@ -38,7 +38,7 @@
> # os.stat() gives a complicated struct sequence.
> st = os.stat(__file__)
> rep = repr(st)
> -self.assertTrue(rep.startswith(os.name + ".stat_result"))
> +self.assertTrue(rep.startswith("os.stat_result"))
If stat results can be pickled, this suggests a possible issue with
unpickling pickles generated with older versions of Python.
Cheers,
Nick.
> self.assertIn("st_mode=", rep)
> self.assertIn("st_ino=", rep)
> self.assertIn("st_dev=", rep)
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-checkins
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 12, 2013, at 09:06 AM, Nick Coghlan wrote: >I'm not too fussy about the name (clearly). We originally picked ignored(), >Raymond asked if he could change it to ignore() (and I said yes), Just as a point of order, it would be good to capture such side-channel discussions in the relevant issue. Mysterious decisions like this are easy to miss in the deluge of checkin messages, and don't help promote a transparent development process. Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
2013/10/12 Guido van Rossum : > What's the use case? I just use Google search if I don't recall the PEP > number. The final goal would be to identify PEPs using a textual identifier instead of a number identifier. We now have 206 PEPs (341 if you count also deferred and rejected PEPs). It's not easy to remember all these PEP numbers. Google should not needed to find a PEP, it's identifier should be enough to write manually the URL. The problem is to remember the numerical identifier. It's easy to mix up PEP numbers. For example, Martin von Loewis wrote two major PEP related to Unicode: 383 and 393. These numbers are close, only one digit is different. It's worse when you discuss recent PEPs: PEP 445 or PEP 454? Oops, no it was the PEP 455. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On 10/11/2013 04:35 PM, Ben Finney wrote: Victor Stinner writes: For draft PEP, the identifier may change. For an idea implemented in several PEPs, the obvious identifier may be taken first, but the preferred PEP for that identifier may later change. For example, PEP 354 would have the obvious keyword “enum” when it was being discussed. Then it was rejected. Later, PEP 435 was introduced, and accepted. It is now even *more* deserving of the keyword “enum” than the earlier PEP. What do you propose in cases like this? Should the keyword always refer to the same PEP it did in the past, even when that PEP is no longer as relevant given later PEPs? Or should the keyword reach a different, newer PEP if that newer PEP becomes a “more relevant” PEP for the keyword? Heh, that was the same example I was going to use. :) Another question: if the later PEP gets the appropriate name, what name then gets applied to the older one(s)? For than matter, what names would you give to the myriad unicode peps? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
Hm. I think at that scale giving every PEP a unique name and remembering those names is just as hard. And the issue with different versions or variants of the same idea is real. I think it's not worth the effort. On Fri, Oct 11, 2013 at 5:53 PM, Victor Stinner wrote: > 2013/10/12 Guido van Rossum : > > What's the use case? I just use Google search if I don't recall the PEP > > number. > > The final goal would be to identify PEPs using a textual identifier > instead of a number identifier. > > We now have 206 PEPs (341 if you count also deferred and rejected > PEPs). It's not easy to remember all these PEP numbers. Google should > not needed to find a PEP, it's identifier should be enough to write > manually the URL. The problem is to remember the numerical identifier. > > It's easy to mix up PEP numbers. For example, Martin von Loewis wrote > two major PEP related to Unicode: 383 and 393. These numbers are > close, only one digit is different. It's worse when you discuss recent > PEPs: PEP 445 or PEP 454? Oops, no it was the PEP 455. > > Victor > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
2013/10/12 Ben Finney : > Victor Stinner writes: > >> For draft PEP, the identifier may change. > > For an idea implemented in several PEPs, the obvious identifier may be > taken first, but the preferred PEP for that identifier may later change. > > For example, PEP 354 would have the obvious keyword “enum” when it was > being discussed. Then it was rejected. > > Later, PEP 435 was introduced, and accepted. It is now even *more* > deserving of the keyword “enum” than the earlier PEP. > > What do you propose in cases like this? Should the keyword always refer > to the same PEP it did in the past, even when that PEP is no longer as > relevant given later PEPs? Or should the keyword reach a different, > newer PEP if that newer PEP becomes a “more relevant” PEP for the > keyword? I would not be shocked if http://www.python.org/dev/peps/pep-enum/ link is updated from the PEP 354 to the PEP 435, especially if both PEPs are draft. Identifiers should be carefully chosen, "unicode" is maybe not the best identifier for a PEP for example (they are many PEPs related to Unicode). Hum, how are PEP numbers generated? PEP *354* and *435* for enum? These numbers are not very random. We should check our PRNG :-) Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
2013/10/12 Ethan Furman : >> What do you propose in cases like this? Should the keyword always refer >> to the same PEP it did in the past, even when that PEP is no longer as >> relevant given later PEPs? Or should the keyword reach a different, >> newer PEP if that newer PEP becomes a “more relevant” PEP for the >> keyword? > > Heh, that was the same example I was going to use. :) > > Another question: if the later PEP gets the appropriate name, what name > then gets applied to the older one(s)? As I wrote in my first message, if changing identifier for draft PEP is an issue, an option is to only add a textual identifier to accepted PEPs. > For than matter, what names would you give to the myriad unicode peps? Let me try to name PEPs related to Unicode: 100: unicode_integration 261: unicode_ucs4 277: windows_unicode_filenames (hum, I proposed a limit of 20 characters, this name is 25 characters long) 383: surrogateescape 393: compact_unicode 414: u_prefix_py33 These names are just propositions. They should be discussed :-) (they are probably much more PEPs related to Unicode :-)) Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On Oct 11, 2013, at 9:13 PM, Victor Stinner wrote: > 2013/10/12 Ethan Furman : >>> What do you propose in cases like this? Should the keyword always refer >>> to the same PEP it did in the past, even when that PEP is no longer as >>> relevant given later PEPs? Or should the keyword reach a different, >>> newer PEP if that newer PEP becomes a “more relevant” PEP for the >>> keyword? >> >> Heh, that was the same example I was going to use. :) >> >> Another question: if the later PEP gets the appropriate name, what name >> then gets applied to the older one(s)? > > As I wrote in my first message, if changing identifier for draft PEP > is an issue, an option is to only add a textual identifier to accepted > PEPs. > >> For than matter, what names would you give to the myriad unicode peps? > > Let me try to name PEPs related to Unicode: > > 100: unicode_integration > 261: unicode_ucs4 > 277: windows_unicode_filenames (hum, I proposed a limit of 20 > characters, this name is 25 characters long) > 383: surrogateescape > 393: compact_unicode > 414: u_prefix_py33 > > These names are just propositions. They should be discussed :-) Perhaps we can have a PEP to decide the name of a PEP! > > (they are probably much more PEPs related to Unicode :-)) > > Victor > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19209: fix structseq test
2013/10/12 Nick Coghlan :
>> summary:
>> Issue #19209: fix structseq test
>>
>> diff --git a/Lib/test/test_structseq.py b/Lib/test/test_structseq.py
>> --- a/Lib/test/test_structseq.py
>> +++ b/Lib/test/test_structseq.py
>> @@ -38,7 +38,7 @@
>> # os.stat() gives a complicated struct sequence.
>> st = os.stat(__file__)
>> rep = repr(st)
>> -self.assertTrue(rep.startswith(os.name + ".stat_result"))
>> +self.assertTrue(rep.startswith("os.stat_result"))
>
> If stat results can be pickled, this suggests a possible issue with
> unpickling pickles generated with older versions of Python.
This change should not break the backward compatibility. The os module
was using a copyreg "hack" (is it the good name?) to replace "posix"
with "os" when a os.stat or os.statvfs object was serialized with
pickle. See the issue for information.
Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On 10/11/2013 06:13 PM, Victor Stinner wrote: Let me try to name PEPs related to Unicode: 100: unicode_integration 261: unicode_ucs4 277: windows_unicode_filenames (hum, I proposed a limit of 20 characters, this name is 25 characters long) 383: surrogateescape 393: compact_unicode 414: u_prefix_py33 These names are just propositions. They should be discussed :-) Yeah, I will still be using google to get the one I want. ;) -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker/irc and development transparency (was: cpython: Rename contextlib.ignored ...)
On Fri, 11 Oct 2013 20:20:28 -0400, Barry Warsaw wrote: > On Oct 12, 2013, at 09:06 AM, Nick Coghlan wrote: > > >I'm not too fussy about the name (clearly). We originally picked ignored(), > >Raymond asked if he could change it to ignore() (and I said yes), > > Just as a point of order, it would be good to capture such side-channel > discussions in the relevant issue. Mysterious decisions like this are easy to > miss in the deluge of checkin messages, and don't help promote a transparent > development process. +10. Those of us who regularly hang out and discuss things on irc[*] try to be good about updating the issue with "xxx was discussed on IRC and...". This is critical, because even the sometimes lengthly checkin messages I write carry nowhere near as much information as can be found by visiting the issue number mentioned in the checkin header. (I note that the issue number was also missing from this particular commit message.) As the community referring to this stuff grows (and it has to, given that use of the language is still growing) and the history of the project becomes ever deeper, this kind of documentation becomes more and more important. --David [*] We will often be carrying on a sort of dual conversation: quick sentences on IRC interleaved with longer back-and-forth posts on the tracker, both part of the same ongoing conversation... ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Nick Coghlan writes: > (RDM is also right that the exception still has the effect of > terminating the block early, but I view names as mnemonics rather > than necessarily 100% accurate descriptions of things). This is just way too ambiguous for my taste. I can't help reading with contextlib.ignore(ExceptionIDontFeelLikeHandlingProperly): stmt1 stmt2 stmt3 as try: stmt1 except ExceptionIDontFeelLikeHandlingProperly: pass try: stmt2 except ExceptionIDontFeelLikeHandlingProperly: pass try: stmt3 except ExceptionIDontFeelLikeHandlingProperly: pass rather than try: stmt1 stmt2 stmt3 except ExceptionIDontFeelLikeHandlingProperly: pass It just feels like the exception should be suppressed at some level "lower" than stmtN, so stmtN fails but the suite continues. How about with contextlib.break_on(ExceptionIDontFeelLikeHandlingProperly): stmt1 stmt2 stmt3 This is not 100% accurate Pythonically (there's no loop to break here), but it does describe what the context manager does more accurately, and it does effectively break out of the 'with' control structure. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
Victor Stinner writes: Quoting someone else: >> For that matter, what names would you give to the myriad unicode >> peps? For what value of "you"? ISTM that's important. > Let me try to name PEPs related to Unicode: Of the ones you suggest, the only one that rings bells for me is "surrogateescape". If it's not mnemonic *to me*, it's not useful *to me*. (I.e., if python-dev can reach a workable consensus on nicknames, it doesn't really matter what I think. But if -- as I suspect -- many people will have different opinions about good nicknames for some PEPs, there won't be such a consensus.) Of the several hundred (and rapidly growing) PEPs, I only ever care about a dozen at a time (and some of those are fixed for all time: PEP 0, PEP 1, PEP 8). I have my own private nicknames for those PEPs. (Oddly enough, PEP 0, PEP 1, and PEP 8 are "pep0", "pep1", and "pep8". ;-) I think that more generally useful would be a PyPI package that grabs the PEP 0 list, parses it into a database, and adds a "nickname" column, plus a UI that allows assigning a personal nick to a PEP, lookup with fuzzy matching on nicks, and optionally sending the URL to the preferred browser. Sharing nicks and keywords (or tags, see below) would be a nice feature, too. N.B. "Keyword" isn't the right term for what you want. I think "nickname" is better. E.g., "unicode" is a fine keyword, but it applies to many PEPs, even if restricted to only those PEPs that directly affect the Unicode implementation. An URL like http://www.python.org/peps/by-keyword/unicode should return a list of all of them IMHO. I think of "keywords" as tags that are formally assigned by the project, "tags" as an informal social networking device. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On 12 Oct 2013 11:15, "Victor Stinner" wrote: > > 2013/10/12 Ethan Furman : > >> What do you propose in cases like this? Should the keyword always refer > >> to the same PEP it did in the past, even when that PEP is no longer as > >> relevant given later PEPs? Or should the keyword reach a different, > >> newer PEP if that newer PEP becomes a “more relevant” PEP for the > >> keyword? > > > > Heh, that was the same example I was going to use. :) > > > > Another question: if the later PEP gets the appropriate name, what name > > then gets applied to the older one(s)? > > As I wrote in my first message, if changing identifier for draft PEP > is an issue, an option is to only add a textual identifier to accepted > PEPs. RFCs are referenced by number. Standards are referenced by number. Nicknames are simply too ambiguous to be scalable. If you want a self explanatory reference, use the full PEP title, as that's what it is for (RFCs and standards also have titles for the same reason). Adopting a suitable set of keywords (like unicode, import, builtins, syntax, stdlib, cpython) could be interesting, though. Cheers, Nick. > > > For than matter, what names would you give to the myriad unicode peps? > > Let me try to name PEPs related to Unicode: > > 100: unicode_integration > 261: unicode_ucs4 > 277: windows_unicode_filenames (hum, I proposed a limit of 20 > characters, this name is 25 characters long) > 383: surrogateescape > 393: compact_unicode > 414: u_prefix_py33 > > These names are just propositions. They should be discussed :-) > > (they are probably much more PEPs related to Unicode :-)) > > Victor > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On Fri, Oct 11, 2013 at 10:04 PM, Nick Coghlan wrote: > Adopting a suitable set of keywords (like unicode, import, builtins, syntax, > stdlib, cpython) could be interesting, though. A couple years ago I started a page on the wiki for a topical listing of the PEPS [1]. I even brought up having a topical listing in PEP 0 [2]. However, there was some but not enough interest and I didn't have enough time to do much about it. :( -eric [1] https://wiki.python.org/moin/Topically%20Organized%20PEP%20List [2] (private list) https://mail.python.org/mailman/private/core-mentorship/2011-April/000252.html ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 07:47 PM, Stephen J. Turnbull wrote: Nick Coghlan writes: > (RDM is also right that the exception still has the effect of > terminating the block early, but I view names as mnemonics rather > than necessarily 100% accurate descriptions of things). This is just way too ambiguous for my taste. I can't help reading [snippers] How about with contextlib.break_on(ExceptionIDontFeelLikeHandlingProperly): stmt1 stmt2 stmt3 This is not 100% accurate Pythonically (there's no loop to break here), but it does describe what the context manager does more accurately, and it does effectively break out of the 'with' control structure. +1 (if we have to have it) While I agree that mnemonics are helpful in the right circumstances, these aren't them, not for this name. We aren't /just/ ignoring the exception, the exception is having a very real effect -- it's terminating the with block. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
Victor Stinner writes: > 2013/10/12 Ben Finney : > > Victor Stinner writes: > > > >> For draft PEP, the identifier may change. Note that this isn't a matter of the PEP being draft; once a PEP has a number, it deserves an official URL and (if I understand you correctly) a keyword. Then, *after* those official designations are associated with that PEP, another PEP can come along and be a better candidate for the same keyword. What use is a unique keyword-to-PEP mapping if it's not leading to the PEP most clearly associated with that keyword? > I would not be shocked if http://www.python.org/dev/peps/pep-enum/ > link is updated from the PEP 354 to the PEP 435, especially if both > PEPs are draft. On the other hand, what use is a keyword-to-PEP mapping if it isn't reliably going to persist over time? > Identifiers should be carefully chosen, "unicode" is maybe not the > best identifier for a PEP for example (they are many PEPs related to > Unicode). Right. I don't think it makes sense to have a keyword limited to exactly one PEP. > Hum, how are PEP numbers generated? PEP *354* and *435* for enum? > These numbers are not very random. We should check our PRNG :-) They're not random; they're sequential for the most part, IIUC. -- \“The restriction of knowledge to an elite group destroys the | `\ spirit of society and leads to its intellectual | _o__)impoverishment.” —Albert Einstein | Ben Finney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
