Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On 11/30/2017 7:22 PM, Eric V. Smith wrote: On 11/30/2017 1:30 PM, Brett Cannon wrote: On Thu, 30 Nov 2017 at 05:00 Eric V. Smith > wrote:     On 11/30/2017 6:59 AM, Antoine Pitrou wrote: > > Or, simply, is_dataclass_instance(), which is even longer, but

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Thu, Nov 30, 2017, at 17:26, Greg Ewing wrote: > Eric Fahlgren wrote: > > ​I think you're missing something here, since it seems clear to me that > > indeed the arguments are evaluated prior to the function call.​ > > I think the OP may be confusing "evaluating the function" with > "calling th

Re: [Python-Dev] Allow tuple unpacking in return and yield statements

I'd be wary of going too far here. The parser (which uses a different representation for the grammar) may not support all of these -- in particular I would guess that the syntax for subscriptions is actually more complicated than shown, because of slices. Do you allow a[x:y, *rest]? On Thu, Nov 30

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On Thursday, November 30, 2017, Wes Turner wrote: > Could these be things in types? > > types.ClassType > types.InstanceType > > types.DataClass > types.DataClassInstanceType (?) > types.DataClass(types.ClassType) types.DataClassInstanceType(types.InstanceType) Would be logical? > > I sent a

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On 11/30/2017 1:30 PM, Brett Cannon wrote: On Thu, 30 Nov 2017 at 05:00 Eric V. Smith > wrote: On 11/30/2017 6:59 AM, Antoine Pitrou wrote: > > Or, simply, is_dataclass_instance(), which is even longer, but far more > readable thanks to explic

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

Eric Fahlgren wrote: ​I think you're missing something here, since it seems clear to me that indeed the arguments are evaluated prior to the function call.​ I think the OP may be confusing "evaluating the function" with "calling the function". If the function being called is determined by some

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

+1 to (3), I like the type error idea, too. I don't care much about naming... but if I were to bikeshed this, I'd go for isdataclass (like issubclass) isdatainstance (like isinstance) - Ł > On Nov 30, 2017, at 12:35 PM, Carl Meyer wrote: > > On 11/29/2017 05:02 PM, Guido van Rossum wrote: >>

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On 11/29/2017 05:02 PM, Guido van Rossum wrote: > I tried to look up the discussion but didn't find much except that you > flagged this as an issue. To repeat, your concern is that isdataclass() > applies to *instances*, not classes, which is how Eric has designed it, > but you worry that either th

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Fri, Dec 1, 2017 at 5:45 AM, Tres Seaver wrote: >> I would *not* add any spelling for an explicit bare-except equivalent. >> You would have to write: >> >> val = name.strip()[4:].upper() except Exception as -1 > > > Wouldn't that really need to be this instead, for a true 'except:' > equival

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On 11/29/2017 01:02 PM, Barry Warsaw wrote: > I don’t know whether I like any of this but I think a more > natural spelling would be: > > val = name.strip()[4:].upper() except (AttributeError, KeyError) as -1 > > which could devolve into: > > val = name.strip()[4:].upper() except KeyError

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Tue, 28 Nov 2017 12:10:54 -0800 Lukasz Langa wrote: > Hi Mark, > it looks like the PEP is dormant for over two years now. I had multiple > people ask me over the past few days about it though, so I wanted to ask if > this is moving forward. I am -1 on this PEP. I also think we don't need an

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On Thu, 30 Nov 2017 at 05:00 Eric V. Smith wrote: > On 11/30/2017 6:59 AM, Antoine Pitrou wrote: > > > > Or, simply, is_dataclass_instance(), which is even longer, but far more > > readable thanks to explicit word boundaries :-) > > That actually doesn't bother me. I think this API will be used r

Re: [Python-Dev] Allow tuple unpacking in return and yield statements

