On 11/26/2017 12:23 AM, Carl Meyer wrote:
Hi Eric,
Really excited about this PEP, thanks for working on it.
Thanks, Carl.
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 nonsen
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 combinations
an immediate
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 was called "cmp", but
"compare"
On Sat, Nov 25, 2017 at 4:57 PM, Nick Coghlan wrote:
> On 26 November 2017 at 02:59, Guido van Rossum wrote:
> >
> > I'd be happy to stop with the conclusion that we're going to rip out some
> > confusing syntax rather than trying to generate code for it -- IMO we've
> > proved to ourselves that
On Sat, Nov 25, 2017, 14:00 Eric V. Smith, wrote:
> 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_
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
On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum wrote:
> On Sat, Nov 25, 2017 at 1:05 PM, David Mertz wrote:
>>
>> FWIW, on a side point. I use 'yield' and 'yield from' ALL THE TIME in real
>> code. Probably 80% of those would be fine with yield statements, but a
>> significant fraction use `ge
On Sun, Nov 26, 2017 at 12:29 PM, Nathaniel Smith wrote:
> On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum
> wrote:
> > On Sat, Nov 25, 2017 at 1:05 PM, David Mertz wrote:
> >>
> >> FWIW, on a side point. I use 'yield' and 'yield from' ALL THE TIME in
> real
> >> code. Probably 80% of those w
On Sun, Nov 26, 2017 at 6:51 PM, Guido van Rossum wrote:
> On Sun, Nov 26, 2017 at 12:29 PM, Nathaniel Smith wrote:
[..]
>> - async/await has associated thread-global state like
>> sys.set_coroutine_wrapper and sys.set_asyncgen_hooks. Generally async
>> libraries assume that they own these, and a
On 27 November 2017 at 06:29, Nathaniel Smith wrote:
> - In async/await, it's not obvious how to write leaf functions:
> 'await' is equivalent to 'yield from', but there's no equivalent to
> 'yield'. You have to jump through some hoops by writing a class with a
> custom __await__ method or using @
Changing subject line because this is way off to the side. Guido and
Nathaniel point out that you can do everything yield expressions do with
async/await *without* an explicit event loop. While I know that is true,
it feels like the best case is adding fairly considerable ugliness to the
code in
On Mon, Nov 27, 2017 at 2:20 PM, David Mertz wrote:
> Changing subject line because this is way off to the side. Guido and
> Nathaniel point out that you can do everything yield expressions do with
> async/await *without* an explicit event loop. While I know that is true, it
> feels like the bes
On 27 November 2017 at 13:20, David Mertz wrote:
>
> Imagining that 'yield' vanished from the language tomorrow, and I wanted
> to write the same thing with async/await, I think the best I can come up
> with is... actually, I just don't know who to do it without any `yield`.
>
I recently had to l
On 27 November 2017 at 06:22, Eric V. Smith wrote:
> 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 requir
On Sun, Nov 26, 2017 at 11:23 PM, Caleb Hattingh
wrote:
[..]
> I'd be very grateful if anyone can point out if my understanding of the
> above is incorrect. Private email is fine if you prefer not to post to the
> list.
It is correct. While 'yield from coro()', where 'coro()' is an 'async
def'
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 least
one should be a subclass of the other. Consider:
@dataclass
class Point3d:
x: float
y
On 27 November 2017 at 14:53, Yury Selivanov
wrote:
> It is correct. While 'yield from coro()', where 'coro()' is an 'async
> def' coroutine would make sense in some contexts, it would require
> coroutines to implement the iteration protocol. That would mean that
> you could write 'for x in cor
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 least
> one should be a subclass
18 matches
Mail list logo
