[Python-ideas] Re: dataclasses: position-only and keyword-only fields

On 3/13/2021 6:41 AM, Matt Wozniski wrote: On Fri, Mar 12, 2021, 11:55 PM Eric V. Smith > wrote: There have been many requests to add keyword-only fields to dataclasses. These fields would result in __init__ parameters that are keyword-only. As

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

Sorry, Matt: I meant to credit you by name, but forgot to during my final edit. I still don't like the verbosity and the look of 'with' statements or classes. Or the fact that some of the fields are indented relative to others. And should also mention that Ethan Furman suggested using '*'

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

On 3/13/2021 6:06 AM, Matt del Valle wrote: As I understand it your proposal would allow for the following, right? import dataclasses @dataclasses.dataclass class Parent: pos= dataclasses.POS_ARG a: int normal= dataclasses.NORMAL_ARG c: bool = False kw= dataclasses.KW_ARG e:

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

Thanks Eric. That's a really good summary of the ideas thrown around up to this point in the other thread. I'm not overly fussed about the precise syntax we use, though I do have a preference for using an extra level of scope to mark fields as pos/kw only, either with context managers or with

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

On Fri, Mar 12, 2021, 11:55 PM Eric V. Smith wrote: > There have been many requests to add keyword-only fields to dataclasses. > These fields would result in __init__ parameters that are keyword-only. > As long as I'm doing this, I'd like to add positional-only fields as well. > Have there also

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

Fwiw I read Eric's entire proposal (I like it) but totally missed the presence of single, double, triple underscores. Which caused me to be very confused reading Matt De Valle's reply, until I went back and noticed them, and the lightbulb went on. Based on that experience, and also Matt's

[Python-ideas] Re: Implicit line continuation for method chaining

Chris Angelico wrote: > On Sat, Mar 13, 2021 at 1:46 PM Peter Ludemann peter.ludem...@gmail.com wrote: > > It's not clear to me what surprising behaviors there would be. Javascript > > seems to do OK with optional semicolons - presumably its algorithm is > > similar to what BCPL used. (Or

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

On 3/13/2021 9:33 AM, Ricky Teachey wrote: Fwiw I read Eric's entire proposal (I like it) but totally missed the presence of single, double, triple underscores. Which caused me to be very confused reading Matt De Valle's reply, until I went back and noticed them, and the lightbulb went on.

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

Another option is something like this (building on Ricky Teachey's suggestion): from dataclasses import ArgumentMarker, dataclass @dataclass class C: a: Any # positional-only __pos__: ArgumentMarker b: Any # normal __kw_only__: ArgumentMarker c: Any # keyword-only The

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

On 3/13/2021 10:22 AM, Jelle Zijlstra wrote: Another option is something like this (building on Ricky Teachey's suggestion): from dataclasses import ArgumentMarker, dataclass @dataclass class C:     a: Any  # positional-only     __pos__: ArgumentMarker     b: Any  # normal     __kw_only__:

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

+1 to Matt's points here. I get the desire for symmetry with / and * in params, but I'm not convinced it's useful enough to warrant the complexity of the approaches being proposes. I think a @dataclass(..., kwonly=True) would solve > 90% of the issues with dataclass usability today. On Sat,

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

I forgot to add: I'm uncertain about your suggestion of a required order of fields, based on argument type. I'll have to think about it some more. I'm working on a sample implementation, and I'm going to wait and see how it works before putting much more thought into it. Eric On 3/13/2021

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

I don’t like the idea of going back and fourth for positional and keyword arguments. The positional arguments have to stay at the top of some variable (be it anything, e.g, __pos: Any). The mixed stays in between the two markers. And the keyword arguments come after yet another predefined

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

On 3/13/2021 2:51 PM, Abdulla Al Kathiri wrote: I don’t like the idea of going back and fourth for positional and keyword arguments. The positional arguments have to stay at the top of some variable (be it anything, e.g, __pos: Any). The mixed stays in between the two markers. And the keyword

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

Oops, sent a reply too soon. On Sat, Mar 13, 2021 at 3:14 PM Eric V. Smith wrote: > The thing is, even without being able to switch back and forth within a > single dataclass, you could achieve the same thing with inheritance: > ... > > In both cases, you'd get re-ordered fields in __init__,

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

On Sat, Mar 13, 2021 at 3:14 PM Eric V. Smith wrote: > On 3/13/2021 2:51 PM, Abdulla Al Kathiri wrote: > > I don’t like the idea of going back and fourth for positional and keyword > arguments. The positional arguments have to stay at the top of some > variable (be it anything, e.g, __pos: Any).

[Python-ideas] Re: Add an export keyword to better manage __all__

> > > I'm not sure that I would let `export` use the existing `__all__` > machinery anyway. Maybe in a module that uses `export` there should be a > different rule that disallows importing anything from it that isn't > explicitly exported, regardless of what form of import is used (`__all__` >