Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator

On 6/30/2014 10:17 PM, Nick Coghlan wrote: > > On 30 Jun 2014 19:13, "Glenn Linderman" > wrote: >> >> >> If it is, use ensure_lstat=False, and use the proposed (by me) > .refresh() API to update the data for those that need it. > > I'm -1 on a refresh API for DirE

Re: [Python-Dev] bytes & bytearray

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/19/2015 11:36 AM, Ethan Furman wrote: > I was checking the documentation [1] to see where to put the new > information about bytes and bytearray %-formatting, and noticed > that /every/ operation that could modify a bytearray object in > place (e.

Re: [Python-Dev] TypeError messages

On 02/20/2015 09:05 AM, Brett Cannon wrote: > Some messages (only in C) truncate actual type name (%.50s, %.80s, > %.200s, %.500s). Should type name be truncated at all and for how limit? > > > I assume this is over some worry of string size blowing out memory > allocation or something? I

Re: [Python-Dev] how to inspect if something includes a bound first param

On 2/24/2015 8:56 PM, Gregory P. Smith wrote: > inspect.getargspec(method) and inspect.signature(method) both include > the 'self' parameter but how are we to figure out from method itself > that it is actually bound and that its first parameter is expected to be > a bound instance? > > So far I'v

Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask

On 3/12/2015 10:00 AM, Antoine Pitrou wrote: > On Thu, 12 Mar 2015 12:37:16 + > "Loevborg, Soeren Jakob" wrote: >> > import ipaddress > ipaddress.IPv4Interface('10.0.0.1/8') + 1 >> IPv4Interface('10.0.0.2/32') > ipaddress.IPv6Interface('fd00::1/64') + 1 >> IPv6Interface('fd00::2/12

Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask

On 3/12/2015 2:17 PM, Antoine Pitrou wrote: > On Thu, 12 Mar 2015 14:08:01 -0400 > Scott Dial wrote: > >> On 2015-03-12 10:46 AM, Eric V. Smith wrote: >>> On 3/12/2015 10:00 AM, Antoine Pitrou wrote: >>>> Related issue: >>>> >>>>>&g

Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask

On 3/14/2015 7:04 AM, francis wrote: > Hi, >> I, too, was thinking /24. I think that overflowing the host portion >> should raise OverflowError. >> > Just curiosity, why not a modulo calculation on the subnet instead > of raising the error? Personally, I can't imaging wanting that behavior. I can'

Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask

On 3/14/2015 4:52 PM, Eric V. Smith wrote: > On 3/14/2015 7:04 AM, francis wrote: >> Hi, >>> I, too, was thinking /24. I think that overflowing the host portion >>> should raise OverflowError. >>> >> Just curiosity, why not a modulo calculation on

[Python-Dev] Keyword-only parameters

I'm working on adding a numeric_owner parameter to some tarfile methods (http://bugs.python.org/issue23193), In a review, Berker suggested making the parameter keyword-only. I agree that you'd likely never want to pass just "True", but that "numeric_owner=True" would be a better usage. But, I don

Re: [Python-Dev] Keyword-only parameters

On 04/14/2015 02:11 PM, Zachary Ware wrote: > On Tue, Apr 14, 2015 at 1:06 PM, Steven D'Aprano wrote: >> On Tue, Apr 14, 2015 at 01:40:40PM -0400, Eric V. Smith wrote: >>> But, I don't see a lot of keyword-only parameters being added to stdlib >>> code. Is th

Re: [Python-Dev] Summary of Python tracker Issues

Thank you, David, for all of your work. It's much appreciated. -- Eric. > On Apr 17, 2015, at 7:18 PM, R. David Murray wrote: > >> On Fri, 17 Apr 2015 18:08:24 +0200, Python tracker >> wrote: >> >> ACTIVITY SUMMARY (2015-04-10 - 2015-04-17) >> Python tracker at http://bugs.python.org/ >> >

Re: [Python-Dev] [Python-checkins] cpython: Issue #24064: Property() docstrings are now writeable.

On 5/13/2015 4:10 AM, raymond.hettinger wrote: > https://hg.python.org/cpython/rev/1e8a768fa0a5 > changeset: 96010:1e8a768fa0a5 > user:Raymond Hettinger > date:Wed May 13 01:09:59 2015 -0700 > summary: > Issue #24064: Property() docstrings are now writeable. > (Patch by Berker

[Python-Dev] PEP 557: Data Classes

I've written a PEP for what might be thought of as "mutable namedtuples with defaults, but not inheriting tuple's behavior" (a mouthful, but it sounded simpler when I first thought of it). It's heavily influenced by the attrs project. It uses PEP 526 type annotations to define fields. From the

Re: [Python-Dev] PEP 557: Data Classes

Oops, I forgot the link. It should show up shortly at https://www.python.org/dev/peps/pep-0557/. Eric. On 9/8/17 7:57 AM, Eric V. Smith wrote: I've written a PEP for what might be thought of as "mutable namedtuples with defaults, but not inheriting tuple's behavior"

Re: [Python-Dev] PEP 557: Data Classes

Hah! Thanks for the catch. There is no C in my happy place. -- Eric. > On Sep 8, 2017, at 8:52 AM, Paul Moore wrote: > >> On 8 September 2017 at 15:57, Eric V. Smith wrote: >> I've written a PEP for what might be thought of as "mutable namedtuples with >

Re: [Python-Dev] PEP 557: Data Classes

On 9/8/17 9:07 AM, Eric V. Smith wrote: Hah! Thanks for the catch. I've pushed a fix to the PEP repo, it should show up online shortly. Eric. There is no C in my happy place. -- Eric. On Sep 8, 2017, at 8:52 AM, Paul Moore wrote: On 8 September 2017 at 15:57, Eric V. Smith

Re: [Python-Dev] PEP 557: Data Classes

On 9/8/17 3:20 PM, Mike Miller wrote: On 2017-09-08 07:57, Eric V. Smith wrote: I've written a PEP for… Apologies for the following list dumb questions and bikesheds: - 'Classes can be thought of as "mutable namedtuples with defaults".' - A C/C++ (struct)

Re: [Python-Dev] PEP 557: Data Classes

On 9/9/2017 11:41 AM, Gustavo Carneiro wrote: Hi, it is not clear whether anything is done to total_cost:     def total_cost(self) -> float: Does this become a property automatically, or is it still a method call?  To that end, some examples of *using* a data class, not just defining one, wo

Re: [Python-Dev] PEP 557: Data Classes

On 9/10/2017 10:00 AM, Michel Desmoulin wrote: The reaction is overwhelmingly positive everywhere: hacker news, reddit, twitter. Do you have a pointer to the Hacker News discussion? I missed it. People have been expecting something like that for a long time. Me, too! 3 questions: - is pr

Re: [Python-Dev] PEP 557: Data Classes

On 9/8/2017 11:01 AM, Eric V. Smith wrote: Oops, I forgot the link. It should show up shortly at https://www.python.org/dev/peps/pep-0557/. And now I've pushed a version that works with Python 3.6 to PyPI at https://pypi.python.org/pypi/dataclasses It implements the PEP as it curr

Re: [Python-Dev] PEP 557: Data Classes

> On Sep 10, 2017, at 5:13 PM, Mike Miller wrote: > > Thanks for the info. > > On 2017-09-08 15:40, Eric V. Smith wrote: >>> - Are types required? >> Annotations are required, the typing module is not. >>> Maybe an example or two with Any? >&

Re: [Python-Dev] PEP 557: Data Classes

On 9/10/17 10:27 PM, Raymond Hettinger wrote: On Sep 10, 2017, at 4:54 PM, Eric V. Smith wrote: And now I've pushed a version that works with Python 3.6 to PyPI at https://pypi.python.org/pypi/dataclasses It implements the PEP as it currently stands. I'll be making some twe

Re: [Python-Dev] PEP 557: Data Classes

On 9/10/17 11:08 PM, Nathaniel Smith wrote: Hi Eric, A few quick comments: Why do you even have a hash= argument on individual fields? For the whole class, I can imagine you might want to explicitly mark a whole class as unhashable, but it seems like the only thing you can do with the field-lev

Re: [Python-Dev] PEP 557: Data Classes

On 9/11/17 9:43 AM, tds...@mailbox.org wrote: Hi Eric, I have on question not addressed yet. The implementation is based on "__annotations__" where the type is specified. But "__annotations__" is not always filled. An interpreter version with special optimization could remove all __annotations_

Re: [Python-Dev] PEP 557: Data Classes

On 9/11/2017 12:34 PM, Nathaniel Smith wrote: On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith wrote: On 9/10/17 11:08 PM, Nathaniel Smith wrote: Why do you even have a hash= argument on individual fields? For the whole class, I can imagine you might want to explicitly mark a whole class as

Re: [Python-Dev] PEP 557: Data Classes

On 9/11/2017 6:28 PM, Guido van Rossum wrote: Oddly I don't like the enum (flag names get too long that way), but I do agree with everything else Barry said (it should be a trivalue flag and please don't name it cmp). So if we don't do enums, I think the choices are ints, strs, or maybe True/

Re: [Python-Dev] PEP 557: Data Classes

On 9/10/2017 11:08 PM, Nathaniel Smith wrote: Hi Eric, A few quick comments: Why do you even have a hash= argument on individual fields? For the whole class, I can imagine you might want to explicitly mark a whole class as unhashable, but it seems like the only thing you can do with the fiel

Re: [Python-Dev] Investigating time for `import requests`

The easiest workaround at the moment is still pretty clumsy: def import_SLLError():     from requests.exceptions import SLLError     return SLLError ...     except import_SLLError(): But what happens if that gives you an ImportError? You can't catch a requests exception unless requests

Re: [Python-Dev] PEP 557: Data Classes

On 10/12/2017 6:33 PM, Chris Barker wrote: On Thu, Oct 12, 2017 at 3:20 AM, Steve Holden > wrote:  The reason I liked "row" as a name is because it resembles "vector" and hence is loosely assocaited with the concept of a tuple as well as being familiar

Re: [Python-Dev] The syntax of replacement fields in format strings

If I had it to do over again, I’d implement it more strictly and only allow chars that are valid in identifiers. But see https://bugs.python.org/issue31907 for a case that is currently valid and would break if we changed how it worked. I’m not sure it’s worth the churn of deprecating this and

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

On 11/1/2017 5:47 PM, Ned Deily wrote: Happy belated Halloween to those who celebrate it; I hope it wasn't too scary! Also possibly scary: we have just a little over 12 weeks remaining until Python 3.7's feature code cutoff, 2018-01-29. Those 12 weeks include a number of traditional holidays

Re: [Python-Dev] Remove typing from the stdlib

On 11/3/2017 12:15 PM, Victor Stinner wrote: Hi, 2017-11-03 15:36 GMT+01:00 Guido van Rossum : Maybe we should remove typing from the stdlib? https://github.com/python/typing/issues/495 The typing module is not used yet in the stdlib, so there is no technically reason to keep typing part of

Re: [Python-Dev] Allow annotations using basic types in the stdlib?

On 11/6/2017 1:40 PM, Barry Warsaw wrote: On Nov 6, 2017, at 08:02, Victor Stinner wrote: While discussions on the typing module are still hot, what do you think of allowing annotations in the standard libraries, but limited to a few basic types: I’m still -1 on adding annotations to the std

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 11/6/2017 1:12 PM, Barry Warsaw wrote: On Nov 5, 2017, at 20:47, Nick Coghlan wrote: warnings.silence_deprecations() python -X silence-deprecations PYTHONSILENCEDEPRECATIONS=x It could be interesting to combine this with Tim's suggestion of putting an upper version limit on the silencing,

[Python-Dev] Second post: PEP 557, Data Classes

The updated version should show up at https://www.python.org/dev/peps/pep-0557/ shortly. The major changes from the previous version are: - Add InitVar to specify initialize-only fields. - Renamed __dataclass_post_init__() to __post_init(). - Rename cmp to compare. - Added eq, separate from com

Re: [Python-Dev] Second post: PEP 557, Data Classes

One more change: - Per-field metadata, for use by third parties. Also, thanks to Guido and Ivan for all of their feedback on the various issues that got the PEP to this point. Eric. On 11/25/2017 4:06 PM, Eric V. Smith wrote: The updated version should show up at https://www.python.org

Re: [Python-Dev] Second post: PEP 557, Data Classes

r existence of _fields) would also work for an instance and a class. And I suppose it's easy enough for the caller to further disallow a class, if that's what they want. Eric. Carl [1] https://mail.python.org/pipermail/python-dev/2017-September/149505.html On 11/25/2017 01:06

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/26/2017 3:35 AM, Eric V. Smith wrote: On 11/26/2017 12:23 AM, Carl Meyer wrote: A couple minor questions: If compare is True, then eq is ignored, and __eq__ and __ne__ will be automatically generated. IMO it's generally preferable to make nonsensical parameter combinatio

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/26/2017 3:48 AM, Eric V. Smith wrote: While creating an issue for this (https://github.com/ericvsmith/dataclasses/issues/88), it occurs to me that the class-level parameter really should be "order" or "orderable", not "compare". It made more sense when it w

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/26/2017 1:04 PM, Brett Cannon wrote: The only open issues I know of are: - Should object comparison require an exact match on the type? https://github.com/ericvsmith/dataclasses/issues/51 I say don't require the type comparison for duck typing purposes. The problem with that

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 1:04 AM, Nick Coghlan wrote: On 27 November 2017 at 15:04, Greg Ewing wrote: Nick Coghlan wrote: Perhaps the check could be: (type(lhs) == type(rhs) or fields(lhs) == fields(rhs)) and all (individual fields match) I think the types should *always* have to match, or at lea

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 6:01 AM, Sebastian Rittau wrote: On 25.11.2017 22:06, Eric V. Smith wrote: The major changes from the previous version are: - Add InitVar to specify initialize-only fields. This is the only feature that does not sit right with me. It looks very obscure and "hacky&q

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 7:31 AM, Sebastian Rittau wrote: On 27.11.2017 13:23, Eric V. Smith wrote: I had something like your suggestion half coded up, except I inspected the args to __post_init__() and added them to __init__, avoiding the API-unfriendly *args and **kwargs. I understand your concerns

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 7:26 AM, Sebastian Rittau wrote: On 27.11.2017 12:01, Sebastian Rittau wrote: The major changes from the previous version are: - Add InitVar to specify initialize-only fields. This is the only feature that does not sit right with me. It looks very obscure and "hacky". From w

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/17 10:51 AM, Guido van Rossum wrote: Following up on this subthread (inline below). On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith mailto:e...@trueblade.com>> wrote: On 11/27/2017 1:04 AM, Nick Coghlan wrote: On 27 November 2017 at 15:04, Greg Ewing mailto:g

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 10:51 AM, Guido van Rossum wrote: Following up on this subthread (inline below). Didn't we at one point have something like isinstance(other, self.__class__) and fields(other) == fields(self) and (plus some optimization if the types are identical)? That feels ideal, because

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/28/17 7:02 AM, Nick Coghlan wrote: On 28 November 2017 at 17:41, Eric V. Smith wrote: One thing this doesn't let you do is compare instances of two different subclasses of a base type: @dataclass class B: i: int @dataclass class C1(B): pass @dataclass class C2(B): pass You

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/28/2017 1:57 PM, Guido van Rossum wrote: I would also be happy with a retreat, where we define `__eq__` to insist that the classes are the same, and people can override this to their hearts' content. I agree. And I guess we could always add it later, if there's a huge demand and someone

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/28/2017 4:14 PM, Guido van Rossum wrote: Hm. Maybe for the ordering comparisons we could defer to the class with the longest list of fields, as long as there's a subtype relationship? That way bb would be equivalent, and both would use C.__gt__. Which had better not reject this on the bas

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/28/2017 8:31 PM, Eric V. Smith wrote: On 11/28/2017 4:14 PM, Guido van Rossum wrote: Hm. Maybe for the ordering comparisons we could defer to the class with the longest list of fields, as long as there's a subtype relationship? That way bb would be equivalent, and both would

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

> On Nov 29, 2017, at 12:40 PM, David Mertz wrote: > > I like much of the thinking in Random's approach. But I still think None > isn't quite special enough to warrant it's own syntax. > > However, his '(or None: name.strip()[4:].upper())' makes me realize that what > is being asked in all th

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

I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/. The only significant changes since the last version are: - changing the "compare" parameter to be "order", since that more accurately reflects what it does. - Having the combination

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

On 11/29/2017 6:51 PM, Carl Meyer wrote: On 11/29/2017 03: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/. The only significant changes since the last version are: - changing the "compare&quo

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

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

27;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 wrote: On 11/29/2017 03:26 PM, Eric V. Smith wrote: I've posted a new version of PEP 557, it should soon be avail

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 <mailto:e...@trueblade.com>> wrote: On 11/30/2017 6:59 AM, Antoine Pitrou wrote: > > Or, simply, is_dataclass_instance(), which is even longer, but far more >

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 <mailto:e...@trueblade.com>> wrote:     On 11/30/2017 6:59 AM, Antoine Pitrou wrote: > > Or, simply, is_dataclass_instance(), which is e

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

On 11/30/2017 3:35 PM, Carl Meyer wrote: 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 desig

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

Since this is easy enough to do in your own code, and I still don't see a use case, I'll just add a note to the PEP and delete isdataclass(). Plus, you can decide for yourself how to deal with the question of returning true for classes or instances or both. I've updated the PEP and reposted i

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

See https://github.com/ericvsmith/dataclasses/issues/104 for a discussion on making order=False the default. This matches regular classes in Python 3, which cannot be ordered. Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python

[Python-Dev] PEP 557 Data Classes 5th posting

I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered. Discussion at https://github.com/ericvsmith/dataclasses/issues/104 It's already

Re: [Python-Dev] PEP 557 Data Classes 5th posting

I've made a minor change: the return type of fields() is now a tuple, it was a list. Eric. On 12/2/2017 9:02 AM, Eric V. Smith wrote: I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matc

Re: [Python-Dev] PEP 557 Data Classes 5th posting

ng the tests anyway. I'm happy to change it back to a list, based on the convention of homogeneous types being in a list. Eric. On Sun, Dec 3, 2017 at 6:55 AM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: I've made a minor change: the return type of fields() is n

Re: [Python-Dev] PEP 557 Data Classes 5th posting

Me, either. So I'm going to leave it as a tuple. Unless I find something while reviewing it tonight, I'm done. Eric. On 12/3/2017 3:02 PM, Guido van Rossum wrote: On second thought I don't care that much. On Dec 3, 2017 9:07 AM, "Eric V. Smith" <mailto:e...@truebl

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/3/2017 3:33 PM, Antoine Pitrou wrote: On Sat, 2 Dec 2017 09:02:37 -0500 "Eric V. Smith" wrote: I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances c

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/3/2017 8:31 PM, Guido van Rossum wrote: On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: On 12/3/2017 3:33 PM, Antoine Pitrou wrote: Thanks.  I have to ask: why don't "asdict" and "astuple" respect

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/3/2017 9:07 PM, Eric V. Smith wrote: It also matches `attrs.asdict()`, which is what originally inspired it. Make that `attr.asdict()`. So easy to get that wrong. Eric. ___ Python-Dev mailing list Python-Dev@python.org https

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/3/2017 9:07 PM, Eric V. Smith wrote: On 12/3/2017 8:31 PM, Guido van Rossum wrote: On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith <mailto:e...@trueblade.com>> wrote:     On 12/3/2017 3:33 PM, Antoine Pitrou wrote:     Thanks.  I have to ask: why don't "a

Re: [Python-Dev] PEP 557 Data Classes 5th posting

Thanks, Guido. And indeed, thanks to everyone else who provided inspiration and feedback. I too would like to thank Hynek and the other authors of “attrs”. I’ll get the implementation committed in the next day or so. -- Eric. > On Dec 4, 2017, at 12:17 PM, Guido van Rossum wrote: > > And wi

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/4/2017 5:19 PM, Ivan Levkivskyi wrote: Congratulations, Eric! This is a great PEP and I am looking forward to implement support for it in mypy ;-) Thanks for all of your help, Ivan, especially for design decisions that help interoperability with mypy. I'm looking forward to mypy support,

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

