Re: [Python-Dev] Second post: PEP 557, Data Classes
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
Re: [Python-Dev] Using async/await in place of yield expression
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
Re: [Python-Dev] Second post: PEP 557, Data Classes
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
Re: [Python-Dev] Using async/await in place of yield expression
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'
Re: [Python-Dev] Second post: PEP 557, Data Classes
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
Re: [Python-Dev] Using async/await in place of yield expression
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
Re: [Python-Dev] Using async/await in place of yield expression
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
[Python-Dev] Using async/await in place of yield expression
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
Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression
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 @
Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression
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
Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression
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
Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression
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
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 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_
Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression
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
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 was called "cmp", but "compare"
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 combinations an immediate
Re: [Python-Dev] Second post: PEP 557, Data Classes
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