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

[Nick Coghlan]

On 2 December 2017 at 08:15, Eric V. Smith  wrote:
> 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.

+1 for making "order=True" be explicitly opt-in.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 it. The only change is removing 
isdataclass().


Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 designed it,
but you worry that either through the name or just because people don't
read the docs it will be confusing. What do you suppose we do? I think
making it work for classes as well as for instances would cause another
category of bugs (confusion between cases where a class is needed vs. an
instance abound in other situations -- we don't want to add to that).
Maybe it should raise TypeError when passed a class (unless its
metaclass is a dataclass)? Maybe it should be renamed to
isdataclassinstance()? That's a mouthful, but I don't know how common
the need to call this is, and people who call it a lot can define their
own shorter alias.


Yeah, I didn't propose a specific fix because I think there are several
options (all mentioned in this thread already), and I don't really have
strong feelings about them:

1) Keep the existing function and name, let it handle either classes or
instances. I agree that this is probably not the best option available,
though IMO it's still marginally better than the status quo).

2) Punt the problem by removing the function; don't add it to the public
API at all until we have demonstrated demand.

3) Rename it to "is_dataclass_instance" (and maybe also keep a separate
"is_dataclass" for testing classes directly). (Then there's also the
choice about raising TypeError vs just returning False if a function is
given the wrong type; I think TypeError is better.)


In that case, you can spell "is_dataclass_instance":

def isdataclass_instance(obj):
dataclasses.fields(obj)  # raises TypeError for non-dataclass
 # classes or instances
if not isinstance(obj, type):
raise TypeError('not an instance')
return True

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 omit delete isdataclass().


Plus, you can decide for yourself how to deal with the question of 
returning true for classes or instances or both.


Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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
    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: what 
actually

    happens will no doubt surprise me.

    So I'm okay with is_dataclass_instance() and is_dataclass_class().

    But then I'm also okay with dropping the API entirely. nametuple has
    lived for years without it, although Raymond's advice there is 
that if

    you really want to know, look for _fields. See
    https://bugs.python.org/issue7796#msg99869 and the following 
discussion.



My question was going to be whether this is even necessary. :) Perhaps 
we just drop it for now and add it in if we find there's a public need 
for it?


That's what I'm leaning toward. I've been trying to figure out what 
attr.has() or hasattr(obj, '_fields') are actually used for. The attrs 
version is hard to search for, and while I see the question about 
namedtuples asked fairly often on SO, I haven't seen an actual use case.


It's easy enough for someone to write their own isdataclass(), 
admittedly using an undocumented feature.


Actually there's a supported way to write your own isdataclass(): call 
dataclasses.fields(obj). If it throws a TypeError, it's not a dataclass 
instance or class. I'll add a note to the PEP.


Eric.



So I'm thinking let's drop it and then gauge the demand for it, if any.

Eric.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com 



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Wes Turner]

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 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
>
> https://github.com/python/peps/pull/488
>
> Additional notes:
>
> - "DataClass" instead of "Data Class" would be easier to search for.
> s/DataClass/Data Class/g?
> - It's probably worth mentioning how hash works when frozen=True also here:
>   https://github.com/python/peps/blob/master/pep-0557.rst#frozen-instances
> - The `hash` explanation could be a two column table for easier readability
>
> What a great feature.
>
> - Runtime data validation from annotations (like PyContracts,) would be
> cool
> - __slots__ are worth the time
>
> On Thursday, November 30, 2017, Antoine Pitrou  > wrote:
>
>>
>> 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  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" parameter to be "order", since that more
>> > > > accurately reflects what it does.
>> > > > - Having the combination of "eq=False" and "order=True" raise an
>> > > > exception instead of silently changing eq to True.
>> > > >
>> > > > There were no other issues raised with the previous version of the
>> PEP.
>> > >
>> > > Not quite; I also raised the issue of isdataclass(ADataClass)
>> returning
>> > > False. I still think that's likely to be a cause of bug reports if
>> left
>> > > as-is.
>> > >
>> >
>> > 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 name or just because people don't read
>> > the docs it will be confusing. What do you suppose we do? I think
>> making it
>> > work for classes as well as for instances would cause another category
>> of
>> > bugs (confusion between cases where a class is needed vs. an instance
>> > abound in other situations -- we don't want to add to that). Maybe it
>> > should raise TypeError when passed a class (unless its metaclass is a
>> > dataclass)? Maybe it should be renamed to isdataclassinstance()? That's
>> a
>> > mouthful, but I don't know how common the need to call this is, and
>> people
>> > who call it a lot can define their own shorter alias.
>> >
>>
>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.
>> turner%40gmail.com
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 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: what actually
happens will no doubt surprise me.

So I'm okay with is_dataclass_instance() and is_dataclass_class().

But then I'm also okay with dropping the API entirely. nametuple has
lived for years without it, although Raymond's advice there is that if
you really want to know, look for _fields. See
https://bugs.python.org/issue7796#msg99869 and the following discussion.


My question was going to be whether this is even necessary. :) Perhaps 
we just drop it for now and add it in if we find there's a public need 
for it?


