I messed up my answer and replied to one person instead of the list, so
I'll post it again.
There is also an alternative to this operator, and it's allowing a
shortcut to do:
try:
val = do_thing()
except ThingError:
val = "default"
In the form of:
val = do_thing() except ThingError: "de
On 09/12/2016 12:05 AM, Michel Desmoulin wrote:
There is also an alternative to this operator, and it's allowing a
shortcut to do:
try:
val = do_thing()
except ThingError:
val = "default"
In the form of:
val = do_thing() except ThingError: "default"
I was debated, and rejected, but
On 12 September 2016 at 09:05, Michel Desmoulin
wrote:
> In the form of:
>
> val = do_thing() except ThingError: "default"
>
> [...]
>
> But it also can deal with many common operations in Python without the
> need to add more operators or variants:
>
> val = my_list[0] except IndexError: "defau
Ok, I guess it's time to end this thread. Thank you all for your answers
and the constructive discussion.
Best,
Dominik
On 12.09.2016 08:25, Nick Coghlan wrote:
On 11 September 2016 at 19:36, Dominik Gresch wrote:
Hi,
I've recently found myself writing code similar to this:
for i in range(
On 12/09/2016 08:05, Michel Desmoulin wrote:
I messed up my answer and replied to one person instead of the list, so
I'll post it again.
There is also an alternative to this operator, and it's allowing a
shortcut to do:
try:
val = do_thing()
except ThingError:
val = "default"
In th
On Mon, Sep 12, 2016, at 06:01, Ivan Levkivskyi wrote:
> I like this idea, I would propose a (maybe crazy) addition to it. What
> about a special exception NoneError, that will catch TypeError,
> AttributeError etc. but only when it was caused by None(),
> None.attr, None[1], etc. With this one ca
On 12/09/2016 11:01, Ivan Levkivskyi wrote:
On 12 September 2016 at 09:05, Michel Desmoulin
mailto:[email protected]>> wrote:
In the form of:
val = do_thing() except ThingError: "default"
[...]
But it also can deal with many common operations in Python without the
On Tue, Sep 13, 2016 at 12:03 AM, Rob Cliffe wrote:
> Assuming you can't break existing code that already traps TypeError,
> AttributeError, etc., I don't see how you can do this without
> having separated kinds of NoneError which were subclasses of TypeError,
> AttributeError, etc.
class NoneErr
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
On Mon, Sep 12, 2016 at 7:09 AM, Chris Angelico wrote:
> On Tue, Sep 13, 2016 at 12:03 AM, Rob Cliffe
> wrote:
>> Assuming you can't break existing code that already
On Sun, Sep 11, 2016 at 11:54 PM, Andrew Svetlov
wrote:
> Should Task.current_task() be declared as a part of supported public API?
Sure.
> Should we declare that every asyncio coroutine is executed in a task
> context?
What importance does this have? Task.get_current_task() can return None.
-
On Mon, Sep 12, 2016 at 1:05 AM, Michel Desmoulin
wrote:
> There is also an alternative to this operator, and it's allowing a
> shortcut to do:
>
> try:
> val = do_thing()
> except ThingError:
> val = "default"
>
> In the form of:
>
> val = do_thing() except ThingError: "default"
Note tha
On 12 September 2016 at 21:47, Eric Snow wrote:
> Note that there's a subtle difference here when multiple lookups are
> involved. Given:
>
> def f(spam):
> return spam().eggs().ham
>
> With null-coalescing:
>
> def f(spam):
> return spam()?.eggs()?.ham
>
> This is roughly
On 09/12/2016 02:13 PM, Paul Moore wrote:
On 12 September 2016 at 21:47, Eric Snow wrote:
Note that there's a subtle difference here when multiple lookups are
involved. Given:
def f(spam):
return spam().eggs().ham
With null-coalescing:
def f(spam):
return spam()
On Mon, Sep 12, 2016 at 3:13 PM, Paul Moore wrote:
> From previous explanations in this thread, that's *not* the behaviour at all.
Gah, you're right. I knew better too. The diversion back to PEP 463
crossed some wires in my brain. :)
>
> If I understand the proposal, f is actually intended to
I'm curious why it's important to update the PEP? I would think the docs
should be the official source of truth about the library, and the PEP
should be a record of the decisions that lead to the library. Trying to
keep both in sync just seems like extra work. Why not put a notice at
the top of t
On Mon, Sep 12, 2016 at 3:05 PM, Ned Batchelder
wrote:
> Why not put a notice at
> the top of the PEP indicating that it was accurate when it was accepted,
> but that changed have happened since then, see the docs for details?
>
I see PEP as the design document and docs as user-friendly document
Part of it is that the official docs often aren't all that precise
compared to the PEP. Part of it is that the PEP is still marked
provisional, and we wish to declare it final as of 3.6.0 (or as of
3.6b1, depending on who you talk to). So I'd like to see the "final"
version correspond with the API
On 12/09/2016 16:37, Guido van Rossum wrote:
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
Can you please clarify what you are saying in the last sentence?
The first time I read it, my brain parsed it as "People
On 09/12/2016 08:37 AM, Guido van Rossum wrote:
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
I certainly agree with the first part, slightly reworded: we should strive to
generate fewer exceptions that we have
On 13/09/2016 01:45, Rob Cliffe wrote:
On 12/09/2016 16:37, Guido van Rossum wrote:
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
Can you please clarify what you are saying in the last sentence?
The first tim
[Elliot Gorokhovsky ]
> Wow, Tim himself!
And Elliot himself! It's a party :-)
> Regarding performance on semi-ordered data: we'll have to
> benchmark to see, but intuitively I imagine radix would meet Timsort
> because verifying that a list of strings is sorted takes Omega(nw)
> (which gives a
On Mon, Sep 12, 2016 at 5:45 PM, Rob Cliffe wrote:
>
>
> On 12/09/2016 16:37, Guido van Rossum wrote:
>>
>> For the record, I still really don't like PEP 463. We should strive to
>> catch fewer exceptions, not make it easier to catch them.
>
> Can you please clarify what you are saying in the last
22 matches
Mail list logo
