Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Le 15/10/2013 05:12, Glenn Linderman a écrit : > > I've got an extra can of "break_out_if" paint here... > another shed color: with contextlib.except_pass(FileNotFoundError): os.unlink(fname) explicit and hopefully not too ugly ___ 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
Both issues are related and should be fixed in the *same* commit. Python should provide an option to encode explicitly filenames to UTF-8. Or maybe better: encode to UTF-8 by default, with an option to encode to cp437, and another to encode to an arbitrary encoding. Victor 2013/10/15 Alexander Belopolsky : > 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] non-US zip archives support in zipfile.py
FYI zipfile does do UTF-8 (http://hg.python.org/cpython/file/d7ebe03fa752/Lib/zipfile.py#l368). Only the non-Unicode encodings might need some help. I like that the patch is only concerned with decoding. Is it necessary to support writing non-UTF8 encodings? On Tue, Oct 15, 2013 at 10:20 AM, Victor Stinner wrote: > Both issues are related and should be fixed in the *same* commit. > Python should provide an option to encode explicitly filenames to > UTF-8. Or maybe better: encode to UTF-8 by default, with an option to > encode to cp437, and another to encode to an arbitrary encoding. > > Victor > > 2013/10/15 Alexander Belopolsky : >> 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/dholth%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] non-US zip archives support in zipfile.py
Am 15.10.13 10:53, schrieb Daniel Holth: > FYI zipfile does do UTF-8 > (http://hg.python.org/cpython/file/d7ebe03fa752/Lib/zipfile.py#l368). > Only the non-Unicode encodings might need some help. I like that the > patch is only concerned with decoding. Is it necessary to support > writing non-UTF8 encodings? For purity, no. For practicality, perhaps. It might be that some tools don't know how to unpack files marked as UTF-8, and always default to the system code page. OTOH, before accepting such a change, I'd like to know what actual existing tool would require such a hack, and a confirmation that this very tool indeed does not support UTF-8. 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] non-US zip archives support in zipfile.py
On Tue, Oct 15, 2013 at 10:20:03AM +0200, Victor Stinner wrote: > Both issues are related and should be fixed in the *same* commit. > Python should provide an option to encode explicitly filenames to > UTF-8. Or maybe better: encode to UTF-8 by default, with an option to > encode to cp437, and another to encode to an arbitrary encoding. Why single out cp437 for special treatment? Surely it's enough to use UTF-8 by default, or specify an arbitrary encoding. -- Steven ___ 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 October 2013 13:12, Glenn Linderman wrote: > 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 come to the conclusion it makes sense to rename it from ignore to suppress, since that's the term already used for this operation in the rest of the context management docs: http://bugs.python.org/issue19266 Given the number of people vehemently opposed to the old name, I'm sure there will be plenty of volunteers to create a patch while I do some more work on PEP 453 :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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().
Le Tue, 15 Oct 2013 22:05:41 +1000, Nick Coghlan a écrit : > On 15 October 2013 13:12, Glenn Linderman > wrote: > > 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 come to the conclusion it makes sense to rename it from ignore to > suppress, since that's the term already used for this operation in the > rest of the context management docs: http://bugs.python.org/issue19266 "suppress" and/or "trap" (which I believe is a common name for such operation). 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
On Tue, Oct 15, 2013 at 8:02 AM, Steven D'Aprano wrote: > On Tue, Oct 15, 2013 at 10:20:03AM +0200, Victor Stinner wrote: >> Both issues are related and should be fixed in the *same* commit. >> Python should provide an option to encode explicitly filenames to >> UTF-8. Or maybe better: encode to UTF-8 by default, with an option to >> encode to cp437, and another to encode to an arbitrary encoding. > > Why single out cp437 for special treatment? Surely it's enough to use > UTF-8 by default, or specify an arbitrary encoding. It is part of the ZIP specification. CP437 or UTF-8 are the two official choices, but other encodings happen on Russian, Japanese systems. ___ 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] Checking in Argument Clinic early?
I really want to get Argument Clinic in to Python 3.4. Currently the following is true: * It has an implementation I've been working on for more than a year. * I assert that it's a reasonable approach and the APIs are ready for public consumption. * The syntax for the DSL is the one proposed by Guido at PyCon US 2013. * So far It has little in the way of documentation apart from the PEP. * The PEP is out of date and not ready for pronouncement. * IIUC Guido said he's not delegating this PEP. There's now a discussion afoot about merging "tulip" in, in time for 3.4a4, which I think is going to happen. And as Release Manager for 3.4 I'm happy to see this happen. I'd like to propose much the same thing for Argument Clinic: check it in now, before 3.4a4, and let it bake in trunk a little before feature freeze at beta 1 while I run around and finish the documentation. You can review the existing code here: https://bitbucket.org/larry/python-clinic/ (Yes, in this fork clinic.py is at the root--but then I never intended to merge this fork.) Checking in Clinic would mean: * Adding the tool (one file, "clinic.py") and its test suite into Tools/clinic/ * Adding its documentation somewhere in the Doc/ directory * Merging six or eight places where I've converted random functions to use Clinic Brett Cannon gave the code a cursory review at PyCon CA over about six hours, and iirc he said it was basically reasonable. He wanted more coverage in the tests, and more in-depth review of course, but he had only minor feedback, all of which I've incorporated. (In case you're wondering: last time I tried, coverage from just the unit test suite was about 85%, but if you also ran all my sample usage of it in the CPython code it rose to like 92%.) So, quick poll: do you approve of me checking Argument Clinic in to Python 3.4 trunk in its current state before 3.4a4? //arry/ ___ 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 October 2013 22:27, Antoine Pitrou wrote: > Le Tue, 15 Oct 2013 22:05:41 +1000, > Nick Coghlan a écrit : > >> On 15 October 2013 13:12, Glenn Linderman >> wrote: >> > 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 come to the conclusion it makes sense to rename it from ignore to >> suppress, since that's the term already used for this operation in the >> rest of the context management docs: http://bugs.python.org/issue19266 > > "suppress" and/or "trap" (which I believe is a common name for such > operation). I chose the new name based on the terminology used in the existing docs (I'll grant that a lot of these docs were written by me at various points in time, but taken together they still create a solid precedent that "suppress" refers to discarding the exception, while "trap" just refers to catching it and then potentially doing something with it, including reraising it). >From http://docs.python.org/dev/library/stdtypes.html#contextmanager.__exit__: "Exit the runtime context and return a Boolean flag indicating if any exception that occurred should be suppressed." "Returning a true value from this method will cause the with statement to suppress the exception and continue execution with the statement immediately following the with statement. " >From http://docs.python.org/dev/reference/datamodel.html#object.__exit__ "If an exception is supplied, and the method wishes to suppress the exception (i.e., prevent it from being propagated), it should return a true value." >From http://docs.python.org/dev/library/contextlib#contextlib.contextmanager "If an exception is trapped merely in order to log it or to perform some action (rather than to suppress it entirely), the generator must reraise that exception." >From http://docs.python.org/dev/library/contextlib#contextlib.ignore (!) "As with any other mechanism that completely suppresses exceptions, it should only be used to cover very specific errors where silently ignoring the exception is known to be the right thing to do." >From http://docs.python.org/dev/library/contextlib#contextlib.ExitStack "...if an inner callback suppresses or replaces an exception, then outer callbacks will be passed arguments based on that updated state." >From >http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.enter_context "These context managers may suppress exceptions just as they normally would if used directly as part of a with statement." >From http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.push "By returning true values, these callbacks can suppress exceptions the same way context manager __exit__() methods can." >From >http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.callback "Unlike the other methods, callbacks added this way cannot suppress exceptions (as they are never passed the exception details)." So, having been convinced that "ignore" was the wrong choice of name, reviewing the docs made it clear to me what the name *should* be. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Checking in Argument Clinic early?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2013 08:55 AM, Larry Hastings wrote: > So, quick poll: do you approve of me checking Argument Clinic in to > Python 3.4 trunk in its current state before 3.4a4? +1 Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJdPgsACgkQ+gerLs4ltQ6CIACbB47gAz5px1MGVhRvqY+S0GP/ SYUAnRSQ2e1xqjySgwrFYz7gCuHbWksJ =+QW/ -END PGP SIGNATURE- ___ 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] Checking in Argument Clinic early?
On 15 October 2013 22:55, Larry Hastings wrote: > So, quick poll: do you approve of me checking Argument Clinic in to Python > 3.4 trunk in its current state before 3.4a4? I'm inclined to say yes, but ultimately the +1 you need is Guido's :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Checking in Argument Clinic early?
On 10/15/2013 02:06 PM, Nick Coghlan wrote: On 15 October 2013 22:55, Larry Hastings wrote: So, quick poll: do you approve of me checking Argument Clinic in to Python 3.4 trunk in its current state before 3.4a4? I'm inclined to say yes, but ultimately the +1 you need is Guido's :) In the past I've found Guido extremely deferential to the Release Manager. I haven't asked the 3.4 Release Manager his opinion in so many words, but I gather he's quite encouraging. //arry/ ___ 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
Hi! On Tue, Oct 15, 2013 at 12:22:29PM +0200, "\"Martin v. L?wis\"" wrote: > Am 15.10.13 10:53, schrieb Daniel Holth: > > FYI zipfile does do UTF-8 > > (http://hg.python.org/cpython/file/d7ebe03fa752/Lib/zipfile.py#l368). > > Only the non-Unicode encodings might need some help. I like that the > > patch is only concerned with decoding. Is it necessary to support > > writing non-UTF8 encodings? > > For purity, no. For practicality, perhaps. It might be that some tools > don't know how to unpack files marked as UTF-8, and always default to > the system code page. > > OTOH, before accepting such a change, I'd like to know what actual > existing tool would require such a hack, and a confirmation that this > very tool indeed does not support UTF-8. Just an example how I create and extract zip files with Russian filenames on Linux: http://phdru.name/Software/Python/misc/zip.py.txt http://phdru.name/Software/Python/misc/unzip.py.txt I hardcoded cp866 encoding to handle zip files the same way other tools (like WinZIP/WinRAR) handle Russian filenames. I hardcoded cp866 encoding into the code because it's the only encoding I've ever saw. cp866 is the OEM encoding in Windows; ANSI encoding is cp1251. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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
Am 15.10.13 14:49, schrieb Daniel Holth: > It is part of the ZIP specification. CP437 or UTF-8 are the two > official choices, but other encodings happen on Russian, Japanese > systems. Indeed. Formally, the other encodings are not supported by the ZIP specification, and are thus formally misuse of the format. I believe (without having proof) that early versions of the specification failed to discuss the file name encoding at all, making people believe that it is unspecified and always the system encoding (which is useless, of course, as you create zip files to move them across systems). 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] Checking in Argument Clinic early?
Le Tue, 15 Oct 2013 13:55:47 +0100, Larry Hastings a écrit : > > You can review the existing code here: > > https://bitbucket.org/larry/python-clinic/ You didn't create it as a (Bitbucket) fork of CPython, and you didn't put your changes in a separate branch, so this repo is a bit useless to review the changes :-/ Is clinic.py automatically invoked by the build chain? (i.e. Makefile) 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] Checking in Argument Clinic early?
On 10/15/2013 02:59 PM, Antoine Pitrou wrote: Le Tue, 15 Oct 2013 13:55:47 +0100, Larry Hastings a écrit : You can review the existing code here: https://bitbucket.org/larry/python-clinic/ You didn't create it as a (Bitbucket) fork of CPython, and you didn't put your changes in a separate branch, so this repo is a bit useless to review the changes :-/ Thanks for at least trying! It is a fork of CPython, but yeah I didn't use Bitbucket's UI to create it. If you want to struggle through it by hand, read clinic.py (obviously), and then search for the string "clinic" in these files: Modules/_cursesmodule.c Modules/_datetimemodule.c Modules/_dbmmodule.c Modules/posixmodule.c Modules/unicodedata.c Modules/_weakref.c Modules/zlibmodule.c Objects/dictobject.c Objects/unicodeobject.c Can you suggest how I could make it easier for you to review? I'd be happy to make an issue for it, which I probably should do anyway (if there isn't already one). Is clinic.py automatically invoked by the build chain? (i.e. Makefile) Not at the moment. I'm a neophyte when it comes to moderne sophisticated Makefile munging. There's also a chicken-and-egg problem there. //arry/ ___ 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] Checking in Argument Clinic early?
I'm +1 -- I have been ever since Larry & I discussed it at EuroPython 2012. On Tue, Oct 15, 2013 at 6:06 AM, Nick Coghlan wrote: > On 15 October 2013 22:55, Larry Hastings wrote: > > So, quick poll: do you approve of me checking Argument Clinic in to > Python > > 3.4 trunk in its current state before 3.4a4? > > I'm inclined to say yes, but ultimately the +1 you need is Guido's :) > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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, 15 Oct 2013 22:57:34 +1000, Nick Coghlan wrote: > On 15 October 2013 22:27, Antoine Pitrou wrote: > > Le Tue, 15 Oct 2013 22:05:41 +1000, > > Nick Coghlan a écrit : > > > >> On 15 October 2013 13:12, Glenn Linderman > >> wrote: > >> > 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 come to the conclusion it makes sense to rename it from ignore to > >> suppress, since that's the term already used for this operation in the > >> rest of the context management docs: http://bugs.python.org/issue19266 > > > > "suppress" and/or "trap" (which I believe is a common name for such > > operation). > > I chose the new name based on the terminology used in the existing > docs (I'll grant that a lot of these docs were written by me at > various points in time, but taken together they still create a solid > precedent that "suppress" refers to discarding the exception, while > "trap" just refers to catching it and then potentially doing something > with it, including reraising it). > > From http://docs.python.org/dev/library/stdtypes.html#contextmanager.__exit__: > > "Exit the runtime context and return a Boolean flag indicating if any > exception that occurred should be suppressed." > > "Returning a true value from this method will cause the with statement > to suppress the exception and continue execution with the statement > immediately following the with statement. " Someone could read this and reason by analogy: "so if the *context manager* is named suppress, then execution will resume following the statement where the exception was suppressed". They'd be wrong, of course, I'm just pointing out some confusion that we might still see. > From http://docs.python.org/dev/reference/datamodel.html#object.__exit__ > > "If an exception is supplied, and the method wishes to suppress the > exception (i.e., prevent it from being propagated), it should return a > true value." > > From http://docs.python.org/dev/library/contextlib#contextlib.contextmanager > > "If an exception is trapped merely in order to log it or to perform > some action (rather than to suppress it entirely), the generator must > reraise that exception." > > From http://docs.python.org/dev/library/contextlib#contextlib.ignore (!) > > "As with any other mechanism that completely suppresses exceptions, it > should only be used to cover very specific errors where silently > ignoring the exception is known to be the right thing to do." This should emphasize that execution resumes with the statement following the with block, and give that as a strong motivation for only using it to cover the line where the exception is to be suppressed (and there are likely to be very few cases where it would reasonable for it to be more than one line, and that is probably worth pointing out). > From http://docs.python.org/dev/library/contextlib#contextlib.ExitStack > > "...if an inner callback suppresses or replaces an exception, then > outer callbacks will be passed arguments based on that updated state." > > From > http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.enter_context > > "These context managers may suppress exceptions just as they normally > would if used directly as part of a with statement." > > From http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.push > > "By returning true values, these callbacks can suppress exceptions the > same way context manager __exit__() methods can." > > From > http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.callback > > "Unlike the other methods, callbacks added this way cannot suppress > exceptions (as they are never passed the exception details)." > > So, having been convinced that "ignore" was the wrong choice of name, > reviewing the docs made it clear to me what the name *should* be. I think 'trap' would be much clearer. What about making the context manager provide the trapped exception, in a fashion similar to what assertRaises does? Even if that was almost never used in practice, the fact that the CM provides only *one* exception no matter how many statements are in the with block would strongly reinforce the actual semantics of the construct. It would also make it parallel to assertRaises, which seems like a consistency bonus. And I could see it getting used. I think I've had code where the logic was: possibly trap an exception, stuff it in a variable, do some logic, check the variable to see if we had an exception earlier, and if so do something with it or otherwise branch the logic. I won't say this is common, and I won't say there wouldn't often be a better way to write it...but I can think that it might have utility. With that change, I'd be +1. With just suppress, I'm -0. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsub
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
: On Tue, Oct 15, 2013 at 10:05:41PM +1000, Nick Coghlan wrote: > I've come to the conclusion it makes sense to rename it from ignore to > suppress, since that's the term already used for this operation in the > rest of the context management docs: http://bugs.python.org/issue19266 > > Given the number of people vehemently opposed to the old name, I'm > sure there will be plenty of volunteers to create a patch while I do > some more work on PEP 453 :) Patch submitted :-) -[]z. -- Zero Piraeus: dictatum erat 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 Oct 15, 2013, at 11:52 AM, R. David Murray wrote: >I think 'trap' would be much clearer. What about making the context >manager provide the trapped exception, in a fashion similar to >what assertRaises does? Even if that was almost never used in practice, >the fact that the CM provides only *one* exception no matter how >many statements are in the with block would strongly reinforce the >actual semantics of the construct. It would also make it parallel to >assertRaises, which seems like a consistency bonus. > >And I could see it getting used. I think I've had code where the logic >was: possibly trap an exception, stuff it in a variable, do some logic, >check the variable to see if we had an exception earlier, and if so do >something with it or otherwise branch the logic. I won't say this is >common, and I won't say there wouldn't often be a better way to write >it...but I can think that it might have utility. > >With that change, I'd be +1. With just suppress, I'm -0. Yeah, I would also be +1 with that. -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] Checking in Argument Clinic early?
On Oct 15, 2013, at 5:55 AM, Larry Hastings wrote: > I'd like to propose much the same thing for Argument Clinic: check it in now, > before 3.4a4, and let it bake in trunk a little before feature freeze at beta > 1 while I run around and finish the documentation. This is a good plan. "Letting it bake" means we get more of a chance to interact with it and you will give more of a chance to make refinements. Raymond ___ 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] Checking in Argument Clinic early?
On 10/15/2013 03:52 PM, Guido van Rossum wrote: I'm +1 -- I have been ever since Larry & I discussed it at EuroPython 2012. If this love-in continues I'll prep a release tonight and commit it in the morning... just before my flight home across the Atlantic. //arry/ ___ 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 11:52 AM, R. David Murray wrote: > I think 'trap' would be much clearer. +1. Short and sweet, and just ambiguous enough that you don't leap to the conclusion that the error is ignored. I agree that "suppress" is basically a synonym for "ignore"; trap at least *implies* some kind of control flow change, which is what's needed to prevent misconceptions. Personally, I would rate "catch" higher than "trap" because it further implies that it is catching a thrown exception, but would compromise to "trap" if that'll end the thread sooner. ;-) > What about making the context > manager provide the trapped exception, in a fashion similar to > what assertRaises does? Sadly, that won't work, since context managers provide a value *before* the block is executed, not after. ___ 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] Checking in Argument Clinic early?
> If this love-in continues I'll prep a release tonight and commit it in the > morning... just before my flight home across the Atlantic. You've got it backwards. You're supposed to release, then leave town for two weeks, not come home to field complaints. I think it might even be in the Zen of Python somewhere, if you read between the lines... :-) Skip ___ 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 8:57 AM, Nick Coghlan wrote: > So, having been convinced that "ignore" was the wrong choice of name, > reviewing the docs made it clear to me what the name *should* be. >From the point of view of code *outside* a block, the error is indeed suppressed. But, as one of those examples actually points out, what's happening from the POV *inside* the block is that the exception is "trapped". So using "suppress" creates an ambiguity: are we suppressing these errors *inside* the block, or *outside* the block? The way it actually works is errors are suppressed from the code *surrounding* the block, but the word can equally be interpreted as suppressing errors *inside* the block, in exactly the same way that "ignore" can be misread. So, if we're going with words that have precedent in the doc, the term "trap", as used here: > "If an exception is trapped merely in order to log it or to perform > some action (rather than to suppress it entirely), the generator must > reraise that exception." is the only one used to describe the POV from inside the block, where the error is... well, being trapped. ;-) It is a more apt description of what actually happens, even if it's only usable for the specific use case where an exception is trapped in order to suppress it. ___ 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] Checking in Argument Clinic early?
15.10.13 15:55, Larry Hastings написав(ла): So, quick poll: do you approve of me checking Argument Clinic in to Python 3.4 trunk in its current state before 3.4a4? Could you get us a week for preliminary review before checking? I remember I proposed a little different syntax and I don't know whether it was taken into account and how a syntax evolved. ___ 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] Checking in Argument Clinic early?
On Tue, Oct 15, 2013 at 5:55 AM, Larry Hastings wrote: > > > I really want to get Argument Clinic in to Python 3.4. Currently the > following is true: > >- It has an implementation I've been working on for more than a year. >- I assert that it's a reasonable approach and the APIs are ready for >public consumption. >- The syntax for the DSL is the one proposed by Guido at PyCon US 2013. > - So far It has little in the way of documentation apart from the PEP. >- The PEP is out of date and not ready for pronouncement. >- IIUC Guido said he's not delegating this PEP. > > I'm neutral here but just wanted to say that it amazes me that we simultaneously (1) run a centi-thread about some semantic trifles in exception handling, peppered with bikeshedding and emotions and (2) you plan to "just go ahead and commit" a large, significant feature for which: 1. The PEP is out of date and has not even been pronounced 2. The code only got "cursory review" 3. The code is not even in a state suitable for convenient review, as Antoine noted And all of that just because the 3.4 deadling is looming. This makes me somewhat sad about our process :-/ And the comparison to Tulip is completely irrelevant. Every single thing in Tulip is being heatedly discussed among multiple developers on the Tulip list for many months now, and all code gets reviewed. Eli > >- > > > There's now a discussion afoot about merging "tulip" in, in time for > 3.4a4, which I think is going to happen. And as Release Manager for 3.4 > I'm happy to see this happen. > > I'd like to propose much the same thing for Argument Clinic: check it in > now, before 3.4a4, and let it bake in trunk a little before feature freeze > at beta 1 while I run around and finish the documentation. > > > You can review the existing code here: > > https://bitbucket.org/larry/python-clinic/ > > (Yes, in this fork clinic.py is at the root--but then I never intended to > merge this fork.) > > Checking in Clinic would mean: > >- Adding the tool (one file, "clinic.py") and its test suite into >Tools/clinic/ >- Adding its documentation somewhere in the Doc/ directory > - Merging six or eight places where I've converted random functions >to use Clinic > > Brett Cannon gave the code a cursory review at PyCon CA over about six > hours, and iirc he said it was basically reasonable. He wanted more > coverage in the tests, and more in-depth review of course, but he had only > minor feedback, all of which I've incorporated. > > (In case you're wondering: last time I tried, coverage from just the unit > test suite was about 85%, but if you also ran all my sample usage of it in > the CPython code it rose to like 92%.) > > > So, quick poll: do you approve of me checking Argument Clinic in to Python > 3.4 trunk in its current state before 3.4a4? > > > */arry* > > ___ > 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/eliben%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] Checking in Argument Clinic early?
On Tue, Oct 15, 2013 at 9:49 AM, Eli Bendersky wrote: > And all of that just because the 3.4 deadling is looming. This makes me > somewhat sad about our process :-/ > Well, almost any process occasionally needs some pepper in the butt, and there's nothing like a hard deadline to get people to take some action. So I think this is actually appropriate. > And the comparison to Tulip is completely irrelevant. Every single thing > in Tulip is being heatedly discussed among multiple developers on the Tulip > list for many months now, and all code gets reviewed. > That may be, but it's not completely irrelevant -- the push for getting Tulip checked in was motivated by exactly the same deadline. -- --Guido van Rossum (python.org/~guido) ___ 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 8:27 AM, Antoine Pitrou wrote: >> I've come to the conclusion it makes sense to rename it from ignore to >> suppress, since that's the term already used for this operation in the >> rest of the context management docs: http://bugs.python.org/issue19266 > > "suppress" and/or "trap" (which I believe is a common name for such > operation). +0 for s/ignore/suppress/ -1 for trap/catch or anything similar that would imply that with trap(Error) as e: ... would make any sense. ___ 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] Checking in Argument Clinic early?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2013 12:47 PM, Serhiy Storchaka wrote: > 15.10.13 15:55, Larry Hastings написав(ла): >> So, quick poll: do you approve of me checking Argument Clinic in to >> Python 3.4 trunk in its current state before 3.4a4? > > Could you get us a week for preliminary review before checking? I > remember I proposed a little different syntax and I don't know whether > it was taken into account and how a syntax evolved. The syntax compromise was actually hammered out during / after the Language Summit at PyCon US this year: Guido blessed the resulting spec. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJdd4sACgkQ+gerLs4ltQ4URgCfRqHMQ4ttE+k1p2w7gMGaCsQI JhoAn2rPnbApwcAbd2TZITzG2UinrK+R =KsLA -END PGP SIGNATURE- ___ 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] Checking in Argument Clinic early?
On Tue, 15 Oct 2013 15:20:34 +0100 Larry Hastings wrote: > If you want to struggle through it by hand, read clinic.py (obviously), > and then search for the string "clinic" in these files: > > Modules/_cursesmodule.c > Modules/_datetimemodule.c > Modules/_dbmmodule.c > Modules/posixmodule.c > Modules/unicodedata.c > Modules/_weakref.c > Modules/zlibmodule.c > Objects/dictobject.c > Objects/unicodeobject.c > > > Can you suggest how I could make it easier for you to review? I'd be > happy to make an issue for it, which I probably should do anyway (if > there isn't already one). hg di -r "" sounds like a good approach. > > Is clinic.py automatically invoked by the build chain? (i.e. Makefile) > > Not at the moment. I'm a neophyte when it comes to moderne > sophisticated Makefile munging. There's also a chicken-and-egg problem > there. Well, solving the chicken-and-egg problem is what would make the Makefile integration interesting :-) 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] Checking in Argument Clinic early?
On Tue, Oct 15, 2013 at 12:49 PM, Eli Bendersky wrote: > On Tue, Oct 15, 2013 at 5:55 AM, Larry Hastings wrote: > >> >> >> I really want to get Argument Clinic in to Python 3.4. Currently the >> following is true: >> >>- It has an implementation I've been working on for more than a year. >>- I assert that it's a reasonable approach and the APIs are ready for >>public consumption. >>- The syntax for the DSL is the one proposed by Guido at PyCon US >>2013. >> - So far It has little in the way of documentation apart from the >>PEP. >>- The PEP is out of date and not ready for pronouncement. >>- IIUC Guido said he's not delegating this PEP. >> >> > I'm neutral here but just wanted to say that it amazes me that we > simultaneously (1) run a centi-thread about some semantic trifles in > exception handling, peppered with bikeshedding and emotions and (2) you > plan to "just go ahead and commit" a large, significant feature for which: > > 1. The PEP is out of date and has not even been pronounced > Guido has essentially pronounced for a while, Larry just didn't bother to update the PEP based on agreements made in person. > 2. The code only got "cursory review" > Well, I stared at the code over a day and a half with Larry sitting next to me, going over almost all of it line-by-line. So it's cursory by me ignoring PEP 8 style violations, but it wasn't just a quick scroll-through. > 3. The code is not even in a state suitable for convenient review, as > Antoine noted > Beyond the tests and Argument Clinic script, only the output is not self-contained, so reviewing it against a checkout is more about how stuff shifts in the .c files which has already been blessed by Guido, not the main code that does the work. > > And all of that just because the 3.4 deadling is looming. This makes me > somewhat sad about our process :-/ > You also need to remember this is initially a tool for *us* and not the outside world, so brittleness found after release really isn't an issue as long as Python continues to compile. Since we are the users we are the ones using and iterating on it before final release, and so the sooner the better. This isn't a rush where we will have something possible half-baked until it sees public use; it's going to iterate quickly the day it's landed and we all can work towards getting it done for ourselves before 3.4 final is out. -Brett > > And the comparison to Tulip is completely irrelevant. Every single thing > in Tulip is being heatedly discussed among multiple developers on the Tulip > list for many months now, and all code gets reviewed. > > Eli > > > > > > > >> >>- >> >> >> There's now a discussion afoot about merging "tulip" in, in time for >> 3.4a4, which I think is going to happen. And as Release Manager for 3.4 >> I'm happy to see this happen. >> >> I'd like to propose much the same thing for Argument Clinic: check it in >> now, before 3.4a4, and let it bake in trunk a little before feature freeze >> at beta 1 while I run around and finish the documentation. >> >> >> You can review the existing code here: >> >> https://bitbucket.org/larry/python-clinic/ >> >> (Yes, in this fork clinic.py is at the root--but then I never intended to >> merge this fork.) >> >> Checking in Clinic would mean: >> >>- Adding the tool (one file, "clinic.py") and its test suite into >>Tools/clinic/ >>- Adding its documentation somewhere in the Doc/ directory >> - Merging six or eight places where I've converted random functions >>to use Clinic >> >> Brett Cannon gave the code a cursory review at PyCon CA over about six >> hours, and iirc he said it was basically reasonable. He wanted more >> coverage in the tests, and more in-depth review of course, but he had only >> minor feedback, all of which I've incorporated. >> >> (In case you're wondering: last time I tried, coverage from just the unit >> test suite was about 85%, but if you also ran all my sample usage of it in >> the CPython code it rose to like 92%.) >> >> >> So, quick poll: do you approve of me checking Argument Clinic in to >> Python 3.4 trunk in its current state before 3.4a4? >> >> >> */arry* >> >> ___ >> 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/eliben%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/brett%40python.org > > ___ 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/15/2013 09:28 AM, PJ Eby wrote:
On Tue, Oct 15, 2013 at 11:52 AM, R. David Murray wrote:
What about making the context manager provide the trapped exception,
in a fashion similar to what assertRaises does?
Sadly, that won't work, since context managers provide a value
*before* the block is executed, not after.
However, if the CM provides the value before, and the with block accepts it, it
can then have the exception added to it:
with trap(OSError) as cm:
os.unlink('missing.txt')
if cm.exc:
do_something()
--
~Ethan~
___
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 12:45 PM, Ethan Furman wrote:
> with trap(OSError) as cm:
> os.unlink('missing.txt')
> if cm.exc:
> do_something()
.. and why is this better than
try:
os.unlink('missing.txt')
except OSError as exc:
do_something()
?
___
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 09:45:59AM -0700, Ethan Furman wrote:
> [...] if the CM provides the value before, and the with block accepts
> it, it can then have the exception added to it:
>
> with trap(OSError) as cm:
> os.unlink('missing.txt')
> if cm.exc:
> do_something()
Is there some advantage to this over
try:
os.unlink('missing.txt')
except OSError as exc:
do_something()
I thought the whole point was to replace code that would otherwise
contain 'except: pass' with something slightly more concise. Once you
expose the exception, it becomes just an uglier version of a try/except
block, as far as I can see.
-[]z.
--
Zero Piraeus: pons asinorum
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/15/2013 9:28 AM, PJ Eby wrote: On Tue, Oct 15, 2013 at 11:52 AM, R. David Murray wrote: >I think 'trap' would be much clearer. +1. Short and sweet, and just ambiguous enough that you don't leap to the conclusion that the error is ignored. I agree that "suppress" is basically a synonym for "ignore"; trap at least*implies* some kind of control flow change, which is what's needed to prevent misconceptions. Yes, trap or catch imply a control flow change, ignore and suppress do not. ___ 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, 15 Oct 2013 15:02:15 -0300, Zero Piraeus wrote:
> :
>
> On Tue, Oct 15, 2013 at 09:45:59AM -0700, Ethan Furman wrote:
> > [...] if the CM provides the value before, and the with block accepts
> > it, it can then have the exception added to it:
> >
> > with trap(OSError) as cm:
> > os.unlink('missing.txt')
> > if cm.exc:
> > do_something()
>
> Is there some advantage to this over
>
> try:
> os.unlink('missing.txt')
> except OSError as exc:
> do_something()
>
> I thought the whole point was to replace code that would otherwise
> contain 'except: pass' with something slightly more concise. Once you
> expose the exception, it becomes just an uglier version of a try/except
> block, as far as I can see.
Obviously not :)
You wouldn't use trap/as for that. Instead you use it to replace this:
exc = None
try:
os.unlink('missing.txt')
except OSError as exc:
pass
some
other
code
if exc is not None:
do_something()
with:
with trap(OSError) as cm:
os.unlink('missing.txt')
some
other
code
if cm.exc is not None:
do_something()
which saves you *three* lines, not just two :)
Of course in real life, in order for 'some other code' really be the
best way to organize this snippet, you're going to be doing something
more complicated than catching OSError from an unlink call.
If this is accepted, I do *not* expect to see this in real code very
often at all. The main motivation for it is to make the semantics
of the context manager clearer, and as a bonus make it work like
assertRaises, which is our existing stdlib context manager that traps
exceptions.
I'd be happy with 'trap' or 'catch' without 'as' support, but the
names make more sense if the exception is actually available after
it is trapped/caught.
--David
___
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 16 October 2013 05:17, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> On Tue, Oct 15, 2013 at 12:45 PM, Ethan Furman wrote:
> > with trap(OSError) as cm:
> > os.unlink('missing.txt')
> > if cm.exc:
> > do_something()
>
> .. and why is this better than
>
> try:
>os.unlink('missing.txt')
> except OSError as exc:
>do_something()
It would allow you to perform a series of operations then process the any
exceptions all together e.g.
with trap(OSError) as cm1:
os.unlink('missing.txt')
with trap(OSError) as cm2:
os.unlink('other_missing.txt')
with trap(OSError) as cm3:
os.unlink('another_missing.txt')
for cm in (cm1, cm2, cm3):
if cm.exc:
do_something(cm.exc)
An equivalent implementation would be:
exceptions = []
try:
os.unlink('missing.txt')
except OSError as exc:
exceptions.append(exc)
try:
os.unlink('missing.txt')
except OSError as exc:
exceptions.append(exc)
try:
os.unlink('missing.txt')
except OSError as exc:
exceptions.append(exc)
for exc in exceptions:
if exc:
do_something(exc)
Tim Delaney
___
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().
Zero Piraeus wrote: I thought the whole point was to replace code that would otherwise contain 'except: pass' with something slightly more concise. Hmmm, that suggests another potential name. with passing_on(OSError): os.remove(somefile) -- Greg ___ 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] Submitting PEP 453 (pip bootstrapping) for pronouncement
On 14 Oct 2013 08:21, "Nick Coghlan" wrote: > > > On 14 Oct 2013 04:26, "Paul Moore" wrote: > > > > On 13 October 2013 13:43, Nick Coghlan wrote: > > > Accordingly, in addition to adding the option to extract and install ``pip`` > > > during installation, this PEP proposes that the Windows installer (and > > > ``sysconfig``) in Python 3.4 and later be updated to: > > > > > > - install scripts to PythonXY\bin rather than PythonXY\Tools\Scripts > > > - add PythonXY\bin to the Windows PATH (in addition to PythonXY) when the > > > PATH modification option is enabled during installation > > > > Then implication of this is that venv (and virtualenv, but that's less > > relevant to python-dev) should be updated to use a "bin" directory on > > Windows rather than the current "Scripts" directory. This would only > > be for 3.4, which means that virtualenv will need to make the > > directory name conditional on version, I guess. > > The sysconfig directory scheme will change accordingly, so it may be possible to leverage that by basing the virtualenv layout on the default scheme. Paul figured out (over on distutils-sig) that there's almost certainly a compatibility issue with existing Windows installers for Python modules in changing the name of the third party scripts directory. Accordingly, I plan to change that part of the PEP to just refer to the appropriate sysconfig entry, and leave out the idea of changing that subdirectory name from Scripts to bin (while it's likely solvable, it's also completely orthogonal to the main purpose of the PEP). I also still have a couple of tweaks to make to the integration timeline that I added after discussion with the pip devs and the release team. So, once again, not quite ready for pronouncement after all... *sigh* Cheers, Nick. > > Cheers, > Nick. > > > > > Paul. ___ 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/15/2013 12:59 PM, Tim Delaney wrote:
On 16 October 2013 05:17, Alexander Belopolsky mailto:alexander.belopol...@gmail.com>>
wrote:
On Tue, Oct 15, 2013 at 12:45 PM, Ethan Furman mailto:et...@stoneleaf.us>> wrote:
> with trap(OSError) as cm:
> os.unlink('missing.txt')
> if cm.exc:
> do_something()
.. and why is this better than
try:
os.unlink('missing.txt')
except OSError as exc:
do_something()
It would allow you to perform a series of operations then process the any
exceptions all together e.g.
with trap(OSError) as cm1:
os.unlink('missing.txt')
with trap(OSError) as cm2:
os.unlink('other_missing.txt')
with trap(OSError) as cm3:
os.unlink('another_missing.txt')
for cm in (cm1, cm2, cm3):
if cm.exc:
do_something(cm.exc)
As long as we're having fun ;)
trap_os = suppress(OSError)
dead_files = ('missing.txt', 'other_missing.txt', 'actually_here.txt')
for file in dead_files:
with trap_os:
os.unlink(missing.txt)
for exc in trap_os.suppressed_exceptions:
do_something(exc)
--
~Ethan~
___
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 16 Oct 2013 01:54, "R. David Murray" wrote: > > On Tue, 15 Oct 2013 22:57:34 +1000, Nick Coghlan wrote: > > On 15 October 2013 22:27, Antoine Pitrou wrote: > > > Le Tue, 15 Oct 2013 22:05:41 +1000, > > > Nick Coghlan a écrit : > > > > > >> On 15 October 2013 13:12, Glenn Linderman > > >> wrote: > > >> > 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 come to the conclusion it makes sense to rename it from ignore to > > >> suppress, since that's the term already used for this operation in the > > >> rest of the context management docs: http://bugs.python.org/issue19266 > > > > > > "suppress" and/or "trap" (which I believe is a common name for such > > > operation). > > > > I chose the new name based on the terminology used in the existing > > docs (I'll grant that a lot of these docs were written by me at > > various points in time, but taken together they still create a solid > > precedent that "suppress" refers to discarding the exception, while > > "trap" just refers to catching it and then potentially doing something > > with it, including reraising it). > > > > From http://docs.python.org/dev/library/stdtypes.html#contextmanager.__exit__: > > > > "Exit the runtime context and return a Boolean flag indicating if any > > exception that occurred should be suppressed." > > > > "Returning a true value from this method will cause the with statement > > to suppress the exception and continue execution with the statement > > immediately following the with statement. " > > Someone could read this and reason by analogy: "so if the *context > manager* is named suppress, then execution will resume following the > statement where the exception was suppressed". They'd be wrong, of > course, I'm just pointing out some confusion that we might still see. > > > From http://docs.python.org/dev/reference/datamodel.html#object.__exit__ > > > > "If an exception is supplied, and the method wishes to suppress the > > exception (i.e., prevent it from being propagated), it should return a > > true value." > > > > From http://docs.python.org/dev/library/contextlib#contextlib.contextmanager > > > > "If an exception is trapped merely in order to log it or to perform > > some action (rather than to suppress it entirely), the generator must > > reraise that exception." > > > > From http://docs.python.org/dev/library/contextlib#contextlib.ignore (!) > > > > "As with any other mechanism that completely suppresses exceptions, it > > should only be used to cover very specific errors where silently > > ignoring the exception is known to be the right thing to do." > > This should emphasize that execution resumes with the statement following > the with block, and give that as a strong motivation for only using it > to cover the line where the exception is to be suppressed (and there are > likely to be very few cases where it would reasonable for it to be more > than one line, and that is probably worth pointing out). > > > From http://docs.python.org/dev/library/contextlib#contextlib.ExitStack > > > > "...if an inner callback suppresses or replaces an exception, then > > outer callbacks will be passed arguments based on that updated state." > > > > From http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.enter_context > > > > "These context managers may suppress exceptions just as they normally > > would if used directly as part of a with statement." > > > > From http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.push > > > > "By returning true values, these callbacks can suppress exceptions the > > same way context manager __exit__() methods can." > > > > From http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.callback > > > > "Unlike the other methods, callbacks added this way cannot suppress > > exceptions (as they are never passed the exception details)." > > > > So, having been convinced that "ignore" was the wrong choice of name, > > reviewing the docs made it clear to me what the name *should* be. > > I think 'trap' would be much clearer. What about making the context > manager provide the trapped exception, in a fashion similar to > what assertRaises does? Even if that was almost never used in practice, > the fact that the CM provides only *one* exception no matter how > many statements are in the with block would strongly reinforce the > actual semantics of the construct. It would also make it parallel to > assertRaises, which seems like a consistency bonus. > > And I could see it getting used. I think I've had code where the logic > was: possibly trap an exception, stuff it in a variable, do some logic, > check the variable to see if we had an exception earlier, and if so do > something with it or otherwise branch the logic. I won't say this is > common, and I won't say there wouldn't often be a better way to write > it...but I can think that it might have utility.
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Wed, Oct 16, 2013 at 09:24:11AM +1000, Nick Coghlan wrote: > Even though it eventually > convinced me to change the name, this thread still epitomises everything > that sucks about soul destroying, energy draining bikeshed painting that > makes me wonder why I ever bother trying to make anything better. I feel your pain, I truly do, but I think the name you ended up with is much better than "ignore(d)". Given that naming things is one of the two hard problems of computer science[1], I think that a bit of pain to get the name just right is worth it. (You did decide on "suppress", right? I must admit I've only skimmed this thread.) In any case, thank you for seeing this through. [1] The other is cache invalidation. -- Steven ___ 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 Wed, 16 Oct 2013 09:24:11 +1000, Nick Coghlan wrote: > On 16 Oct 2013 01:54, "R. David Murray" wrote: > > With that change, I'd be +1. With just suppress, I'm -0. > > Please, please, please just let it drop. Even though it eventually > convinced me to change the name, this thread still epitomises everything > that sucks about soul destroying, energy draining bikeshed painting that > makes me wonder why I ever bother trying to make anything better. I've already said that I was fine with whatever you decide (even if it was to keep ignore). I did think trap/as was a good suggestion, but if you don't like it, you don't like it. --David ___ 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 16 Oct 2013 11:42, "R. David Murray" wrote: > > On Wed, 16 Oct 2013 09:24:11 +1000, Nick Coghlan wrote: > > On 16 Oct 2013 01:54, "R. David Murray" wrote: > > > With that change, I'd be +1. With just suppress, I'm -0. > > > > Please, please, please just let it drop. Even though it eventually > > convinced me to change the name, this thread still epitomises everything > > that sucks about soul destroying, energy draining bikeshed painting that > > makes me wonder why I ever bother trying to make anything better. > > I've already said that I was fine with whatever you decide (even if it > was to keep ignore). I did think trap/as was a good suggestion, but if > you don't like it, you don't like it. Thank you for that :) Cheers, Nick. > > --David > ___ > 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