That's what I'm leaning toward. I've been trying to figure out what 
attr.has() or hasattr(obj, '_fields') are actually used for. The attrs 
version is hard to search for, and while I see the question about 
namedtuples asked fairly often on SO, I haven't seen an actual use case.


It's easy enough for someone to write their own isdataclass(), 
admittedly using an undocumented feature.


So I'm thinking let's drop it and then gauge the demand for it, if any.

Eric.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Lukasz Langa]

+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:
>> 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 name or just because people don't
>> read the docs it will be confusing. What do you suppose we do? I think
>> making it work for classes as well as for instances would cause another
>> category of bugs (confusion between cases where a class is needed vs. an
>> instance abound in other situations -- we don't want to add to that).
>> Maybe it should raise TypeError when passed a class (unless its
>> metaclass is a dataclass)? Maybe it should be renamed to
>> isdataclassinstance()? That's a mouthful, but I don't know how common
>> the need to call this is, and people who call it a lot can define their
>> own shorter alias.
> 
> Yeah, I didn't propose a specific fix because I think there are several
> options (all mentioned in this thread already), and I don't really have
> strong feelings about them:
> 
> 1) Keep the existing function and name, let it handle either classes or
> instances. I agree that this is probably not the best option available,
> though IMO it's still marginally better than the status quo).
> 
> 2) Punt the problem by removing the function; don't add it to the public
> API at all until we have demonstrated demand.
> 
> 3) Rename it to "is_dataclass_instance" (and maybe also keep a separate
> "is_dataclass" for testing classes directly). (Then there's also the
> choice about raising TypeError vs just returning False if a function is
> given the wrong type; I think TypeError is better.)
> 
> Carl
> 
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/lukasz%40langa.pl



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Carl Meyer]

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 through the name or just because people don't
> read the docs it will be confusing. What do you suppose we do? I think
> making it work for classes as well as for instances would cause another
> category of bugs (confusion between cases where a class is needed vs. an
> instance abound in other situations -- we don't want to add to that).
> Maybe it should raise TypeError when passed a class (unless its
> metaclass is a dataclass)? Maybe it should be renamed to
> isdataclassinstance()? That's a mouthful, but I don't know how common
> the need to call this is, and people who call it a lot can define their
> own shorter alias.

Yeah, I didn't propose a specific fix because I think there are several
options (all mentioned in this thread already), and I don't really have
strong feelings about them:

1) Keep the existing function and name, let it handle either classes or
instances. I agree that this is probably not the best option available,
though IMO it's still marginally better than the status quo).

2) Punt the problem by removing the function; don't add it to the public
API at all until we have demonstrated demand.

3) Rename it to "is_dataclass_instance" (and maybe also keep a separate
"is_dataclass" for testing classes directly). (Then there's also the
choice about raising TypeError vs just returning False if a function is
given the wrong type; I think TypeError is better.)

Carl





signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 rarely,
> if ever. Or more realistically, it should be used rarely: what actually
> happens will no doubt surprise me.
>
> So I'm okay with is_dataclass_instance() and is_dataclass_class().
>
> But then I'm also okay with dropping the API entirely. nametuple has
> lived for years without it, although Raymond's advice there is that if
> you really want to know, look for _fields. See
> https://bugs.python.org/issue7796#msg99869 and the following discussion.
>

My question was going to be whether this is even necessary. :) Perhaps we
just drop it for now and add it in if we find there's a public need for it?

-Brett