On 12/7/17 3:27 PM, Raymond Hettinger wrote: ... I'm looking for guidance or workarounds for two issues that have arisen. First, the use of default values seems to completely preclude the use of __slots__. For example, this raises a ValueError: class A: __slots__ = ['x', 'y']

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

On 12/8/2017 1:28 PM, Raymond Hettinger wrote: On Dec 7, 2017, at 12:47 PM, Eric V. Smith wrote: On 12/7/17 3:27 PM, Raymond Hettinger wrote: ... I'm looking for guidance or workarounds for two issues that have arisen. First, the use of default values seems to completely preclude th

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

On 12/8/2017 9:14 PM, Nathaniel Smith wrote: On Dec 7, 2017 12:49, "Eric V. Smith" <mailto:e...@trueblade.com>> wrote: The reason I didn't include it (as @dataclass(slots=True)) is because it has to return a new class, and the rest of the dataclass features

Re: [Python-Dev] Is static typing still optional?

On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote: On 10 December 2017 at 22:24, Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote: Without typing (only the first currently works):     Point = namedtuple('Point', ['x', 'y', 'z'])          # underlying store is a tuple  

Re: [Python-Dev] Is static typing still optional?

On 12/10/2017 5:00 PM, Raymond Hettinger wrote: On Dec 10, 2017, at 1:37 PM, Eric V. Smith wrote: On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote: On 10 December 2017 at 22:24, Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote: Without typing (only the first currently

Re: [Python-Dev] Is static typing still optional?

On 12/10/2017 5:00 PM, Raymond Hettinger wrote: On Dec 10, 2017, at 1:37 PM, Eric V. Smith wrote: On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote: On 10 December 2017 at 22:24, Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote: Without typing (only the first currently

Re: [Python-Dev] Is static typing still optional?

On 12/11/2017 9:25 PM, Nick Coghlan wrote: On 11 Dec. 2017 12:26 pm, "Eric V. Smith" <mailto:e...@trueblade.com>> wrote: I see a couple of options: 1a: Use a default type annotation, if one is not is supplied. typing.Any would presumably make the most sense.

Re: [Python-Dev] Is static typing still optional?

On 12/15/2017 5:56 AM, Steve Holden wrote: On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal mailto:chris.bar...@noaa.gov>> wrote: ... However, typing is not currently imported by dataclasses.py. > And there you have an actual reason besides my uneasiness :-) - CHB ​hmm..

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 12/15/2017 11:55 AM, Guido van Rossum wrote: On Fri, Dec 15, 2017 at 8:32 AM, Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote: > On Dec 15, 2017, at 7:53 AM, Guido van Rossum mailto:gu...@python.org>> wrote: > > Make it so. "Dict keeps insertion order" is the ruling

Re: [Python-Dev] Is static typing still optional?

On 12/18/2017 2:55 PM, Ivan Levkivskyi wrote: On 18 December 2017 at 20:38, Nick Coghlan > wrote: On 19 Dec. 2017 7:00 am, "Chris Barker" mailto:chris.bar...@noaa.gov>> wrote: Are there other options?? plain old: @dataclass clas

Re: [Python-Dev] Is static typing still optional?

On 12/18/2017 9:41 PM, Chris Barker wrote: I'm really surprised no one seems to get my point here. TL;DR: My point is that having type annotation syntax required for something in the stdlib is a significant step toward "normalizing" type hinting in Python. Whether that's a good idea or not is

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 12/19/2017 2:38 AM, Steve Dower wrote: On 18Dec2017 2309, Steven D'Aprano wrote: [A LOT OF THINGS I AGREE WITH] I agree completely with Steven's reasoning here, and it bothers me that what is an irrelevant change to many users (dict becoming ordered) seems to imply that all users of dict hav

Re: [Python-Dev] Is static typing still optional?

On 12/20/2017 6:57 PM, Mike Miller wrote: On 2017-12-19 02:53, Paul Moore wrote: Also, the fact that no-one raised this issue during the whole time the PEP was being discussed (at least as far as I recollect) and that Guido (who of all of us should be most aware of what is and isn't acceptable u

Re: [Python-Dev] Is static typing still optional?

On 12/20/2017 8:13 PM, Eric V. Smith wrote: There is definitely a passive bias towards using types with dataclasses in that the Eric (the author) doesn't appear to want an example without them in the pep/docs. I'm not sure what such an example would look like. Do you me

Re: [Python-Dev] Is static typing still optional?

On 12/21/2017 1:46 AM, Chris Barker wrote: On Wed, Dec 20, 2017 at 5:29 PM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: There is definitely a passive bias towards using types with dataclasses in that the Eric (the author) doesn't appear to want an example witho

Re: [Python-Dev] Is static typing still optional?

On 12/21/17 6:25 AM, Sven R. Kunze wrote: On 21.12.2017 11:22, Terry Reedy wrote: @dataclass class C: a: int # integer field with no default b: float = 0.0 # float field with a default And the types will be recognized by type checkers such as mypy. And I think the non-typed examp

Re: [Python-Dev] is typing optional in dataclasses?

On 12/21/2017 7:55 PM, MRAB wrote: On 2017-12-22 00:19, Gregory P. Smith wrote: (subject for this sub-thread updated) On Thu, Dec 21, 2017 at 4:08 PM Chris Barker > wrote:     On Thu, Dec 21, 2017 at 3:36 PM, Gregory P. Smith mailto:g...@krypto.org>> wrote:

Re: [Python-Dev] Is static typing still optional?

On 12/21/2017 6:36 AM, Ivan Levkivskyi wrote: On 21 December 2017 at 11:22, Terry Reedy <mailto:tjre...@udel.edu>> wrote: On 12/21/2017 4:22 AM, Eric V. Smith wrote: On 12/21/2017 1:46 AM, Chris Barker wrote: I suggest that it be clear in the docs, and ideal

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

I’m traveling until next week, and haven’t had time to read any of these emails. I’ll look at them when I return. -- Eric. > On Dec 30, 2017, at 5:20 AM, Raymond Hettinger > wrote: > > >> On Dec 29, 2017, at 4:52 PM, Guido van Rossum wrote: >> >> I still think it should overrides anything

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

I’ll open an issue after I have time to read this thread and comment on it. -- Eric. > On Jan 3, 2018, at 12:31 PM, Ivan Levkivskyi wrote: > > I like the Guido's proposal, i.e. > > if '__repr__' not in cls.__dict__: > ... # generate the method > > etc. I didn't find an issue to

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

On 1/2/2018 12:01 AM, Guido van Rossum wrote: On Mon, Jan 1, 2018 at 8:50 PM, Ethan Smith > wrote: On Mon, Jan 1, 2018 at 5:03 PM, Chris Barker mailto:chris.bar...@noaa.gov>> wrote: On Sat, Dec 30, 2017 at 7:27 AM, Stephen J. Turnbull mailto:turnbu

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

On 1/5/2018 11:24 AM, Guido van Rossum wrote: On Fri, Jan 5, 2018 at 5:08 AM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: On 1/2/2018 12:01 AM, Guido van Rossum wrote: Yes, there's a class variable (__dataclass_fields__) that identifies the parent f

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

seudo-fields. But no one came up with a use case. Eric. On Fri, Jan 5, 2018 at 8:43 AM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: On 1/5/2018 11:24 AM, Guido van Rossum wrote: On Fri, Jan 5, 2018 at 5:08 AM, Eric V. Smith mailto:e...@trueblade.com>

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

ssue. Eric. On Fri, Jan 5, 2018 at 11:06 AM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: On 1/5/2018 12:58 PM, Guido van Rossum wrote: Hm. I don't know that people will conclude that checking for a dataclass is an anti-pattern. They'll probably ju

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

On 1/5/2018 2:11 PM, Eric V. Smith wrote: On 1/5/2018 2:09 PM, Guido van Rossum wrote: I'm normally no big fan of things that take either a class or an instance, but since fields() does this, I think is_dataclass() should to. And that's the name I'd choose. OK on the pseudo-f

Re: [Python-Dev] Is static typing still optional?

On 12/10/2017 5:00 PM, Raymond Hettinger wrote: On Dec 10, 2017, at 1:37 PM, Eric V. Smith wrote: On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote: On 10 December 2017 at 22:24, Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote: Without typing (only the first currently

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

On 1/3/2018 1:17 PM, Eric V. Smith wrote: I’ll open an issue after I have time to read this thread and comment on it. https://bugs.python.org/issue32513 I need to think though how __eq__ and __ne__ work, as well as the ordering operators. My specific concern with __ne__ is that there'

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

On 1/7/2018 12:25 PM, Guido van Rossum wrote: On Sun, Jan 7, 2018 at 9:09 AM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: On 1/3/2018 1:17 PM, Eric V. Smith wrote: I’ll open an issue after I have time to read this thread and comment on it.

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

On 1/25/2018 8:13 PM, Terry Reedy wrote: On 1/25/2018 7:47 PM, Mariatta Wijaya wrote: I think we're starting to deviate from the original topic here which is: please replace # with GH- when you click Squash & Merge button. I will try to remember to do this, although it seems pointless if most

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

On 1/26/2018 12:22 PM, Mariatta Wijaya wrote: I believe https://github.com/python/bedevere/pull/82  will add a comment, which will get emailed to everyone nosy on the PR. Yes, and I've just updated my PR description: If a PR was merged and

  1   2   3   4   5   6   >