Or perhaps call it "contextlib.ignore_first(Exception)"?
Mark Favas
iVEC@CSIRO Director
A/Director, Technical Operations, iVEC
Advanced Scientific Computing
CSIRO IM&T
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/l
First, thanks for the education. What you wrote is extremely edifying
about more than just context managers, and I really appreciate the
visionary understanding you reported from BrisPy and further elucidated
on, regarding the educational pattern of using things before you learn
how they work..
On 10/17/2013 08:26 AM, Nick Coghlan wrote:
# Arbitrarily nested search loop
with exit_label() as found:
for i in range(x):
for j in range(y):
if matches(i, j):
found.exit((i, j))
if found:
print(found.value)
+
On 17 October 2013 01:24, 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'
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
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 w
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
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 decis
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/
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
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
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
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.
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
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 mis
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
> >
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
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 o
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.u
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 not
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?
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 (CE
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 th
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
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
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 epito
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 anythin
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
> > >> wr
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'
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
__
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
>
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:
> >
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
:
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()
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()
?
_
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
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
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
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* s
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 *
:
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
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,
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 term
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
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
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
___
Pytho
On 10/14/2013 5:18 PM, Nick Coghlan wrote:
What the new CM *doesn't* handle nicely is multi-statement suites, and
I'm OK with that.
Yeah, that is the dubious part.
You can't even convince python-dev that saving 2 lines to ignore an
exception in one line of code is a good idea, at the cost of
On 10/14/2013 06:04 PM, Zero Piraeus wrote:
:
On Tue, Oct 15, 2013 at 10:18:56AM +1000, Nick Coghlan wrote:
I didn't articulate the point very well. The reason I originally
approved the change (and the reason I have kept it despite the
objections raised) is because it allows correct-but-ugly co
:
On Tue, Oct 15, 2013 at 10:18:56AM +1000, Nick Coghlan wrote:
> I didn't articulate the point very well. The reason I originally
> approved the change (and the reason I have kept it despite the
> objections raised) is because it allows correct-but-ugly code like:
>
> try:
> os.unlin
On Mon, Oct 14, 2013 at 8:18 PM, Nick Coghlan wrote:
> .. especially by people that expect it to work like VB's "on error resume
> next"
> rather than by suppressing the exception and resuming execution after the
> with statement.
"It is practically impossible to teach good programming to studen
On 14 Oct 2013 09:28, "Glenn Linderman" wrote:
>
> On 10/12/2013 11:57 PM, Nick Coghlan wrote:
>>
>> For the record, this thread did prompt me to consider the new construct
anew, but on reflection, I still consider it a reasonable addition to
contextlib.
>>
>> It substantially improves the simple
On 15 Oct 2013 08:54, "Barry Warsaw" wrote:
>
> On Oct 12, 2013, at 03:27 PM, Raymond Hettinger wrote:
>
> >The module maintainer (Nick) approved the name change from his original
> >preference for ignored(). That should had been the end of it.
>
> As a general plea, please be sure to record the
On Oct 12, 2013, at 03:27 PM, Raymond Hettinger wrote:
>The module maintainer (Nick) approved the name change from his original
>preference for ignored(). That should had been the end of it.
As a general plea, please be sure to record the rationale and decisions in the
appropriate place, such as
On 10/12/2013 11:57 PM, Nick Coghlan wrote:
For the record, this thread did prompt me to consider the new
construct anew, but on reflection, I still consider it a reasonable
addition to contextlib.
It substantially improves the simple cases it is intended to help
with, and, if anything, mak
On 14 Oct 2013 01:45, "Antoine Pitrou" wrote:
>
> On Mon, 14 Oct 2013 01:20:30 +1000
> Nick Coghlan wrote:
> >
> > Then, yes, I think challenging people to try to get me booted as
> > module maintainer for contextlib is a *precisely* proportionate
> > response.
>
> Because I don't agree with you
On Sun, Oct 13, 2013 at 1:58 PM, Alexander Belopolsky
wrote:
> People who write code using contextlib
> are expected to know
People who *read* that code while learning Python cannot be expected
to know that it is not really possible to ignore errors in Python.
If this feature is used under any n
On Sun, Oct 13, 2013 at 2:09 PM, R. David Murray wrote:
> with replaces try/finally, not try/except.
with ignore(..) is different. This is one of the things that I like
about it - a demonstration of a context manager that replaces
try/except.
___
Pytho
On Sun, 13 Oct 2013 13:58:56 -0400, Alexander Belopolsky
wrote:
> The feature (*and* its name) is a fine solution for the problem that
> it solves and is an improvement over status quo.
>
> I find
>
> with ignore(OSError):
> os.unlink(path)
>
> much easier to read than
>
> try:
>os.u
On Sun, Oct 13, 2013 at 1:01 PM, R. David Murray wrote:
> But the name hurts my brain
I did not think I would weigh in on this because Ramond's and Nick's
position seemed quite rational and the issue minor, but surprisingly
this thread does not seem to end.
The feature (*and* its name) is a fine
+1 to the below.
I don't have a strong opinion about the feature itself. The number of
times I can imagine using it in code is pretty close to zero, but
might not actually turn out to *be* zero, you never know.
But the name hurts my brain for the reasons PJ explains :)
--David
PS: I think you
On Sun, Oct 13, 2013 at 10:05 AM, Antoine Pitrou wrote:
> And for the record, it's not *my* objection; several other core
> developers have said -1 too: Ezio, Serhiy, Giampaolo, etc.
FWIW, I'm -1 also; the thread quickly convinced me that this is a
horrible idea, at least with the current name.
On Mon, 14 Oct 2013 01:20:30 +1000
Nick Coghlan wrote:
>
> Then, yes, I think challenging people to try to get me booted as
> module maintainer for contextlib is a *precisely* proportionate
> response.
Because I don't agree with you on one instance doesn't mean I usually
*distrust* your judgemen
On 14 October 2013 00:05, Antoine Pitrou wrote:
> On Sun, 13 Oct 2013 22:50:07 +1000
> Nick Coghlan wrote:
>> That's the way this works (unless you think this is such a disastrous
>> addition that you want to appeal to Guido to strip me of my
>> responsibilities as contextlib maintainer and go hu
On 14 October 2013 01:05, Victor Stinner wrote:
> 2013/10/13 Ethan Furman :
>> True, but Raymond's example of
>>
>> with ignore(OSError):
>> os.remove('somefile')
>
> And what about:
>
> with ignore(OSError):
> os.remove('file1')
> os.remove('file2')
It's just as broken as the try
2013/10/13 Ethan Furman :
> True, but Raymond's example of
>
> with ignore(OSError):
> os.remove('somefile')
And what about:
with ignore(OSError):
os.remove('file1')
os.remove('file2')
?
Victor
___
Python-Dev mailing list
Python-Dev@py
On 10/13/2013 05:34 AM, Antoine Pitrou wrote:
On Sun, 13 Oct 2013 16:57:09 +1000
Nick Coghlan wrote:
For the record, this thread did prompt me to consider the new construct
anew, but on reflection, I still consider it a reasonable addition to
contextlib.
It substantially improves the simple c
2013/10/13 Antoine Pitrou :
> On Sun, 13 Oct 2013 22:50:07 +1000
> Nick Coghlan wrote:
>> That's the way this works (unless you think this is such a disastrous
>> addition that you want to appeal to Guido to strip me of my
>> responsibilities as contextlib maintainer and go hunting for a new
>> on
13.10.13 15:50, Nick Coghlan написав(ла):
On 13 October 2013 22:34, Antoine Pitrou wrote:
There's actually more typing involved, and one more API to know about...
It is just another case of those "one-liners" that we generally refrain
from adding to the stdlib.
It meets my threshold for inclu
On Sun, 13 Oct 2013 16:05:40 +0200
Antoine Pitrou wrote:
> On Sun, 13 Oct 2013 22:50:07 +1000
> Nick Coghlan wrote:
> > That's the way this works (unless you think this is such a disastrous
> > addition that you want to appeal to Guido to strip me of my
> > responsibilities as contextlib maintain
On Sun, 13 Oct 2013 22:50:07 +1000
Nick Coghlan wrote:
> That's the way this works (unless you think this is such a disastrous
> addition that you want to appeal to Guido to strip me of my
> responsibilities as contextlib maintainer and go hunting for a new
> one).
Wow... I don't think challengin
On 13 October 2013 22:34, Antoine Pitrou wrote:
> On Sun, 13 Oct 2013 16:57:09 +1000
> Nick Coghlan wrote:
>>
>> For the record, this thread did prompt me to consider the new construct
>> anew, but on reflection, I still consider it a reasonable addition to
>> contextlib.
>>
>> It substantially i
On Sun, 13 Oct 2013 16:57:09 +1000
Nick Coghlan wrote:
>
> For the record, this thread did prompt me to consider the new construct
> anew, but on reflection, I still consider it a reasonable addition to
> contextlib.
>
> It substantially improves the simple cases it is intended to help with,
> a
On 13 Oct 2013 16:37, "Stephen J. Turnbull" wrote:
>
> Cameron Simpson writes:
>
> > But we've got "ignore" in play already. Can't we accept that it is
> > somewhat evocative though clearly not perfect for everyone, and
> > move on?
>
> No, that is *way* out. We can overrule the objections, re
Cameron Simpson writes:
> But we've got "ignore" in play already. Can't we accept that it is
> somewhat evocative though clearly not perfect for everyone, and
> move on?
No, that is *way* out. We can overrule the objections, recognizing
that sometimes compromise is the worst of the four possi
On 12Oct2013 15:27, Raymond Hettinger wrote:
> On Oct 12, 2013, at 1:41 PM, Ethan Furman wrote:
> . break_on reads just fine to me, although leave_on is probably better.
>
> Sorry, these are both really bad.
I agree.
> I've user tested ignore() and had good results.
> It makes the intenti
Cameron Simpson wrote:
>> >polysemic: having more than one meaning; having multiple meanings
>>
>> IMHO a poor word to use. I'm a middle aged Brit who's never heard
>> of it so people who have English as a second language have little or
>> no chance :(
>
> IMO a fine word. New to me, but perfec
On 10/12/2013 06:50 PM, Raymond Hettinger wrote:
On Oct 12, 2013, at 4:30 PM, Ethan Furman wrote:
Were you only displaying the same short form above?
Yes. The specific example given was:
with ignore(OSError):
os.remove(somefile)
That is certainly nicer than the multi-line
On Oct 12, 2013, at 4:30 PM, Ethan Furman wrote:
>>
>> When you ask someone to describe what
>> "try: f() except SomeException: pass" does,
>> they will say that it ignores the exception.
>
> And they would be right in that case.
>
>
>> FWIW, I presented this to 2500+ people in the keynote
>
On 11Oct2013 13:51, Mark Lawrence wrote:
> On 11/10/2013 11:33, Eric V. Smith wrote:
> >And Antoine has again taught me a new word:
> >polysemic: having more than one meaning; having multiple meanings
>
> IMHO a poor word to use. I'm a middle aged Brit who's never heard
> of it so people who hav
On 10/12/2013 03:27 PM, Raymond Hettinger wrote:
When you ask someone to describe what
"try: f() except SomeException: pass" does,
they will say that it ignores the exception.
And they would be right in that case.
FWIW, I presented this to 2500+ people in the keynote
at the 2013 U.S. Pycon
On 10/12/2013 6:27 PM, Raymond Hettinger wrote:
On Oct 12, 2013, at 1:41 PM, Ethan Furman mailto:et...@stoneleaf.us>> wrote:
. break_on reads just fine to me, although leave_on is probably better.
Sorry, these are both really bad.
I've user tested ignore() and had good results.
It makes th
On Oct 12, 2013, at 1:41 PM, Ethan Furman wrote:
> . break_on reads just fine to me, although leave_on is probably better.
Sorry, these are both really bad.
I've user tested ignore() and had good results.
It makes the intention of the code very clear.
When you ask someone to describe what
"t
On 10/11/2013 09:05 PM, Ethan Furman wrote:
On 10/11/2013 07:47 PM, Stephen J. Turnbull wrote:
Nick Coghlan writes:
> (RDM is also right that the exception still has the effect of
> terminating the block early, but I view names as mnemonics rather
> than necessarily 100% accurate descript
On 12/10/2013 05:05, Ethan Furman wrote:
On 10/11/2013 07:47 PM, Stephen J. Turnbull wrote:
Nick Coghlan writes:
> (RDM is also right that the exception still has the effect of
> terminating the block early, but I view names as mnemonics rather
> than necessarily 100% accurate description
On 10/11/2013 12:09 PM, Zero Piraeus wrote:
with blithe_disdain_concerning(...):
+1 :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
On 10/11/2013 07:47 PM, Stephen J. Turnbull wrote:
Nick Coghlan writes:
> (RDM is also right that the exception still has the effect of
> terminating the block early, but I view names as mnemonics rather
> than necessarily 100% accurate descriptions of things).
This is just way too ambigu
Nick Coghlan writes:
> (RDM is also right that the exception still has the effect of
> terminating the block early, but I view names as mnemonics rather
> than necessarily 100% accurate descriptions of things).
This is just way too ambiguous for my taste. I can't help reading
with contex
On Oct 12, 2013, at 09:06 AM, Nick Coghlan wrote:
>I'm not too fussy about the name (clearly). We originally picked ignored(),
>Raymond asked if he could change it to ignore() (and I said yes),
Just as a point of order, it would be good to capture such side-channel
discussions in the relevant iss
On 12 Oct 2013 03:58, "R. David Murray" wrote:
>
> On Fri, 11 Oct 2013 20:32:45 +0300, Serhiy Storchaka
wrote:
> > 11.10.13 10:24, Antoine Pitrou написав(ла):
> > > Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my
> > > -1 too. This is a useless addition (the traditional idio
On Fri, 11 Oct 2013 16:09:56 -0300, Zero Piraeus wrote:
> :
>
> On Fri, Oct 11, 2013 at 08:01:07PM +0100, MRAB wrote:
> > On 11/10/2013 19:41, Glenn Linderman wrote:
> > >Insistence on using "with" for the anti-pattern, and proper English,
> > >would require:
> > >
> > >with ignorance_of(FileNotF
:
On Fri, Oct 11, 2013 at 08:01:07PM +0100, MRAB wrote:
> On 11/10/2013 19:41, Glenn Linderman wrote:
> >Insistence on using "with" for the anti-pattern, and proper English,
> >would require:
> >
> >with ignorance_of(FileNotFoundError)
> >
> "Ignorance" means not knowing, but we _do_ know about Fi
On Fri, Oct 11, 2013 at 11:41 AM, Glenn Linderman wrote:
> On 10/11/2013 10:19 AM, Eric V. Smith wrote:
>
> On 10/11/2013 12:43 PM, Barry Warsaw wrote:
>
> On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote:
>
>
> Maybe to fit in with other verb-like APIs used as context managers:
> it's open() n
On 10/11/2013 12:00 PM, MRAB wrote:
On 11/10/2013 18:39, Ethan Furman wrote:
On 10/11/2013 09:43 AM, Barry Warsaw wrote:
On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote:
Maybe to fit in with other verb-like APIs used as context managers:
it's open() not opened().
open() predates context ma
On 10/11/2013 8:04 AM, Serhiy Storchaka wrote:
11.10.13 13:33, Eric V. Smith написав(ла):
And Antoine has again taught me a new word:
polysemic: having more than one meaning; having multiple meanings
There is no such word in my dictionaries. :( Only polysemous and
polysemantic.
http://www.me
On Fri, 11 Oct 2013 20:01:07 +0100, MRAB wrote:
> On 11/10/2013 19:41, Glenn Linderman wrote:
> > On 10/11/2013 10:19 AM, Eric V. Smith wrote:
> >> On 10/11/2013 12:43 PM, Barry Warsaw wrote:
> >>> On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote:
> >>>
> Maybe to fit in with other verb-like
On 11/10/2013 19:41, Glenn Linderman wrote:
On 10/11/2013 10:19 AM, Eric V. Smith wrote:
On 10/11/2013 12:43 PM, Barry Warsaw wrote:
On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote:
Maybe to fit in with other verb-like APIs used as context managers:
it's open() not opened().
open() predates
On 11/10/2013 18:39, Ethan Furman wrote:
On 10/11/2013 09:43 AM, Barry Warsaw wrote:
On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote:
Maybe to fit in with other verb-like APIs used as context managers:
it's open() not opened().
open() predates context managers, but maybe we need a new conve
11.10.13 21:41, Glenn Linderman написав(ла):
Seriously, "with" is the wrong spelling for this using. It should be
while ignorning(FileNotFoundError)
We need extended bool for while condition:
http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx
__
On 10/11/2013 10:19 AM, Eric V. Smith wrote:
On 10/11/2013 12:43 PM, Barry Warsaw wrote:
On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote:
Maybe to fit in with other verb-like APIs used as context managers:
it's open() not opened().
open() predates context managers, but maybe we need a new co
Am 11.10.2013 19:24, schrieb Barry Warsaw:
> On Oct 11, 2013, at 01:19 PM, Eric V. Smith wrote:
>
>>But, to continue to paint the shed, shouldn't it be "ignoring", to match
>>"closing"?
>
> Maybe so.
Would at least be consistent since both actions (close/ignore) are done at
the end of the execut
1 - 100 of 121 matches
Mail list logo