>
> Eric.
>
> >
> > 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 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 
> 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" parameter to be "order", since that more
> > accurately reflects what it does.
> > - Having the combination of "eq=False" and "order=True" raise an
> > exception instead of silently changing eq to True.
> >
> > There were no other issues raised with the previous version of the
> PEP.
> 
>  Not quite; I also raised the issue of isdataclass(ADataClass)
> returning
>  False. I still think that's likely to be a cause of bug reports if
> left
>  as-is.
> 
> >>>
> >>> 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 name or just because people don't
> read
> >>> the docs it will be confusing. What do you suppose we do? I think
> making it
> >>> work for classes as well as for instances would cause another category
> of
> >>> bugs (confusion between cases where a class is needed vs. an instance
> >>> abound in other situations -- we don't want to add to that). Maybe it
> >>> should raise TypeError when passed a class (unless its metaclass is a
> >>> dataclass)? Maybe it should be renamed to isdataclassinstance()?
> That's a
> >>> mouthful, but I don't know how common the need to call this is, and
> people
> >>> who call it a lot can define their own shorter alias.
> >>>
> >>
> >>
> >>
> >
> >
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
> >
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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: what actually 
happens will no doubt surprise me.


So I'm okay with is_dataclass_instance() and is_dataclass_class().

But then I'm also okay with dropping the API entirely. nametuple has 
lived for years without it, although Raymond's advice there is that if 
you really want to know, look for _fields. See 
https://bugs.python.org/issue7796#msg99869 and the following discussion.


Eric.



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 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  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" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.

There were no other issues raised with the previous version of the PEP.


Not quite; I also raised the issue of isdataclass(ADataClass) returning
False. I still think that's likely to be a cause of bug reports if left
as-is.



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 name or just because people don't read
the docs it will be confusing. What do you suppose we do? I think making it
work for classes as well as for instances would cause another category of
bugs (confusion between cases where a class is needed vs. an instance
abound in other situations -- we don't want to add to that). Maybe it
should raise TypeError when passed a class (unless its metaclass is a
dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a
mouthful, but I don't know how common the need to call this is, and people
who call it a lot can define their own shorter alias.
   








___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 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  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" parameter to be "order", since that more
> > > > accurately reflects what it does.
> > > > - Having the combination of "eq=False" and "order=True" raise an
> > > > exception instead of silently changing eq to True.
> > > >
> > > > There were no other issues raised with the previous version of the PEP. 
> > > >
> > >
> > > Not quite; I also raised the issue of isdataclass(ADataClass) returning
> > > False. I still think that's likely to be a cause of bug reports if left
> > > as-is.
> > >
> > 
> > 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 name or just because people don't read
> > the docs it will be confusing. What do you suppose we do? I think making it
> > work for classes as well as for instances would cause another category of
> > bugs (confusion between cases where a class is needed vs. an instance
> > abound in other situations -- we don't want to add to that). Maybe it
> > should raise TypeError when passed a class (unless its metaclass is a
> > dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a
> > mouthful, but I don't know how common the need to call this is, and people
> > who call it a lot can define their own shorter alias.
> >   
> 
> 
> 



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 name or just because people don't 
read the docs it will be confusing. What do you suppose we do? I think 
making it work for classes as well as for instances would cause another 
category of bugs (confusion between cases where a class is needed vs. an 
instance abound in other situations -- we don't want to add to that). 
Maybe it should raise TypeError when passed a class (unless its 
metaclass is a dataclass)? Maybe it should be renamed to 
isdataclassinstance()? That's a mouthful, but I don't know how common 
the need to call this is, and people who call it a lot can define their 
own shorter alias.


There is isdatadescriptor() which is not too shorter.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Wes Turner]

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,)

On Thursday, November 30, 2017, Wes Turner  wrote:

> 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
>
> https://github.com/python/peps/pull/488
>
> Additional notes:
>
> - "DataClass" instead of "Data Class" would be easier to search for.
> s/DataClass/Data Class/g?
> - It's probably worth mentioning how hash works when frozen=True also here:
>   https://github.com/python/peps/blob/master/pep-0557.rst#frozen-instances
> - The `hash` explanation could be a two column table for easier readability
>
> What a great feature.
>
> - Runtime data validation from annotations (like PyContracts,) would be
> cool
> - __slots__ are worth the time
>
> On Thursday, November 30, 2017, Antoine Pitrou  > wrote:
>
>>
>> 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  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" parameter to be "order", since that more
>> > > > accurately reflects what it does.
>> > > > - Having the combination of "eq=False" and "order=True" raise an
>> > > > exception instead of silently changing eq to True.
>> > > >
>> > > > There were no other issues raised with the previous version of the
>> PEP.
>> > >
>> > > Not quite; I also raised the issue of isdataclass(ADataClass)
>> returning
>> > > False. I still think that's likely to be a cause of bug reports if
>> left
>> > > as-is.
>> > >
>> >
>> > 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 name or just because people don't read
>> > the docs it will be confusing. What do you suppose we do? I think
>> making it
>> > work for classes as well as for instances would cause another category
>> of
>> > bugs (confusion between cases where a class is needed vs. an instance
>> > abound in other situations -- we don't want to add to that). Maybe it
>> > should raise TypeError when passed a class (unless its metaclass is a
>> > dataclass)? Maybe it should be renamed to isdataclassinstance()? That's
>> a
>> > mouthful, but I don't know how common the need to call this is, and
>> people
>> > who call it a lot can define their own shorter alias.
>> >
>>
>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.
>> turner%40gmail.com
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Wes Turner]

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

https://github.com/python/peps/pull/488

Additional notes:

- "DataClass" instead of "Data Class" would be easier to search for.
s/DataClass/Data Class/g?
- It's probably worth mentioning how hash works when frozen=True also here:
  https://github.com/python/peps/blob/master/pep-0557.rst#frozen-instances
- The `hash` explanation could be a two column table for easier readability

What a great feature.

- Runtime data validation from annotations (like PyContracts,) would be cool
- __slots__ are worth the time

On Thursday, November 30, 2017, Antoine Pitrou  wrote:

>
> 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  > 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" parameter to be "order", since that more
> > > > accurately reflects what it does.
> > > > - Having the combination of "eq=False" and "order=True" raise an
> > > > exception instead of silently changing eq to True.
> > > >
> > > > There were no other issues raised with the previous version of the
> PEP.
> > >
> > > Not quite; I also raised the issue of isdataclass(ADataClass) returning
> > > False. I still think that's likely to be a cause of bug reports if left
> > > as-is.
> > >
> >
> > 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 name or just because people don't read
> > the docs it will be confusing. What do you suppose we do? I think making
> it
> > work for classes as well as for instances would cause another category of
> > bugs (confusion between cases where a class is needed vs. an instance
> > abound in other situations -- we don't want to add to that). Maybe it
> > should raise TypeError when passed a class (unless its metaclass is a
> > dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a
> > mouthful, but I don't know how common the need to call this is, and
> people
> > who call it a lot can define their own shorter alias.
> >
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org 
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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  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" parameter to be "order", since that more
> > > accurately reflects what it does.
> > > - Having the combination of "eq=False" and "order=True" raise an
> > > exception instead of silently changing eq to True.
> > >
> > > There were no other issues raised with the previous version of the PEP.  
> >
> > Not quite; I also raised the issue of isdataclass(ADataClass) returning
> > False. I still think that's likely to be a cause of bug reports if left
> > as-is.
> >  
> 
> 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 name or just because people don't read
> the docs it will be confusing. What do you suppose we do? I think making it
> work for classes as well as for instances would cause another category of
> bugs (confusion between cases where a class is needed vs. an instance
> abound in other situations -- we don't want to add to that). Maybe it
> should raise TypeError when passed a class (unless its metaclass is a
> dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a
> mouthful, but I don't know how common the need to call this is, and people
> who call it a lot can define their own shorter alias.
> 



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

 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 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 of "eq=False" and "order=True" raise an
> > exception instead of silently changing eq to True.
> >
> > There were no other issues raised with the previous version of the PEP.
>
> Not quite; I also raised the issue of isdataclass(ADataClass) returning
> False. I still think that's likely to be a cause of bug reports if left
> as-is.
>

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 name or just because people don't read
the docs it will be confusing. What do you suppose we do? I think making it
work for classes as well as for instances would cause another category of
bugs (confusion between cases where a class is needed vs. an instance
abound in other situations -- we don't want to add to that). Maybe it
should raise TypeError when passed a class (unless its metaclass is a
dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a
mouthful, but I don't know how common the need to call this is, and people
who call it a lot can define their own shorter alias.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.

There were no other issues raised with the previous version of the PEP.


Not quite; I also raised the issue of isdataclass(ADataClass) returning
False. I still think that's likely to be a cause of bug reports if left
as-is.


Oops, sorry about that!

I think you're probably right. attr.has(), which is the equivalent attrs 
API, returns True for both classes and instances (although 
interestingly, the code only talks about it working on classes).


https://github.com/ericvsmith/dataclasses/issues/99

Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Carl Meyer]

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" parameter to be "order", since that more
> accurately reflects what it does.
> - Having the combination of "eq=False" and "order=True" raise an
> exception instead of silently changing eq to True.
> 
> There were no other issues raised with the previous version of the PEP.

Not quite; I also raised the issue of isdataclass(ADataClass) returning
False. I still think that's likely to be a cause of bug reports if left
as-is.

Carl



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

I plan to accept this on Monday if no new objections are raised.

On Nov 29, 2017 3:28 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" parameter to be "order", since that more
> accurately reflects what it does.
> - Having the combination of "eq=False" and "order=True" raise an exception
> instead of silently changing eq to True.
>
> There were no other issues raised with the previous version of the PEP.
>
> So with that, I think it's ready for a pronouncement.
>
> Eric.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 of "eq=False" and "order=True" raise an 
exception instead of silently changing eq to True.


There were no other issues raised with the previous version of the PEP.

So with that, I think it's ready for a pronouncement.

Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com