Ethan Furman wrote:
Why is this? Doesn't the exception have to be instantiated at some
point, even if just to print to stderr?
If it gets caught by an except clause without an else clause,
in theory there's no need to instantiate it.
However, Python doesn't currently seem to take advantage o
On Thu, May 31, 2018 at 11:03:56AM -0700, Brendan Barnwell wrote:
> What I don't understand is this: if we believe that, then why was
> comprehension-leaking EVER removed? Everything that I've seen
> advocating for this kind of leaking seems to me like it is much more
> logically consist
On 2018-05-31 05:53, Steven D'Aprano wrote:
Bottom line is, if you think it is okay that the following assignment to
x affects the local scope:
results = []
for a in seq:
# using "given" to avoid arguments about :=
y = (x given x = a)+1
results.append(y)
On Fri, Jun 1, 2018 at 12:52 AM, Antoine Pitrou wrote:
> On Thu, 31 May 2018 07:49:58 -0700
> Ethan Furman wrote:
>> On 05/31/2018 07:36 AM, Nick Coghlan wrote:
>>
>> > The exception machinery deliberately attempts to avoid instantiating
>> > exception objects whenever it can, but that gets
>> >
On Thu, May 31, 2018 at 10:37 AM Nick Coghlan wrote:
>
> The exception machinery deliberately attempts to avoid instantiating
exception objects whenever it can, but that gets significantly more
difficult if we always need to create the instance before we can decide
whether or not the raised except
On Wed, May 30, 2018 at 10:47 PM, Danilo J. S. Bellini
wrote:
try:
> ... # [...]
> ... session.commit() # Here it raises!
> ... # [...]
> ... except DatabaseError as exc:
> ... msg = get_db_error_msg_from_exception(exc)
> ... if msg == "beyond_limit":
> ... # [...]
On Thu, 31 May 2018 07:49:58 -0700
Ethan Furman wrote:
> On 05/31/2018 07:36 AM, Nick Coghlan wrote:
>
> > The exception machinery deliberately attempts to avoid instantiating
> > exception objects whenever it can, but that gets
> > significantly more difficult if we always need to create the in
On Thu, May 31, 2018 at 7:49 AM, Ethan Furman wrote:
> On 05/31/2018 07:36 AM, Nick Coghlan wrote:
>
> The exception machinery deliberately attempts to avoid instantiating
>> exception objects whenever it can, but that gets
>> significantly more difficult if we always need to create the instance
On 05/31/2018 07:36 AM, Nick Coghlan wrote:
The exception machinery deliberately attempts to avoid instantiating exception
objects whenever it can, but that gets
significantly more difficult if we always need to create the instance before we
can decide whether or not the raised
exception match
On 31 May 2018 at 14:47, Danilo J. S. Bellini
wrote:
> The idea is to allow catching exceptions beyond checking their MRO,
> using a class that checks the exception instance by implementing
> a custom __instancecheck__.
>
The exception machinery deliberately attempts to avoid instantiating
excep
In one of my own packages, I use the following to catch dynamic error
messages:
def handle_error(exc):
# do stuff with exc
with catch('error_code', handle_error):
# do stuff that can raise an error
The definition of "catch" is as follows, assuming the root exception
actual
On 31 May 2018 at 02:41, Steven D'Aprano wrote:
> Since error messages are rarely part of the exception API, testing for
> them is fragile and prone to errors. For example, what if the message
> changes to "no money" or "out of funds" or "insufficient funds" or
> "keine Mittel"? Since the error m
On Thu, May 31, 2018 at 11:23 PM, Peter O'Connor
wrote:
> On Thu, May 31, 2018 at 2:55 PM, Chris Angelico wrote:
>>
>> [process(tx, y) for x in xs for tx in [transform(x)] for y in yz]
>>
>> ...
>>
>> I think Serhiy was trying to establish this form as a standard idiom,
>> with optimization in th
On Thu, May 31, 2018 at 2:55 PM, Chris Angelico wrote:
> [process(tx, y) for x in xs for tx in [transform(x)] for y in yz]
>
...
I think Serhiy was trying to establish this form as a standard idiom,
> with optimization in the interpreter to avoid constructing a list and
> iterating over it (so i
On Thu, May 31, 2018 at 10:24 PM, Steven D'Aprano wrote:
> Do you have an equally compelling example for your given-comprehension
> syntax? I didn't think your example was obviously better than what we
> can already do:
>
> # calculate tx only once per x loop
> [process(tx, y) for x in xs
On Thu, May 31, 2018 at 02:22:21PM +0200, Peter O'Connor wrote:
> There seems to be a lot of controversy about updating variables defined
> outside a comprehension within a comprehension. Seems like it could lead
> to a lot of bugs and unintended consequences, and that it's safer to not
> allow s
On Thu, May 31, 2018 at 04:44:18AM -0400, Neil Girdhar wrote:
> Yes, you're right. That's the ambiguity I mentioned in my last message.
> It's too bad because I want given for expressions and given for
> comprehensions.
Why? So far you haven't given (heh, pun intended) any examples of
something y
On Thu, May 31, 2018 at 1:55 PM, Neil Girdhar wrote:
> Why wouldn't you want to just put the outer given outside the entire
> comprehension?
> retval = [expr(name, x) given name=update(name, x) for x in seq]
> given name=something
>
There seems to be a lot of controversy about updating varia
On Thu, May 31, 2018 at 5:39 AM Peter O'Connor
wrote:
> Well, there need not be any ambiguity if you think of "B given A" as
> "execute A before B", and remember that "given" has a lower precedence than
> "for" (So [B given A for x in seq] is parsed as [(B given A) for x in seq]
>
> Then
>
>>
>>
Well, there need not be any ambiguity if you think of "B given A" as
"execute A before B", and remember that "given" has a lower precedence than
"for" (So [B given A for x in seq] is parsed as [(B given A) for x in seq]
Then
>
> retval = [expr(name) given name=something(x) for x in seq]
>
Is
Current documentation says:
"An object is compatible with an exception if it is the class or a base
class of the exception object or a tuple containing an item compatible with
the exception."
https://docs.python.org/3/reference/compound_stmts.html#the-try-statement
It is, in my opinion, not very
Yes, you're right. That's the ambiguity I mentioned in my last message.
It's too bad because I want given for expressions and given for
comprehensions. But if you have both, there's ambiguity and you would at
least need parentheses:
[(y given y=2*x) for x in range(3)]
That might be fine.
On Thu,
* Sorry, message sent too early:
On Thu, May 31, 2018 at 4:50 AM, Neil Girdhar wrote:
>
>
>> [expression given name=something for x in seq]
>>
>
> retval = []
> name = something
> for x in seq:
> retval.append(expression)
> return retval
>
That's a little confusing then, because, given t
On Thu, May 31, 2018 at 4:50 AM, Neil Girdhar wrote:
>
>
>> [expression given name=something for x in seq]
>>
>
> retval = []
> name = something
> for x in seq:
> retval.append(expression)
> return retval
>
That's a little strange confusing then, because, given the way given is
used outsi
Okay, I though about it some more, and I think I'm mistaken about the
possibility of adding both rules to the grammar since in that case it is
ambiguous whether given binds more tightly to a trailing expression or to
the comp_iter. It's too bad.
On Wed, May 30, 2018 at 10:50 PM Neil Girdhar wrot
On 5/31/2018 12:47 AM, Danilo J. S. Bellini wrote:
Hi!
I was working on handling some exceptions from external software
(e.g. database constraint triggers)
switching the handler based on the messages that had been sent.
Today we can do something like (running on Python 3.6.5):
try:
... #
26 matches
Mail list logo