On Thu, 30 Nov 2017 at 05:01 David Cuthbert wrote: > Henk-Jaap noted that the grammar section of the language ref for yield and > return should also be updated from expression_list to starred_list with > this change. As noted elsewhere, this isn't in-sync with the Grammar file > (intentionally, i

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Thu, Nov 30, 2017, at 11:08, Eric Fahlgren wrote: > On Thu, Nov 30, 2017 at 2:48 AM, Andrea Griffini wrote: > > > Not really related but the PEP says that arguments in Python are evaluated > > before the function (as a reason to reject the idea of None-aware function > > call) but this is not

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Thu, Nov 30, 2017 at 2:48 AM, Andrea Griffini wrote: > Not really related but the PEP says that arguments in Python are evaluated > before the function (as a reason to reject the idea of None-aware function > call) but this is not the case: > ​I think you're missing something here, since it s

Re: [Python-Dev] Py_DECREF(m) on PyInit_xxx() failure?

30.11.17 17:42, Victor Stinner пише: CPython has many C extensions with non-trivial PyInit_xxx() functions which has to handle failures. A few modules use "Py_DECREF(m); retutrn NULL;", but most functions only do "return NULL;". Is it a reference leak or not? Example from Modules/posixmodule.c:

[Python-Dev] Py_DECREF(m) on PyInit_xxx() failure?

Hi, CPython has many C extensions with non-trivial PyInit_xxx() functions which has to handle failures. A few modules use "Py_DECREF(m); retutrn NULL;", but most functions only do "return NULL;". Is it a reference leak or not? Example from Modules/posixmodule.c: v = convertenviron(); Py_

[Python-Dev] PEPs: ``.. code:: python`` or ``::`` (syntax highlighting)

In ReStructuredText, this gets syntax highlighted because of the code directive [1][2][3]: .. code:: python import this def func(*args, **kwargs): pass This also gets syntax highlighted as python[3]: .. code:: python import this def func(*args, **kwargs): pass This d

Re: [Python-Dev] Allow tuple unpacking in return and yield statements

Henk-Jaap noted that the grammar section of the language ref for yield and return should also be updated from expression_list to starred_list with this change. As noted elsewhere, this isn't in-sync with the Grammar file (intentionally, if I understand correctly). I took a look, and I believe t

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On 11/30/2017 6:59 AM, Antoine Pitrou wrote: Or, simply, is_dataclass_instance(), which is even longer, but far more readable thanks to explicit word boundaries :-) That actually doesn't bother me. I think this API will be used rarely, if ever. Or more realistically, it should be used rarely:

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

Or, simply, is_dataclass_instance(), which is even longer, but far more readable thanks to explicit word boundaries :-) On Thu, 30 Nov 2017 10:16:58 +0100 Antoine Pitrou wrote: > isdataclass() testing for instance-ship does sound like a bug magnet to > me. > > If isdataclassinstance() is too l

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

30.11.17 03:02, Guido van Rossum пише: I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the nam

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

Sorry, this one shouldn't be "an"; " a" was correct:: ``repr``: If true (the default), an ``__repr__`` method will be generated. Note that __repr__ can be dangerous with user-supplied input because of terminal control character injection (e.g. broken syntax highlighting, \r, character set, LEDs

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

Could these be things in types? types.ClassType types.InstanceType types.DataClass types.DataClassInstanceType (?) I sent a PR with typo fixes and ``.. code:: python`` directives so that syntax highlighting works (at least on GitHub). https://github.com/python/peps/blob/master/pep-0557.rst htt

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

Not really related but the PEP says that arguments in Python are evaluated before the function (as a reason to reject the idea of None-aware function call) but this is not the case: >>> import dis >>> dis.dis(lambda : f()(g())) 1 0 LOAD_GLOBAL 0 (f)

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

isdataclass() testing for instance-ship does sound like a bug magnet to me. If isdataclassinstance() is too long (that's understandable), how about isdatainstance()? Regards Antoine. On Wed, 29 Nov 2017 17:02:21 -0800 Guido van Rossum wrote: > On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer wr

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On 11/29/2017 6:26 PM, Eric V. Smith wrote: I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/. Also, I've posted version 0.2 to PyPI as dataclasses, so you can play with it on 3.6 and 3.7. Eric. ___