Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 15, 2013, at 4:24 PM, Nick Coghlan wrote: > 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. > FWIW, here's a little history: * Last year, one of my clients suggested this feature based on code his team had been using in production. * I thought it might be a good idea, so I scanned the standard library and some third-party modules to see how well it worked with existing examples of try/except/pass. * I posted the proposal to the tracker over a year ago (issue 15806) along with some examples from the standard library. I also posted an egrep search so that others could evaluate it on their own code. * Along the way, I did usability testing on some corporate Python programmers who were attending my intermediate and advance Python classes. The feedback was positive (expressive, readable, and concise). * In February, I presented ignore() in the keynote for the U.S. Pycon. Again, the feedback was positive. * After some refinements, the module maintainer (Nick) blessed it and the code was checked-in to the Python 3.4 codebase in early March. * This month, I made a minor name change from ignored() to ignore(). * The next day, Antoine launched this thread and everything hit the fan. As Nick said, this thread was just awful. I found it painful to read each day. Shoot from the hip comments were given greater weight than months of development. Neither Nick nor I were given an ounce of respect for the thought we put into this or for our long track record of good design. The python-dev mailing list is a complex (and sometimes dysfunctional) environment. I understand that everyone on the soccer field feels a need to step-in and kick the ball to affect the outcome, but this was too much. To each participant, it may not seem like bike-shedding, but there were almost a hundred emails in this thread just to kick around six lines of code that were checked-in seven months ago: @contextmanager def ignored(*exceptions): try: yield except exceptions: pass Raymond P.S. The name suppress() is not as good as ignore(), but I'm so burnt out on this thread that I just don't care anymore. ___ 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 Wed, 16 Oct 2013 00:07:16 -0700, Raymond Hettinger a écrit : > > As Nick said, this thread was just awful. I found it painful to read > each day. Shoot from the hip comments were given greater weight than > months of development. Neither Nick nor I were given an ounce of > respect for the thought we put into this or for our long track record > of good design. I think it would probably have been much less "awful" if the comments had been addressed from the start. I don't remember anyone being insulting to either you or Nick, just people questioning the decision to include this in the stdlib. You also can't expect people to know about any "user testing" you didn't mention having done. re "User testing": I thought we resisted including "convenient one-liners" in the stdlib - though in this case it's more of a two-liner replacement. I'm not really surprised that some people are spontaneously sympathetic to such additions, but that hasn't really been a criterion in the past, has it? re "Months of development": well... you've said it yourself, it's 6 lines of very simple code. Perhaps you're being *a little* hyperbolic? Both the concept and the implementation are so trivial that I can't imagine more than a couple days being spent on it, total. (real "months of development" get routinely ignored or rejected, for various good or bad reasons... It always hurts when it happens, but I don't think this one is a good instance of the case: for one, your code is still there). > The python-dev mailing list is a complex (and sometimes dysfunctional) > environment. I understand that everyone on the soccer field feels a > need to step-in and kick the ball to affect the outcome, but this was > too much. Well, I don't know about others, but I *personally* find python-dev quite functional. Core development is a team's work, and I think many of us expect it to involve of certain amount of listening to each other. 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] cpython: Rename contextlib.ignored() to contextlib.ignore().
CONGRATULATION! This thread reached 100 mails, it's now time to summarize it into a PEP. Is there a candidate to write it? If no PEP is written, the thread will never die and people will continue to feed it. Victor 2013/10/11 Antoine Pitrou : > > Hello, > > On Fri, 11 Oct 2013 07:39:48 +0200 (CEST) > raymond.hettinger wrote: >> http://hg.python.org/cpython/rev/f014b5f0773f >> changeset: 86209:f014b5f0773f >> user:Raymond Hettinger >> date:Thu Oct 10 22:39:39 2013 -0700 >> summary: >> Rename contextlib.ignored() to contextlib.ignore(). > > I don't think that this contextlib.ignore() thing has been discussed a > lot. > > Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my > -1 too. This is a useless addition (the traditional idiom is perfectly > obvious) and makes reading foreign code more tedious by adding > superfluous API calls. > > Please consider reverting. There is absolutely zero use case for this > that wasn't already solved by the traditional "except ...: pass" idiom. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%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().
2013/10/16 Raymond Hettinger : > FWIW, here's a little history: Thank you! It helped me to understand the story. > * In February, I presented ignore() in the keynote for the U.S. Pycon. > Again, the feedback was positive. I missed this edition of Pycon US. How did you feedback on the keynote? > To each participant, it may not seem like bike-shedding, but there > were almost a hundred emails in this thread just to kick around six lines > of code that were checked-in seven months ago: Sorry but you cannot summarize this thread to this only point (the name). Many other topics were discussed: * process: most votes were negative on the tracker, Nick didn't mention that he blesssed this function * surprising behaviour when the block contains more than 1 instruction * documentation issue * should we add new functions in Python just to remove 2 lines of code? * possibility of storing the catched exception * etc. If you disagree with the principle of discussing new features, you missed probably an important part of the Python community. The process is not perfect, don't hesisate to suggest enhancement :-) The discussion only started recently (after the function was added) because it started on python-dev which is more visible than the bug tracker. -- Antoine also asked me recently to revert a commit (new malloc API) because it was not discussed enough (so you are not the only one to be harassed by Antoine :-)). I tried to describe my choices on python-dev, but it was hard to follow the flow of emails, so I wrote a PEP (PEP 445). The PEP was quickly accepted, the code is back, BUT the API is now *much* better, and the PEP is a good documentation explaining all technicals choices. (There were many alternatives to the proposed API, the PEP now lists all of them.) I can now say that my first API was no well designed, and the PEP helped me to improve it. It is frustrating to have to revert a commit, it should not happen. My patch was available since many weeks (months), but Antoine was right: it was not discussed enough. I don't know yet how to get more review on the bug tracker, sometimes even emails to python-dev are not enough. It depends on the motivation and availability of each developer :-) 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().
I might agree with idea of contextlib.ignore() (I'm still opposed to
the idea), but I don't understand the purpose of adding a new syntax
doing exactly the same than try/except:
> with trap(OSError) as cm:
> os.unlink('missing.txt')
> if cm.exc:
> do_something()
Nobody noticed that this can be written:
try:
os.unlink('missing.txt')
except OSError as err:
# do something with err
?? What happened with the Zen Principle "There should be one-- and
preferably only one --obvious way to do it." I don't understand why I
would import contextlib and use a new context manager, whereas
try/except is already a builtin feature of Python.
By the way, what are the performances of contextlib.ignore()?
Exceptions can be slow in some cases. Adding something even slower
would not be a good idea.
Victor
2013/10/15 Tim Delaney :
> On 16 October 2013 05:17, Alexander Belopolsky
> 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/victor.stinner%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().
Le Wed, 16 Oct 2013 13:42:34 +0200,
Victor Stinner a écrit :
> I might agree with idea of contextlib.ignore() (I'm still opposed to
> the idea), but I don't understand the purpose of adding a new syntax
> doing exactly the same than try/except:
>
> > with trap(OSError) as cm:
> > os.unlink('missing.txt')
> > if cm.exc:
> > do_something()
>
> Nobody noticed that this can be written:
>
> try:
> os.unlink('missing.txt')
> except OSError as err:
> # do something with err
>
> ?? What happened with the Zen Principle "There should be one-- and
> preferably only one --obvious way to do it." I don't understand why I
> would import contextlib and use a new context manager, whereas
> try/except is already a builtin feature of Python.
>
> By the way, what are the performances of contextlib.ignore()?
> Exceptions can be slow in some cases. Adding something even slower
> would not be a good idea.
A "try" block which succeeds is fast. A context manager will always be
slower, especially when written in pure Python with a generator wrapped
in a contextlib.contextmanager.
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] cpython: Rename contextlib.ignored() to contextlib.ignore().
2013/10/16 Antoine Pitrou : >> By the way, what are the performances of contextlib.ignore()? >> Exceptions can be slow in some cases. Adding something even slower >> would not be a good idea. > > A "try" block which succeeds is fast. Ah yes, I never reminder this fact. I try to not care too much of micro-optimizations :-) > A context manager will always be > slower, especially when written in pure Python with a generator wrapped > in a contextlib.contextmanager. ignore() is much slower than try/except even if the block succeeds? 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().
Le Wed, 16 Oct 2013 14:01:37 +0200, Victor Stinner a écrit : > 2013/10/16 Antoine Pitrou : > >> By the way, what are the performances of contextlib.ignore()? > >> Exceptions can be slow in some cases. Adding something even slower > >> would not be a good idea. > > > > A "try" block which succeeds is fast. > > Ah yes, I never reminder this fact. I try to not care too much of > micro-optimizations :-) It's not so much a micro-optimization than the fact that pushing a block on the stack is very cheap. IIRC, what is expensive is: - creating the exception object with the associated traceback - matching the exception in the "exception SomeException" clause I don't have numbers, though :-) 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] cpython: Rename contextlib.ignored() to contextlib.ignore().
Le Wed, 16 Oct 2013 14:09:16 +0200, Antoine Pitrou a écrit : > Le Wed, 16 Oct 2013 14:01:37 +0200, > Victor Stinner a écrit : > > 2013/10/16 Antoine Pitrou : > > >> By the way, what are the performances of contextlib.ignore()? > > >> Exceptions can be slow in some cases. Adding something even > > >> slower would not be a good idea. > > > > > > A "try" block which succeeds is fast. > > > > Ah yes, I never reminder this fact. I try to not care too much of > > micro-optimizations :-) > > It's not so much a micro-optimization than the fact that pushing a > block on the stack is very cheap. > IIRC, what is expensive is: > - creating the exception object with the associated traceback > - matching the exception in the "exception SomeException" clause By the way, of course this must be kept in proportion. At worse the total cost is a couple of microseconds. Still, a simplistic micro-benchmark: $ ./python -m timeit "try: pass" "except Exception: pass" 1 loops, best of 3: 0.0164 usec per loop $ ./python -m timeit -s "from contextlib import ignore" "with ignore(Exception): pass" 10 loops, best of 3: 2.21 usec per loop 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] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 16, 2013 5:35 AM, "Victor Stinner" wrote: > > 2013/10/16 Raymond Hettinger : > > FWIW, here's a little history: > > Thank you! It helped me to understand the story. > > > * In February, I presented ignore() in the keynote for the U.S. Pycon. > > Again, the feedback was positive. > > I missed this edition of Pycon US. How did you feedback on the keynote? > > > To each participant, it may not seem like bike-shedding, but there > > were almost a hundred emails in this thread just to kick around six lines > > of code that were checked-in seven months ago: > > Sorry but you cannot summarize this thread to this only point (the > name). Many other topics were discussed: > > * process: most votes were negative on the tracker, Nick didn't > mention that he blesssed this function > * surprising behaviour when the block contains more than 1 instruction > * documentation issue > * should we add new functions in Python just to remove 2 lines of code? > * possibility of storing the catched exception > * etc. > > If you disagree with the principle of discussing new features, you > missed probably an important part of the Python community. The process > is not perfect, don't hesisate to suggest enhancement :-) > > The discussion only started recently (after the function was added) > because it started on python-dev which is more visible than the bug > tracker. > > -- > > Antoine also asked me recently to revert a commit (new malloc API) > because it was not discussed enough (so you are not the only one to be > harassed by Antoine :-)). I tried to describe my choices on > python-dev, but it was hard to follow the flow of emails, so I wrote a > PEP (PEP 445). The PEP was quickly accepted, the code is back, BUT the > API is now *much* better, and the PEP is a good documentation > explaining all technicals choices. (There were many alternatives to > the proposed API, the PEP now lists all of them.) I can now say that > my first API was no well designed, and the PEP helped me to improve > it. > > It is frustrating to have to revert a commit, it should not happen. My > patch was available since many weeks (months), but Antoine was right: > it was not discussed enough. I don't know yet how to get more review > on the bug tracker, sometimes even emails to python-dev are not > enough. It depends on the motivation and availability of each > developer :-) You make several good points, Victor. However, in this case the change is a new function and a small, innocuous one at that. That is not enough justification alone, as Antoine pointed out, but the module's maintainer made a decision on this. When a module's maintainer makes a decision on a relatively insignificant addition to the module, I'd expect little resistance or even comment (the original commit was months ago). That's why I'm surprised by the reaction to this change. It just seems like the whole thing is being blown way out of proportion to the detriment of other interesting problems. Sure, things could have been done differently. But in this case it's not that big a deal. -eric ___ 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/16/2013 12:07 AM, Raymond Hettinger wrote: On Oct 15, 2013, at 4:24 PM, Nick Coghlan wrote: 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 think each of us has had this experience. It can certainly be draining and disheartening, but keep in mind we all want the same thing: a beautiful language to work with. FWIW, here's a little history: * Last year, one of my clients suggested this feature based on code his team had been using in production. * I thought it might be a good idea, so I scanned the standard library and some third-party modules to see how well it worked with existing examples of try/except/pass. * I posted the proposal to the tracker over a year ago (issue 15806) along with some examples from the standard library. I also posted an egrep search so that others could evaluate it on their own code. These three steps show on the bug tracker * Along the way, I did usability testing on some corporate Python programmers who were attending my intermediate and advance Python classes. The feedback was positive (expressive, readable, and concise). This does not. * In February, I presented ignore() in the keynote for the U.S. Pycon. Again, the feedback was positive. This does not. * After some refinements, the module maintainer (Nick) blessed it True, but what you are leaving out is that most of the feedback from pydevs in that issue was negative. So to someone reading the issue, as I just did, it looks like: * Here's an idea * Here's examples * Not a good idea feedback * Not a good idea feedback * Here's a better way to write it * Not a good idea feedback * Committed and the code was checked-in to the Python 3.4 codebase in early March. * This month, I made a minor name change from ignored() to ignore(). * The next day, Antoine launched this thread and everything hit the fan. It would have been better if this thread had been launched back in March, but we all have busy lives and sometimes things get missed. As Nick said, this thread was just awful. I found it painful to read each day. Shoot from the hip comments were given greater weight than months of development. Again, items that did not show up in the bug tracker. Neither Nick nor I were given an ounce of respect for the thought we put into this or for our long track record of good design. Everybody makes mistakes. The python-dev mailing list is a complex (and sometimes dysfunctional) environment. I understand that everyone on the soccer field feels a need to step-in and kick the ball to affect the outcome, but this was too much. We'll have to agree to disagree on this point. I find pydev an invaluable resource for putting many eyes and many perspectives on code / issues / design questions. To each participant, it may not seem like bike-shedding, but there were almost a hundred emails in this thread just to kick around six lines of code that were checked-in seven months ago: Actually, it was to kick around one line of code, the most import one: def ignored(...): P.S. The name suppress() is not as good as ignore(), but I'm so burnt out on this thread that I just don't care anymore. I agree it doesn't read as well, but despite that I think suppress is better. 'ignore' would surely be misinterpreted many more times. -- ~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().
Victor Stinner a écrit :
> I might agree with idea of contextlib.ignore() (I'm still opposed to
> the idea), but I don't understand the purpose of adding a new syntax
> doing exactly the same than try/except:
>
> > with trap(OSError) as cm:
> > os.unlink('missing.txt')
> > if cm.exc:
> > do_something()
>
> Nobody noticed that this can be written:
>
> try:
> os.unlink('missing.txt')
> except OSError as err:
> # do something with err
>
> ?? What happened with the Zen Principle "There should be one-- and
> preferably only one --obvious way to do it." I don't understand why I
> would import contextlib and use a new context manager, whereas
> try/except is already a builtin feature of Python.
For the record, that was *not* my proposal. You'd be silly to replace
the try/except with the context manager in the above case. The case
where the CM would be useful would be if there were statements
in between the context manager and the 'if'.
And that *still* wasn't the proposal. My proposal was to provide the
exception on the CM so that the name 'trap' made sense, and so that
it was clear that only one exception was ever caught, and so that
the CM was parallel in functionality to the existing assertRaises
CM.
But none of this affects the code, because Nick isn't accepting the
proposal, and that's fine.
--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().
I would rewrite your examples using try/finally:
try:
try:
os.unlink('missing.txt')
finally:
some
other
code
except OSError as exc:
do_something()
It's differently than yours, because it catchs OSError on "some; other; code".
Sometimes, I write it differently by copying the cleanup code:
try:
os.unlink('missing.txt')
cleanup()
except OSError as exc:
cleanup()
do_something()
(Yeah, it's ugly to duplicate code.)
Victor
2013/10/15 R. David Murray :
> 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/victor.stinner%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 Oct 16, 2013, at 08:31 AM, Eric Snow wrote: >When a module's maintainer makes a decision on a relatively insignificant >addition to the module, I'd expect little resistance or even comment (the >original commit was months ago). That's why I'm surprised by the reaction >to this change. It just seems like the whole thing is being blown way out >of proportion to the detriment of other interesting problems. Sure, things >could have been done differently. But in this case it's not that big a >deal. Any project as big and diverse as Python needs a hierarchical structure of trust and responsibility. I see it *roughly* as core dev < module maintainer < release manager < bdfl delegate < bdfl. However, it's imperative to remain vigilantly transparent so that everyone understands the rationale and motivation behind a change, even if they disagree with it. Trust is extended upwards when this transparency is extended downloads. "'Cause I said so" only works at the top of the chain. ;) I posted my original question because the change seemed so random and arbitrary, and the commit message didn't enlighten me. -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] cpython: Rename contextlib.ignored() to contextlib.ignore().
Victor Stinner writes:
> the idea), but I don't understand the purpose of adding a new syntax
> doing exactly the same than try/except:
>
> > with trap(OSError) as cm:
> > os.unlink('missing.txt')
> > if cm.exc:
> > do_something()
>
> Nobody noticed that this can be written:
>
> try:
> os.unlink('missing.txt')
> except OSError as err:
> # do something with err
A couple of people did, and it was pointed out that "with trap ... if"
allows intervening statements that are *not* in the "with" suite,
while all of the statements between "try" and "except" must be part of
the "try" suite. The actual equivalent would be
try:
os.unlink('missing.txt')
except OSError as err:
pass
# unhandled statements may go here
if err:
# do something with err
This is really horrible.
> ?? What happened with the Zen Principle "There should be one-- and
> preferably only one --obvious way to do it."
AIUI, the justification for this feature goes something like this:
1. It is fast and effective to use a try ... except block to catch
and ignore an exception, but it's awkward and ugly, which may
deter people from catching those exceptions. This is much nicer.
2. The "attractive nuisance" argument against the nicer syntax is
probably a fallacy: cargo cult programmers benefit as much as
Raymond's students from the correct single-line-suite usage. On
the other hand, nicer syntax may make it easier to wean the cargo
cult programmers from multi-statement try suites, and there's
little evidence that the nicer syntax would actually encourage
them to use more multi-statement suites.
3. As for the *several* Zen principles this feature violates, we
really should encourage people to "do something appropriate" with
exceptions, instead of
try:
main()
except:
print("You REALLY SCREWED UP this time, didn't you!",
file=sys.stderr)
sys.exit(errors.PEBKAC)
but encouraging robust programming is hard: exception handling is
just plain awkward if you do it in any generality. We hope "with
ignore()" can help in one frequently encountered, easily
understood, use case.
___
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/16/2013 07:06 AM, Ethan Furman wrote: Actually, it was to kick around one line of code, the most import one: def ignored(...): s/import/important/ ___ 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 Wed, 16 Oct 2013 08:31:44 -0600, Eric Snow a écrit : > > You make several good points, Victor. However, in this case the > change is a new function and a small, innocuous one at that. That is > not enough justification alone, as Antoine pointed out, but the > module's maintainer made a decision on this. > > When a module's maintainer makes a decision on a relatively > insignificant addition to the module, I'd expect little resistance or > even comment (the original commit was months ago). Just FWIW, I had totally overlooked the original commit, otherwise I would have raised my concerns back then. 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] cpython: Rename contextlib.ignored() to contextlib.ignore().
Eric Snow writes: > That's why I'm surprised by the reaction to this change. It just > seems like the whole thing is being blown way out of proportion to > the detriment of other interesting problems. The feature itself a perfect bikeshedding pitfall. Everybody here understands the Zen, and this addition violates at least a half-dozen Zen principles. That's why the thread had more heads than the Hydra. In cases like this, I would recommend that the responsible maintainer (yeah, I know, sorry for "blaming the victim") just write "Thank you for your comment. I understand that you're thinking about , and I've thought again, but I still think this is good enough. This thread is over" -- and then *refuse to post again*. ___ 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] Making submodules available when importing top one
(all this using Python 3.4.0a3+) In the stdlib, I see that (as an example): >>> import os >>> os.path.abspath >>> os.path However, for other (newer) modules: >>> import urllib >>> urllib.requests.urlopen Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'requests' >>> import concurrent >>> concurrent.futures Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'futures' So, is there a reason to not expose the submodules in the top module? This should be fixed? Thanks! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista ___ 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] Making submodules available when importing top one
On Wed, Oct 16, 2013 at 01:26:11PM -0300, Facundo Batista wrote: > (all this using Python 3.4.0a3+) > > In the stdlib, I see that (as an example): > > >>> import os > >>> os.path.abspath > > >>> os.path > > > > However, for other (newer) modules: > > >>> import urllib > >>> urllib.requests.urlopen > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute 'requests' > >>> import concurrent > >>> concurrent.futures > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute 'futures' > > > So, is there a reason to not expose the submodules in the top module? > This should be fixed? I don't think it should be fixed. To expose submodules automatically top-level modules have to import them. In case one only needs a couple of submodules (and without lazy import) importing all of them would be a waste of time and memory. Module os.path is a special kind of module. On import os imports a platform-dependent module (posixpath, ntpath) and exposes it as os.path. 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] Making submodules available when importing top one
On Wed, Oct 16, 2013 at 9:26 AM, Facundo Batista wrote: > (all this using Python 3.4.0a3+) > > In the stdlib, I see that (as an example): > > >>> import os > >>> os.path.abspath > > >>> os.path > > > > However, for other (newer) modules: > > >>> import urllib > >>> urllib.requests.urlopen > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute 'requests' > >>> import concurrent > >>> concurrent.futures > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute 'futures' > > > So, is there a reason to not expose the submodules in the top module? > This should be fixed? > os.path is special. The behavior of other modules is intentional. In general it is not a good idea to automatically import all submodules when you import a top-level package; imaging what this would do if you have a large top-level package (maybe a namespace package) containing hundreds of modules. For specific top-level packages that want to provide all (or some) submodules upon import of just the top-level package, they should have the sub-imports in the top-level __init__.py. -- --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] Making submodules available when importing top one
On Wed, Oct 16, 2013 at 10:26 AM, Facundo Batista wrote: > (all this using Python 3.4.0a3+) > > In the stdlib, I see that (as an example): > import os os.path.abspath > os.path > > > > However, for other (newer) modules: > import urllib urllib.requests.urlopen > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute 'requests' import concurrent concurrent.futures > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute 'futures' > > > So, is there a reason to not expose the submodules in the top module? > This should be fixed? -1 When you import a submodule the parent is imported first, the submodule second, and the submodule is bound as an attribute of the parent. Then the parent is bound to the module where the import happened. This is always the case (and not particular to os.path). For example, let's suppose you have these two files (plus a spam package): import spam.eggs import ham import spam When you run "python -c 'import sausage'", here's what happens: 1. ham is loaded: a. spam is loaded and added to sys.modules. b. eggs is loaded (as "spam.eggs") and added to sys.modules (as "spam.eggs"). c. the "eggs" attribute of spam (spam.eggs) is bound to the module at sys.modules["spam.eggs"]. d. the "spam" attribute of the [currently loading] ham module (ham.spam) is bound to the module at sys.modules["spam"]. 2. sausage is loaded: a-c. (already done when ham was imported) d. the "spam" attribute of the [currently loading] sausage module (sausage.spam) is bound to the module at sys.modules["spam"]. So now you could use "spam.eggs." in sausage even though you did not import "spam.eggs" there. It just happens that during interpreter startup some module did "import os.path", so the submodule is still bound to os. If urllib.requests had been imported during startup (or in another module), then your example would have worked. Guido's response covers just about everything else I was going say. If you really need to auto-import submodules of modules you don't control, you can write your own importer to do it. The import system is pretty easily extended. In this case, however, I doubt that's warranted. -eric ___ 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, Oct 16, 2013 at 9:24 AM, Barry Warsaw wrote: > On Oct 16, 2013, at 08:31 AM, Eric Snow wrote: >>When a module's maintainer makes a decision on a relatively insignificant >>addition to the module, I'd expect little resistance or even comment (the >>original commit was months ago). That's why I'm surprised by the reaction >>to this change. It just seems like the whole thing is being blown way out >>of proportion to the detriment of other interesting problems. Sure, things >>could have been done differently. But in this case it's not that big a >>deal. > > Any project as big and diverse as Python needs a hierarchical structure of > trust and responsibility. I see it *roughly* as core dev < module maintainer > < release manager < bdfl delegate < bdfl. +1 > > However, it's imperative to remain vigilantly transparent so that everyone > understands the rationale and motivation behind a change, even if they > disagree with it. Trust is extended upwards when this transparency is > extended downloads. "'Cause I said so" only works at the top of the chain. ;) Good point. -eric > > I posted my original question because the change seemed so random and > arbitrary, and the commit message didn't enlighten me. > > -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
[Python-Dev] Regarding stdlib socket module, _fileobject.flush() method using ._rbufsize instead of ._wbufsize
Hello, Is there a reason why the stdlib socket module _fileobject.flush() method is using ._rbufsize instead of ._wbufsize at line 297 (Python 2.7.3), where it determines the buffer_size value to be used for _sock.sendall()? Does anybody know the history behind this? Based on what I read in the code, there appear to be four code paths possible setting the _rbufsize and _wbufsize when creating an _fileobject: 1. default, or negative, bufsize argument bufsize argument is set to the default_bufsize class attribute _rbufsize = bufsize _wbufsize = bufsize 2. bufsize = 0 _rbufsize = 1 _wbufsize = 0 3. bufsize = 1 _rbufsize = default_bufsize class attribute _wbufsize = 1 4. bufsize > 1 _rbufsize = _wbufsize = bufsize With that, write() and writelines() uses _wbufsize, as expected. Additionally, could flush's buffer_size local variable be determined just the same using: buffer_size = max(self._wbufsize, self.bufsize) Thanks for considering. -peter ___ 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 21:34, "Victor Stinner" wrote: > > 2013/10/16 Raymond Hettinger : > > FWIW, here's a little history: > > Thank you! It helped me to understand the story. > > > * In February, I presented ignore() in the keynote for the U.S. Pycon. > > Again, the feedback was positive. > > I missed this edition of Pycon US. How did you feedback on the keynote? > > > To each participant, it may not seem like bike-shedding, but there > > were almost a hundred emails in this thread just to kick around six lines > > of code that were checked-in seven months ago: > > Sorry but you cannot summarize this thread to this only point (the > name). Many other topics were discussed: > > * process: most votes were negative on the tracker, Nick didn't > mention that he blesssed this function > * surprising behaviour when the block contains more than 1 instruction > * documentation issue > * should we add new functions in Python just to remove 2 lines of code? > * possibility of storing the catched exception > * etc. > > If you disagree with the principle of discussing new features, you > missed probably an important part of the Python community. The process > is not perfect, don't hesisate to suggest enhancement :-) > > The discussion only started recently (after the function was added) > because it started on python-dev which is more visible than the bug > tracker. This thread was 99% people rehashing the original tracker issue where I approved the addition of contextlib.ignored. *That* was the main problem with this thread: people commenting without even bothering to read up on the original change. There were fortunately a couple of shining moments of signal (thank you PJE) amidst the tidal wave of noise, and that's what really persuaded me to more closely review the name and how it related to the terminology used elsewhere in the docs. Regards, Nick. > > -- > > Antoine also asked me recently to revert a commit (new malloc API) > because it was not discussed enough (so you are not the only one to be > harassed by Antoine :-)). I tried to describe my choices on > python-dev, but it was hard to follow the flow of emails, so I wrote a > PEP (PEP 445). The PEP was quickly accepted, the code is back, BUT the > API is now *much* better, and the PEP is a good documentation > explaining all technicals choices. (There were many alternatives to > the proposed API, the PEP now lists all of them.) I can now say that > my first API was no well designed, and the PEP helped me to improve > it. > > It is frustrating to have to revert a commit, it should not happen. My > patch was available since many weeks (months), but Antoine was right: > it was not discussed enough. I don't know yet how to get more review > on the bug tracker, sometimes even emails to python-dev are not > enough. It depends on the motivation and availability of each > developer :-) > > 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] Regarding stdlib socket module, _fileobject.flush() method using ._rbufsize instead of ._wbufsize
On 10/16/2013 5:01 PM, Peter Portante wrote: Hello, Is there a reason why the stdlib socket module _fileobject.flush() method is using ._rbufsize instead of ._wbufsize at line 297 (Python 2.7.3), where it determines the buffer_size value to be used for _sock.sendall()? Does anybody know the history behind this? Annotations and history show that line is from 61875, 2010-5-23, J P Calderone, Merged revisions 74426... I do not understand the message. -- Terry Jan Reedy ___ 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
