Re: [Python-Dev] Right place for PBKDF2 wrapper
13.10.13 13:39, Christian Heimes написав(ла): Am 13.10.2013 08:32, schrieb Nick Coghlan: +1 to hashlib from me (especially since we used that as the best available home for compare_digest). I'm afraid your memory doesn't serve you well. :( compare_digest is implemented in _operator.c. Its official home is hmac.compare_digest. Could we move compare_digest() out of _operator.c? It makes Python implementation of the operator module incomplete. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Right place for PBKDF2 wrapper
Le Mon, 14 Oct 2013 12:47:03 +0300, Serhiy Storchaka a écrit : > 13.10.13 13:39, Christian Heimes написав(ла): > > Am 13.10.2013 08:32, schrieb Nick Coghlan: > >> +1 to hashlib from me (especially since we used that as the best > >> available home for compare_digest). > > > > I'm afraid your memory doesn't serve you well. :( > > compare_digest is implemented in _operator.c. Its official home is > > hmac.compare_digest. > > Could we move compare_digest() out of _operator.c? It makes Python > implementation of the operator module incomplete. Or we could simply write a reference Python implementation :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Right place for PBKDF2 wrapper
14.10.13 13:07, Antoine Pitrou написав(ла): Le Mon, 14 Oct 2013 12:47:03 +0300, Serhiy Storchaka a écrit : 13.10.13 13:39, Christian Heimes написав(ла): Am 13.10.2013 08:32, schrieb Nick Coghlan: +1 to hashlib from me (especially since we used that as the best available home for compare_digest). I'm afraid your memory doesn't serve you well. :( compare_digest is implemented in _operator.c. Its official home is hmac.compare_digest. Could we move compare_digest() out of _operator.c? It makes Python implementation of the operator module incomplete. Or we could simply write a reference Python implementation :-) It was discussed when compare_digest() was introdused. Looks as pure Python implementation is not possible (without destroying the purpose of compare_digest()). Even with C implementation we should be very careful. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GC pauses in CPython
HI I'm working on an incremental GC for PyPy. How do I measure GC pauses in CPython? (that is, the circular reference searching stuff) Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make str/bytes hash algorithm pluggable?
Hi, I have found a link to a speed comparison of hash functions: http://code.google.com/p/xxhash/ Regards, Wolfgang ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GC pauses in CPython
Le Mon, 14 Oct 2013 13:49:34 +0200, Maciej Fijalkowski a écrit : > HI > > I'm working on an incremental GC for PyPy. How do I measure GC pauses > in CPython? (that is, the circular reference searching stuff) timeit gc.collect()? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GC pauses in CPython
Am 14.10.13 13:49, schrieb Maciej Fijalkowski: > I'm working on an incremental GC for PyPy. How do I measure GC pauses > in CPython? (that is, the circular reference searching stuff) I would instrument the interpreter. The tricky part may be to subtract the time for any resulting finalization (and whether or not to subtract that at all). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GC pauses in CPython
Maciej Fijalkowski gmail.com> writes: > > HI > > I'm working on an incremental GC for PyPy. How do I measure GC pauses > in CPython? (that is, the circular reference searching stuff) > > Cheers, > fijal > For what it's worth I threw together some code that might be helpful: http://bpaste.net/show/140334/ if someone was interested it might be a cool idea to properly organize this up and find a place to expose VM statistics like this. It'd also probably useful to use sane units, and maybe (it's unclear to me) exclude some amount of finalizations (Ideally I think you'd ignore use __del__ functions, but keep the bits of C code that decref other things and actually call free()). Alex ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GC pauses in CPython
On Mon, Oct 14, 2013 at 2:11 PM, "Martin v. Löwis" wrote: > Am 14.10.13 13:49, schrieb Maciej Fijalkowski: >> I'm working on an incremental GC for PyPy. How do I measure GC pauses >> in CPython? (that is, the circular reference searching stuff) > > I would instrument the interpreter. The tricky part may be to subtract > the time for any resulting finalization (and whether or not to subtract > that at all). > > Regards, > Martin > seems that: gc.set_debug(gc.DEBUG_STATS) does the job obviously timing gc.collect is quite the opposite of what I'm trying to achieve (see how cpython deals with when to collect) I think including finalizer time is fine ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GC pauses in CPython
Le Mon, 14 Oct 2013 14:25:18 +0200, Maciej Fijalkowski a écrit : > On Mon, Oct 14, 2013 at 2:11 PM, "Martin v. Löwis" > wrote: > > Am 14.10.13 13:49, schrieb Maciej Fijalkowski: > >> I'm working on an incremental GC for PyPy. How do I measure GC > >> pauses in CPython? (that is, the circular reference searching > >> stuff) > > > > I would instrument the interpreter. The tricky part may be to > > subtract the time for any resulting finalization (and whether or > > not to subtract that at all). > > > > Regards, > > Martin > > > > seems that: > > gc.set_debug(gc.DEBUG_STATS) does the job > > obviously timing gc.collect is quite the opposite of what I'm trying > to achieve (see how cpython deals with when to collect) Why "the opposite"? The time of a GC pause in CPython is the time executing gc.collect(). And most of the time gc.collect() will spend its time walking live objects, not dead ones, so executing it multiple times should only introduce a minor bias. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GC pauses in CPython
On Mon, Oct 14, 2013 at 2:34 PM, Antoine Pitrou wrote: > Le Mon, 14 Oct 2013 14:25:18 +0200, > Maciej Fijalkowski a écrit : >> On Mon, Oct 14, 2013 at 2:11 PM, "Martin v. Löwis" >> wrote: >> > Am 14.10.13 13:49, schrieb Maciej Fijalkowski: >> >> I'm working on an incremental GC for PyPy. How do I measure GC >> >> pauses in CPython? (that is, the circular reference searching >> >> stuff) >> > >> > I would instrument the interpreter. The tricky part may be to >> > subtract the time for any resulting finalization (and whether or >> > not to subtract that at all). >> > >> > Regards, >> > Martin >> > >> >> seems that: >> >> gc.set_debug(gc.DEBUG_STATS) does the job >> >> obviously timing gc.collect is quite the opposite of what I'm trying >> to achieve (see how cpython deals with when to collect) > > Why "the opposite"? The time of a GC pause in CPython is the time > executing gc.collect(). And most of the time gc.collect() will spend > its time walking live objects, not dead ones, so executing it multiple > times should only introduce a minor bias. well, I'm not trying to measure it at *one point in time* but to provide some statistics. invoking it kills the point quite a bit. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GC pauses in CPython
Le Mon, 14 Oct 2013 14:38:44 +0200, Maciej Fijalkowski a écrit : > On Mon, Oct 14, 2013 at 2:34 PM, Antoine Pitrou > wrote: > > Le Mon, 14 Oct 2013 14:25:18 +0200, > > Maciej Fijalkowski a écrit : > >> On Mon, Oct 14, 2013 at 2:11 PM, "Martin v. Löwis" > >> wrote: > >> > Am 14.10.13 13:49, schrieb Maciej Fijalkowski: > >> >> I'm working on an incremental GC for PyPy. How do I measure GC > >> >> pauses in CPython? (that is, the circular reference searching > >> >> stuff) > >> > > >> > I would instrument the interpreter. The tricky part may be to > >> > subtract the time for any resulting finalization (and whether or > >> > not to subtract that at all). > >> > > >> > Regards, > >> > Martin > >> > > >> > >> seems that: > >> > >> gc.set_debug(gc.DEBUG_STATS) does the job > >> > >> obviously timing gc.collect is quite the opposite of what I'm > >> trying to achieve (see how cpython deals with when to collect) > > > > Why "the opposite"? The time of a GC pause in CPython is the time > > executing gc.collect(). And most of the time gc.collect() will spend > > its time walking live objects, not dead ones, so executing it > > multiple times should only introduce a minor bias. > > well, I'm not trying to measure it at *one point in time* but to > provide some statistics. invoking it kills the point quite a bit. Ah, then you can plug into the new "callbacks" property: http://docs.python.org/3.3/library/gc.html#gc.callbacks Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GC pauses in CPython
On Mon, Oct 14, 2013 at 2:42 PM, Antoine Pitrou wrote: > Le Mon, 14 Oct 2013 14:38:44 +0200, > Maciej Fijalkowski a écrit : > >> On Mon, Oct 14, 2013 at 2:34 PM, Antoine Pitrou >> wrote: >> > Le Mon, 14 Oct 2013 14:25:18 +0200, >> > Maciej Fijalkowski a écrit : >> >> On Mon, Oct 14, 2013 at 2:11 PM, "Martin v. Löwis" >> >> wrote: >> >> > Am 14.10.13 13:49, schrieb Maciej Fijalkowski: >> >> >> I'm working on an incremental GC for PyPy. How do I measure GC >> >> >> pauses in CPython? (that is, the circular reference searching >> >> >> stuff) >> >> > >> >> > I would instrument the interpreter. The tricky part may be to >> >> > subtract the time for any resulting finalization (and whether or >> >> > not to subtract that at all). >> >> > >> >> > Regards, >> >> > Martin >> >> > >> >> >> >> seems that: >> >> >> >> gc.set_debug(gc.DEBUG_STATS) does the job >> >> >> >> obviously timing gc.collect is quite the opposite of what I'm >> >> trying to achieve (see how cpython deals with when to collect) >> > >> > Why "the opposite"? The time of a GC pause in CPython is the time >> > executing gc.collect(). And most of the time gc.collect() will spend >> > its time walking live objects, not dead ones, so executing it >> > multiple times should only introduce a minor bias. >> >> well, I'm not trying to measure it at *one point in time* but to >> provide some statistics. invoking it kills the point quite a bit. > > Ah, then you can plug into the new "callbacks" property: > http://docs.python.org/3.3/library/gc.html#gc.callbacks > > Regards > > Antoine. New in version 3.3. no, thanks ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation
On Sun, Oct 13, 2013 at 3:08 PM, Victor Stinner wrote: > Le 13 oct. 2013 10:19, "Stefan Behnel" a écrit : > > > I agree. I find it much easier to read a plain and obvious > > > > try: > >from _cmodule import * > > except ImportError: > >from _pymodule import * > > > > in a facade module ... > > I miss maybe something. I don't understand why you would like to use the > Python implementation if a C implementation is available and probably > (much) faster. > > Maybe developers of PyPy, IronPython and Jython appreciate our effort to > provide a Python implementation which is up to date and well tested. But > why should we pay a price (bad performance) if the module is not (never? > who uses _pyio?) used in CPython. If another Python uses it, the file can > be renamed (ex: _pyio.py becomes simply io.py). > Because doing a rename like that is a deviation between implementations that saves you nothing more than a file with four lines. And "bad performance" in this instance is a single import * which in the grand scheme of things is cheap, especially in this instance where the module is not on the critical path (and even if it was I would argue it isn't worth worrying about). > IMO if the C module is complete (has no extra functions in the "facade" > module), it should get the main name (ex: decimal, not _decimal). > Why? It's not the reference implementation as that's the pure Python version, but your suggested naming scheme purports the opposite. -Brett ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] non-US zip archives support in zipfile.py
Hello,
I'd like to submit patch to support zip archives created on systems that
use non-US codepage (e.g. russian CP866).
Codepage would be specified in additional parameter of ZipFile
constructor, named "codepage".
If it is not specified, old behavior is preserved (use CP437).
--- zipfile.py-orig 2013-09-18 16:45:56.0 +0400
+++ zipfile.py 2013-10-15 00:24:06.105157572 +0400
@@ -885,7 +885,7 @@
fp = None # Set here since __del__ checks it
_windows_illegal_name_trans_table = None
-def __init__(self, file, mode="r", compression=ZIP_STORED,
allowZip64=False):
+def __init__(self, file, mode="r", compression=ZIP_STORED,
allowZip64=False, codepage='cp437'):
"""Open the ZIP file with mode read "r", write "w" or append
"a"."""
if mode not in ("r", "w", "a"):
raise RuntimeError('ZipFile() requires mode "r", "w", or
"a"')
@@ -901,6 +901,7 @@
self.mode = key = mode.replace('b', '')[0]
self.pwd = None
self._comment = b''
+self.codepage = codepage
# Check if we were passed a file-like object
if isinstance(file, str):
@@ -1002,7 +1003,7 @@
filename = filename.decode('utf-8')
else:
# Historical ZIP filename encoding
-filename = filename.decode('cp437')
+filename = filename.decode(self.codepage)
# Create ZipInfo instance to store file information
x = ZipInfo(filename)
x.extra = fp.read(centdir[_CD_EXTRA_FIELD_LENGTH])
@@ -1157,7 +1158,7 @@
# UTF-8 filename
fname_str = fname.decode("utf-8")
else:
-fname_str = fname.decode("cp437")
+fname_str = fname.decode(self.codepage)
if fname_str != zinfo.orig_filename:
raise BadZipFile(
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] non-US zip archives support in zipfile.py
Hello, On Tue, 15 Oct 2013 00:55:05 +0400 Sergey Dorofeev wrote: > Hello, > > I'd like to submit patch to support zip archives created on systems that > use non-US codepage (e.g. russian CP866). > Codepage would be specified in additional parameter of ZipFile > constructor, named "codepage". > If it is not specified, old behavior is preserved (use CP437). Thanks for contributing! Patches posted on the mailing-list tend to get lost. You should open an issue on the bug tracker and post your patch there: http://bugs.python.org/ Also, the devguide can help you know how to make your patch more complete (for example by adding unit tests): http://docs.python.org/devguide/ Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] non-US zip archives support in zipfile.py
I opened an issue proposing exactly the same change, but I didn't provide a patch. Thanks for working on the issue. (Sorry I don't know the issue number. Search for "zipfile encoding".) Victor ___ Python-Dev mailing list Python-Dev@python.org 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 03:27 PM, Raymond Hettinger wrote: >The module maintainer (Nick) approved the name change from his original >preference for ignored(). That should had been the end of it. As a general plea, please be sure to record the rationale and decisions in the appropriate place, such as the tracker and/or commit message. I think it's fine for such minor decisions to be made in high bandwidth forums such as IRC, it's also incumbent on the participants to be mindful of the larger community of core developers and users. Not doing so makes our process less transparent, puts legitimacy at risk, and alienates users and developers who may not be privileged to those out-of-band discussions. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] non-US zip archives support in zipfile.py
On Mon, Oct 14, 2013 at 6:13 PM, Victor Stinner wrote: > I opened an issue proposing exactly the same change, but I didn't provide a > patch. I found this: http://bugs.python.org/issue10614 but it has (seemingly incorrect) patch. Also related: http://bugs.python.org/issue10972 Victor - is any of these what you had in mind? ___ Python-Dev mailing list Python-Dev@python.org 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 15 Oct 2013 08:54, "Barry Warsaw" wrote: > > On Oct 12, 2013, at 03:27 PM, Raymond Hettinger wrote: > > >The module maintainer (Nick) approved the name change from his original > >preference for ignored(). That should had been the end of it. > > As a general plea, please be sure to record the rationale and decisions in the > appropriate place, such as the tracker and/or commit message. I think it's > fine for such minor decisions to be made in high bandwidth forums such as IRC, > it's also incumbent on the participants to be mindful of the larger community > of core developers and users. Not doing so makes our process less > transparent, puts legitimacy at risk, and alienates users and developers who > may not be privileged to those out-of-band discussions. Agreed, although in this case there wasn't much additional rationale beyond "Raymond and I decided we preferred the shorter spelling, so we changed it" :) I figured it was a minor enough change that the commit message was adequate documentation, but I acknowledge it would have been better to create a new issue with its own NEWS entry to more explicitly track the change. Cheers, Nick. > > Cheers, > -Barry > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org 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 14 Oct 2013 09:28, "Glenn Linderman" wrote: > > On 10/12/2013 11:57 PM, Nick Coghlan wrote: >> >> For the record, this thread did prompt me to consider the new construct anew, but on reflection, I still consider it a reasonable addition to contextlib. >> >> It substantially improves the simple cases it is intended to help with, and, if anything, makes overly broad exception suppression *more* obviously dubious (because the name of the construct doesn't match the consequences for multi-line suites). > > For the record, the logic in the last paragraph is the most dubious thing I've ever seen you post. I didn't articulate the point very well. The reason I originally approved the change (and the reason I have kept it despite the objections raised) is because it allows correct-but-ugly code like: try: os.unlink(fname) except FileNotFoundError: pass To be rewritten as the significantly more elegant: with ignore(FileNotFoundError): os.unlink(fname) which is much closer to the version that expects to have complete control over the file's lifecycle: os.unlink(fname) The more explicit statement of intent can also be exploited in static code analysis (such as linting), although I don't expect anyone to actually do that any time soon. This benefit when used correctly then needs to be weighed against the risk of it being used *incorrectly*, especially by people that expect it to work like VB's "on error resume next" rather than by suppressing the exception and resuming execution after the with statement. The problem of overbroad exception handling isn't a new one, though, and I don't believe this feature makes that problem *worse*, and, by making it simpler and cleaner to suppress exceptions from a single statement, may make it better. For example, this code is wrong: try: os.unlink(fname) os.unlink(fname2) except FileNotFoundError: pass You could fix this particular case with a loop (since the two commands differ by a single value), but that option isn't always going to be available. Requiring 3 extra lines per command is a significant factor pushing against correctly suppressing exceptions from cleanup code that may fail for legitimate reasons. The new CM handles these cases a little more neatly, in a way that doesn't require the use of a loop: with ignore(FileNotFoundError): os.unlink(fname) with ignore(FileNotFoundError): os.unlink(fname2) What the new CM *doesn't* handle nicely is multi-statement suites, and I'm OK with that. Handling those is not what *this* CM is for, and I believe trying to generalise it would harm the primary intended use case. I now *do* plan to experiment with a more general with statement termination construct in contextlib2 before Python 3.5, but that's orthogonal to *this* change. Regards, Nick. > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, Oct 14, 2013 at 8:18 PM, Nick Coghlan wrote: > .. especially by people that expect it to work like VB's "on error resume > next" > rather than by suppressing the exception and resuming execution after the > with statement. "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." -- Edsger W.Dijkstra, 18 June 1975, "How do we tell truths that might hurt?" http://www.cs.virginia.edu/~cs655/readings/ewd498.html ___ Python-Dev mailing list Python-Dev@python.org 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 Tue, Oct 15, 2013 at 10:18:56AM +1000, Nick Coghlan wrote: > I didn't articulate the point very well. The reason I originally > approved the change (and the reason I have kept it despite the > objections raised) is because it allows correct-but-ugly code like: > > try: > os.unlink(fname) > except FileNotFoundError: > pass > > To be rewritten as the significantly more elegant: > > with ignore(FileNotFoundError): > os.unlink(fname) I thought that was already clear, to be honest. As an aside, calling the try/except construct above "ugly" seems a stretch to me - it's a little verbose if you're going to be using it a lot, but presumably in that case you'd just wrap it in a safe_unlink() convenience function if it became annoying. > This benefit when used correctly then needs to be weighed against the > risk of it being used *incorrectly*, especially by people that expect > it to work like VB's "on error resume next" rather than by suppressing > the exception and resuming execution after the with statement. > > The problem of overbroad exception handling isn't a new one, though, > and I don't believe this feature makes that problem *worse*, and, by > making it simpler and cleaner to suppress exceptions from a single > statement, may make it better. For example, this code is wrong: > > try: > os.unlink(fname) > os.unlink(fname2) > except FileNotFoundError: > pass Yes, it's bad code, but it's more intuitively obvious what it does (and therefore that it's badly written) than the equivalent with ignore(FileNotFoundError): os.unlink(fname) os.unlink(fname2) ... as others have pointed out. The above suffers from the same (famously solved by Python) problem as C code with inconsistent braces and indentation: there's a disconnect between what it looks like and what it does. I think one problem is that ignore() doesn't actually do what its name suggests - the flow of execution is changed if an exception occurs, which by definition means the exception isn't being ignored. Maybe it would be better to call it silence()? That's still not perfect IMO, but it's closer to an accurate description of what's going on. -[]z. -- Zero Piraeus: obiter dictum http://etiol.net/pubkey.asc ___ Python-Dev mailing list Python-Dev@python.org 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/14/2013 06:04 PM, Zero Piraeus wrote: : On Tue, Oct 15, 2013 at 10:18:56AM +1000, Nick Coghlan wrote: I didn't articulate the point very well. The reason I originally approved the change (and the reason I have kept it despite the objections raised) is because it allows correct-but-ugly code like: try: os.unlink(fname) except FileNotFoundError: pass To be rewritten as the significantly more elegant: with ignore(FileNotFoundError): os.unlink(fname) I thought that was already clear, to be honest. As an aside, calling the try/except construct above "ugly" seems a stretch to me - it's a little verbose if you're going to be using it a lot, but presumably in that case you'd just wrap it in a safe_unlink() convenience function if it became annoying. This benefit when used correctly then needs to be weighed against the risk of it being used *incorrectly*, especially by people that expect it to work like VB's "on error resume next" rather than by suppressing the exception and resuming execution after the with statement. The problem of overbroad exception handling isn't a new one, though, and I don't believe this feature makes that problem *worse*, and, by making it simpler and cleaner to suppress exceptions from a single statement, may make it better. For example, this code is wrong: try: os.unlink(fname) os.unlink(fname2) except FileNotFoundError: pass Yes, it's bad code, but it's more intuitively obvious what it does (and therefore that it's badly written) than the equivalent with ignore(FileNotFoundError): os.unlink(fname) os.unlink(fname2) ... as others have pointed out. The above suffers from the same (famously solved by Python) problem as C code with inconsistent braces and indentation: there's a disconnect between what it looks like and what it does. I think one problem is that ignore() doesn't actually do what its name suggests - the flow of execution is changed if an exception occurs, which by definition means the exception isn't being ignored. Maybe it would be better to call it silence()? That's still not perfect IMO, but it's closer to an accurate description of what's going on. -[]z. but is: with ignore(FileNotFoundError): os.unlink(fname) os.unlink(fname2) equivalent to: try: os.unlink(fname) os.unlink(fname2) except FileNotFoundError: pass or to: try: os.unlink(fname) except FileNotFoundError: pass try: os.unlink(fname2) except FileNotFoundError: pass If the documentation isn't clear, I'd read it the second way. (And I'd *WANT* it to be the second way.) -- Charles Hixson ___ Python-Dev mailing list Python-Dev@python.org 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/14/2013 5:18 PM, Nick Coghlan wrote: What the new CM *doesn't* handle nicely is multi-statement suites, and I'm OK with that. Yeah, that is the dubious part. You can't even convince python-dev that saving 2 lines to ignore an exception in one line of code is a good idea, at the cost of the potential for misunderstanding and misuse; I can't conceive of how verbose the documentation would have to be to explain it to people that don't know python well... especially to the cut-n-pasters that don't read the documentation anyway (in some sense they don't matter, until they discover the bug, and then try to read the documentation). I suspect that there is no logic that will quiet down this thread with the current implementation and decision, now that it has been exposed for what it is ... maybe the only way would be to appeal to Guido to proclaim that this thread should stop. Of course, if the name were changed to be accurate, or the feature made less prone to misuse, then maybe it would terminate. I've got an extra can of "break_out_if" paint here... ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
