OK, I concede your point (and indeed I only tested this on 3.6). If we
could break the backward compatibility for now() we presumably can break it
for this purpose.
On Sun, Jan 6, 2019 at 11:02 AM Paul Ganssle wrote:
> I did address this in the original post - the assumption that the subclass
>
Brett,
Thank you for bringing this up, but I think you /may/ have misunderstood
my position - though maybe you understood the thrust and wanted to
clarify for people coming in halfway, which I applaud.
I proposed this change /knowing/ that it was a breaking change - it's
why I brought it to the
On Sun, 6 Jan 2019 at 11:00, Paul Ganssle wrote:
> I did address this in the original post - the assumption that the subclass
> constructor will have the same arguments as the base constructor is baked
> into many alternate constructors of datetime. I acknowledge that this is a
> breaking
On Mon, Jan 7, 2019 at 7:18 AM Brett Cannon wrote:
>
> Maybe someone can propose a code comment to explain this instead? I agree
> that this doesn't need to be explained in the language spec, but I don't see
> any harm in a comment where the opcodes are emitted to explain why it is the
> way
On Sun, 6 Jan 2019 at 10:26, Guido van Rossum wrote:
> On Sun, Jan 6, 2019 at 9:40 AM Paul G wrote:
>
>> I am not familiar enough with the compiler logic, but would it be
>> possible to optimize this away by detecting whether the bound name has
>> already been deleted during the body of the
Hello,
On Mon, 7 Jan 2019 01:14:55 +1100
Steven D'Aprano wrote:
[]
> > Thanks, that summarizes it well. And well, my interest is also how
> > non-compliant would be for another Python implementation to act
> > differently, specifically to skip wrapping an except handler body in
> > try-finally
I did address this in the original post - the assumption that the
subclass constructor will have the same arguments as the base
constructor is baked into many alternate constructors of datetime. I
acknowledge that this is a breaking change, but it is a small one -
anyone creating such a subclass
Hello,
On Sun, 6 Jan 2019 17:26:09 +0200
Serhiy Storchaka wrote:
[]
> Because there is a reason for such code.
>
> See issue1631942 [1] and the thread with the subject "self-contained
> exceptions" on the Python-3000 mailing list [2] for the rationale.
>
> In short, the code
>
> try:
06.01.19 18:05, Chris Angelico пише:
Which I read, and they do not explain the assignment of None. The only
reference is that the tracker issue mentions having a test case to
ensure that it's happening, which is further proof that it's
intentional, but still fails to explain *why*.
This is
On 1/6/19 1:29 PM, Andrew Svetlov wrote:
> From my perspective datetime classes are even more complex than int/float.
> Let's assume we have
>
> class DT(datetime.datetime): ...
> class TD(datetime.timedelta): ...
>
> What is the result type for the following expressions?
> DT - datetime
> DT -
I don't think datetime and builtins like int necessarily need to be
aligned. But I do see a problem -- the __new__ and __init__ methods defined
in the subclass (if any) should allow for being called with the same
signature as the base datetime class. Currently you can have a subclass of
datetime
>From my perspective datetime classes are even more complex than int/float.
Let's assume we have
class DT(datetime.datetime): ...
class TD(datetime.timedelta): ...
What is the result type for the following expressions?
DT - datetime
DT - DT
DT + TD
DT + timedelta
I have a feeling that the
On Sun, Jan 6, 2019 at 9:40 AM Paul G wrote:
> I am not familiar enough with the compiler logic, but would it be possible
> to optimize this away by detecting whether the bound name has already been
> deleted during the body of the except statement?
>
As was said before, it's not useful to
I am not familiar enough with the compiler logic, but would it be possible to
optimize this away by detecting whether the bound name has already been deleted
during the body of the except statement?
On January 6, 2019 4:18:00 PM UTC, Chris Angelico wrote:
>On Mon, Jan 7, 2019 at 3:13 AM Paul
On Mon, Jan 7, 2019 at 3:13 AM Paul G wrote:
>
> I think Serhiy is saying that if you delete exc before the except body ends,
> when the compiled code goes to delete it it will fail. Binding to None
> guarantees that there is something to delete.
Ahh! Thank you. I interpreted that example as a
I think Serhiy is saying that if you delete exc before the except body ends,
when the compiled code goes to delete it it will fail. Binding to None
guarantees that there is something to delete.
On January 6, 2019 4:05:27 PM UTC, Chris Angelico wrote:
>On Mon, Jan 7, 2019 at 2:52 AM Serhiy
On Mon, Jan 7, 2019 at 2:52 AM Serhiy Storchaka wrote:
>
> 06.01.19 17:35, Chris Angelico пише:
> > On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka wrote:
> >> Because there is a reason for such code.
> >
> > What reason though??
>
> I added references and excerpts in the previous message.
I can think of many reasons why datetime is different from builtins,
though to be honest I'm not sure that consistency for its own sake is
really a strong argument for keeping a counter-intuitive behavior - and
to be honest I'm open to the idea that /all/ arithmetic types /should/
have some form
06.01.19 17:35, Chris Angelico пише:
On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka wrote:
Because there is a reason for such code.
What reason though??
I added references and excerpts in the previous message.
In short, the code
try:
1/0
except Exception as e:
On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka wrote:
> > The "store None" behavior can be traced down to introduction of the
> > "del except target var" behavior back in 2007:
> >
On 1/6/19 9:14 AM, Steven D'Aprano wrote:
> [...]
> But a better question is, why would you (generic, not you personally)
> imagine that, alone out of all flow control statements, ONLY "except"
> clauses introduce a new scope? Every other flow control statement (for,
> while, if, elif, else,
06.01.19 13:10, Paul Sokolovsky пише:
Storing None looks superfluous. For example, DELETE_FAST explicitly
stores NULL on delete.
https://github.com/python/cpython/blob/master/Python/ceval.c#L2249
Likewise, for DELETE_NAME/DELETE_GLOBAL, PyObject_DelItem() is
called which translates to:
On Mon, Jan 7, 2019 at 1:21 AM Steven D'Aprano wrote:
> > I would
> > definitely find a behavior of merely clearing an "except" target
> > variable to be more understandable than magic fiddling with namespaces.
>
> I don't understand what this means. What is "clearing an except target"?
> Do you
On Sun, Jan 06, 2019 at 03:03:03PM +0200, Paul Sokolovsky wrote:
[...]
> Ack. Such an explanation makes sense, though semantics behind it is
> "magic". And given that variable deletion happens conditionally on
> whether exception happened or not, it's still pretty strange.
I don't think anyone
Hello,
On Sun, 6 Jan 2019 23:10:24 +1100
Steven D'Aprano wrote:
[]
> > # Where's my *global* variable?
> > # Worse, my variable can be gone or not, depending on whether
> > exception # triggered or not.
> > print(e)
>
> That's not "worse", that's BETTER.
>
> With e deleted, you get an
On Sun, Jan 06, 2019 at 01:10:48PM +0200, Paul Sokolovsky wrote:
[...]
> P.S.
> I actually wanted to argue that such an implementation is hardly ideal
> at all. Consider:
>
>
> e = "my precious data"
> try:
> 1/0
> except Exception as e:
> pass
>
> # Where's my *global* variable?
>
Hello,
On Sun, 6 Jan 2019 22:19:39 +1100
Chris Angelico wrote:
> > It's clear that what happens there is that first None is stored to
> > N, just to del it as the next step. Indeed, that's what done in the
> > compile.c:
> >
> >
On Sun, Jan 6, 2019 at 10:12 PM Paul Sokolovsky wrote:
> It's clear that what happens there is that first None is stored to N,
> just to del it as the next step. Indeed, that's what done in the
> compile.c:
>
> https://github.com/python/cpython/blob/master/Python/compile.c#L2905
>
> Storing None
Hello,
As explained in
https://docs.python.org/3/reference/compound_stmts.html#the-try-statement ,
except E as N:
foo
is actually compiled as:
except E as N:
try:
foo
finally:
del N
But looking at the generated bytecode, it's worse than that:
16
29 matches
Mail list logo
