[Python-ideas] Re: Enum: determining if a value is valid

[Marco Sulla]

On Mon, 15 Mar 2021 at 20:49, Ethan Furman  wrote:
> Everything considered, I think I like allowing `__contains__` to verify both 
> names and values

What about Enum.values()?

> adding `default=` to the constructor for the value-based "gimme an 
> Enum or None" case

What's the use case, apart checking if the value is a "member" of the enum?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QMCYEAAZ3UELOL5G3T2T3G72KVKNAJV3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Richard Damon]

On 3/16/21 8:22 AM, Roland Puntaier via Python-ideas wrote:
> On Mon 21Mar15 15:18, Paul Bryan wrote:
>> On Mon, 2021-03-15 at 11:13 +0100, Roland Puntaier via Python-ideas
>> wrote:
>>
>>> I hesitate to call this proposal a language change. It is rather a
>>> syntactic allowance, like that of the trailing comma before the
>>> terminating token.
>>
>> If implemented, such a proposal would in fact require a change to the
>> language specification.
>
> Yes. What I meant is, that it is minor,
> equivalent to the `,]` change.
>
>>
>>> Can `x=[,1,2]` possibly be used for some future language feature,
>>> liking making `[,` a operator of its own? Considering that one has
>>> already decided that `,]` will not be allowed to have a separate
>>> meaning in the future, then, so should neither `[,`.
>>
>> It would be helpful to me to understand what friction you're currently
>> experiencing without such a change. I'm still struggling to appreciate
>> what the benefit would be, beyond aesthetic preference.
>
> I'd like to write
>
> def my_long_function_name(
>     , my_long_option_2 = "some default expression 1".split()
>     , my_long_option_1 = "some default expression 1".split()
>     ):
>     pass
>
> Then, I'd like to change the order of the lines without having to care
> to remove and add a comma.
>
> To allow `,]` was motivated by aesthetic preferences (PEP8).
> To allow both `[,`, and `,]` is aesthetically more neutral.
>
> So, the proposal is based on the already done `,]` language feature.
> The proposal adds some syntactic flexibility,
> which avoids errors in situations like the one described. 


My thought is that there is a line in the Zen

> There should be one-- and preferably only one --obvious way to do it.
That says that the langauge doesn't desire to be aesthetically neutral,
but will intentionally choose a preferred way to do something. Other
ways may be possible, if there is a good reason (and sometimes that is
just due to backwards compatibility when a better way to do something in
discovered).

This rule is even literally baked into the language due to 'import this'

I think this means you need a stronger motivation than you just want
another way to do the same thing,

-- 
Richard Damon

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/US5MJJA2KTE6QVCX5GR5ORZWLSICX6GO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Dataclass (or get_type_hints) wishlist item: Optional[...]

[Paul Bryan]

With some of the dataclass threads in python-ideas ongoing, I wanted to
add another to the fray.

There's an area where typing.get_type_hints on dataclass and __init__
produce inconsistent results. Example:

@dataclass
class Foo:
    x: int = None

>>> typing.get_type_hints(Foo)
{'x': }

>>> typing.get_type_hints(Foo.__init__)
{'x': typing.Optional[int], 'return': }

My wish list item would be for the dataclass annotations to match
__init__'s.

Rationale: by explicitly specifying a default value of a different
type, the resulting type annotation for the field should be a Union of
the specified type and the type of the default value.

I might go so far as to say this could be how the type hints of
function parameters should be encoded. Example to illustrate my
thoughts—it does not work this way presently:

def foo(x: str = 1):
    ...

>>> typing.get_type_hints(foo)
{'x': typing.Union[str, int]}

This example could be construed as an error that a static type checker
should catch and flag; if this is the consensus, then I fall back on
the proposal to only supporting Union[type, None]—i.e.
Optional[type]—which is how get_type_hints performs currently.

Thoughts?

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PC6RHDXNRIDBRDJAPXR5W32OCT7AQ4SO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Multiple dispatch transpilation

[David Mertz]

I quite like multiple dispatch. It's odd to claim it's not OOP, since a
relatively old object-oriented system, the Common Lisp Object System (CLOS)
uses this as it's fundamental construct.

A long time ago, I wrote about and created an example library for
multimethods. Lots of other folks have done so as well. Mine was old enough
to precede decorators, which I think is the best way to express it in
modern Python. Guido had demonstrated a simple system when decorators were
pretty new.

While I would like an implementation added to `functools`, I think it's
exceptionally unlikely it would have anything to do with speeding up
Python. It's a nice way to express certain programs, but not any slower or
faster than other styles.

On Tue, Mar 16, 2021, 6:13 PM Greg Ewing 
wrote:

> On 17/03/21 2:54 am, Marvin van Aalst wrote:
> > it
> > should in principle be possible to transform the code from
> > |Class.method|to |method(class:type)|, *before compilation*essentially
> > allowing the same optimizations.
>
> I don't think this transformation would help with anything.
> If the static analysis can work out what class of object a name
> refers to, and what methods and attributes it has, it can
> generate code that is just as efficient.
>
> --
> Greg
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZEWMGYXCXXRMXRJJ32TQP3U5V2OLMRGX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7OPNZAUPBLJDSKVZP6BW3XAJREGSRXJE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Eric V. Smith]

Okay, I'll do that. Thanks!

Eric

On 3/16/2021 6:10 PM, Guido van Rossum wrote:
That's a really good question. I think that `__match_args__` should 
*only* contain the non-kw-only args, so that you would have to write 
`case C(a, c, b=b, d=d)` to match on all four attributes (but 
typically you'd probably just write `case C(a, c)` -- that's about the 
same as `case C(a, c, b=_, d=_)` except it doesn't even care whether b 
and d are set at all.


On Tue, Mar 16, 2021 at 1:36 PM Eric V. Smith > wrote:


And now I have a question for you, Guido.

I'm looking at the code and I see the additions for
__match_args__. Is there any bad interaction between this proposal
and the match statement? I assume __match_args__ be the re-ordered
arguments to __init__, but I want to make sure.

So this:

@dataclasses.dataclass
class C:
 a: Any
 b: Any = field(kw_only=True)
 c: Any
 d: Any = field(kw_only=True)

Which generates:

def __init__(self, a, c, *, b, d):

Would have __match_args__ equal to ('a', 'c', 'b', 'd'), right?
Even though the repr would have fields in order a, b, c, d.

Eric

On 3/15/2021 7:45 PM, Guido van Rossum wrote:

Good proposal! I have a few questions.

On Mon, Mar 15, 2021 at 2:22 PM Eric V. Smith mailto:e...@trueblade.com>> wrote:

[I'm sort of loose with the terms field, parameter, and
argument here.
Forgive me: I think it's still understandable. Also I'm not
specifying
types here, I'm using Any everywhere. Use your imagination and
substitute real types if it helps you.]

Here's version 2 of my proposal:

There have been many requests to add keyword-only fields to
dataclasses.
These fields would result in __init__ parameters that are
keyword-only.

In a previous proposal, I suggested also including positional
arguments
for dataclasses. That proposal is at

https://mail.python.org/archives/list/python-ideas@python.org/message/I3RKK4VINZUBCGF2TBJN6HTDV3PVUEUQ/



. After some discussion, I think it's clear that positional
arguments
aren't going to work well with dataclasses. The deal breaker
for me is
that the generated repr would either not work with eval(), or
it would
contain fields without names (since they're positional).
There are
additional concerns mentioned in that thread. Accordingly,
I'm going to
drop positional arguments from this proposal.

Basically, I want to add a flag to each field, stating
whether the field
results in a normal parameter or a keyword-only parameter to
__init__.
Then when I'm generating __init__, I'll examine those flags
and put the
normal arguments first, followed by the keyword-only ones.

The trick becomes: how do you specify what type of parameter
each field
represents?


What attrs does
---

First, here's what attrs does. There's a parameter to their
attr.ib()
function (the moral equivalent of dataclasses.field()) named
kw_only,
which if set, marks the field as being keyword-only. From
https://www.attrs.org/en/stable/examples.html#keyword-only-attributes

:

 >>> @attr.s
... class A:
... a = attr.ib(kw_only=True)
 >>> A()
Traceback (most recent call last):
   ...
TypeError: A() missing 1 required keyword-only argument: 'a'
 >>> A(a=1)
A(a=1)

There's also a parameter to attr.s (the equivalent of
dataclasses.dataclass), also named kw_only, which if true
marks every
field as being keyword-only:

 >>> @attr.s(kw_only=True)
... class A:
... a = attr.ib()
... b = attr.ib()
 >>> A(1, 2)
Traceback (most recent call last):
   ...
TypeError: __init__() takes 1 positional argument but 3 were
given
 >>> A(a=1, b=2)
A(a=1, b=2)


dataclasses proposal


I propose to adopt both of these methods
(dataclass(kw_ony=True) and
field(kw_only=True) in dataclasses. The above example would
become:

 >>> @dataclasses.dataclass
... class A:
... a: Any = field(kw_only=True)

 >>> @dataclasses.dataclass(kw_only=True)
... class A:
... a: Any
... b: Any

But, I'd also like to make this a little easier to use,
especially in
the case where you're defining a data

[Python-ideas] Re: Multiple dispatch transpilation

[Greg Ewing]

On 17/03/21 2:54 am, Marvin van Aalst wrote:
it 
should in principle be possible to transform the code from 
|Class.method|to |method(class:type)|, *before compilation*essentially 
allowing the same optimizations.


I don't think this transformation would help with anything.
If the static analysis can work out what class of object a name
refers to, and what methods and attributes it has, it can
generate code that is just as efficient.

--
Greg

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZEWMGYXCXXRMXRJJ32TQP3U5V2OLMRGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Guido van Rossum]

That's a really good question. I think that `__match_args__` should *only*
contain the non-kw-only args, so that you would have to write `case C(a, c,
b=b, d=d)` to match on all four attributes (but typically you'd probably
just write `case C(a, c)` -- that's about the same as `case C(a, c, b=_,
d=_)` except it doesn't even care whether b and d are set at all.

On Tue, Mar 16, 2021 at 1:36 PM Eric V. Smith  wrote:

> And now I have a question for you, Guido.
>
> I'm looking at the code and I see the additions for __match_args__. Is
> there any bad interaction between this proposal and the match statement? I
> assume __match_args__ be the re-ordered arguments to __init__, but I want
> to make sure.
>
> So this:
> @dataclasses.dataclass
> class C:
>  a: Any
>  b: Any = field(kw_only=True)
>  c: Any
>  d: Any = field(kw_only=True)
>
> Which generates:
>
> def __init__(self, a, c, *, b, d):
> Would have __match_args__ equal to ('a', 'c', 'b', 'd'), right? Even
> though the repr would have fields in order a, b, c, d.
>
> Eric
> On 3/15/2021 7:45 PM, Guido van Rossum wrote:
>
> Good proposal! I have a few questions.
>
> On Mon, Mar 15, 2021 at 2:22 PM Eric V. Smith  wrote:
>
>> [I'm sort of loose with the terms field, parameter, and argument here.
>> Forgive me: I think it's still understandable. Also I'm not specifying
>> types here, I'm using Any everywhere. Use your imagination and
>> substitute real types if it helps you.]
>>
>> Here's version 2 of my proposal:
>>
>> There have been many requests to add keyword-only fields to dataclasses.
>> These fields would result in __init__ parameters that are keyword-only.
>>
>> In a previous proposal, I suggested also including positional arguments
>> for dataclasses. That proposal is at
>>
>> https://mail.python.org/archives/list/python-ideas@python.org/message/I3RKK4VINZUBCGF2TBJN6HTDV3PVUEUQ/
>> . After some discussion, I think it's clear that positional arguments
>> aren't going to work well with dataclasses. The deal breaker for me is
>> that the generated repr would either not work with eval(), or it would
>> contain fields without names (since they're positional). There are
>> additional concerns mentioned in that thread. Accordingly, I'm going to
>> drop positional arguments from this proposal.
>>
>> Basically, I want to add a flag to each field, stating whether the field
>> results in a normal parameter or a keyword-only parameter to __init__.
>> Then when I'm generating __init__, I'll examine those flags and put the
>> normal arguments first, followed by the keyword-only ones.
>>
>> The trick becomes: how do you specify what type of parameter each field
>> represents?
>>
>>
>> What attrs does
>> ---
>>
>> First, here's what attrs does. There's a parameter to their attr.ib()
>> function (the moral equivalent of dataclasses.field()) named kw_only,
>> which if set, marks the field as being keyword-only. From
>> https://www.attrs.org/en/stable/examples.html#keyword-only-attributes :
>>
>>  >>> @attr.s
>> ... class A:
>> ... a = attr.ib(kw_only=True)
>>  >>> A()
>> Traceback (most recent call last):
>>...
>> TypeError: A() missing 1 required keyword-only argument: 'a'
>>  >>> A(a=1)
>> A(a=1)
>>
>> There's also a parameter to attr.s (the equivalent of
>> dataclasses.dataclass), also named kw_only, which if true marks every
>> field as being keyword-only:
>>
>>  >>> @attr.s(kw_only=True)
>> ... class A:
>> ... a = attr.ib()
>> ... b = attr.ib()
>>  >>> A(1, 2)
>> Traceback (most recent call last):
>>...
>> TypeError: __init__() takes 1 positional argument but 3 were given
>>  >>> A(a=1, b=2)
>> A(a=1, b=2)
>>
>>
>> dataclasses proposal
>> 
>>
>> I propose to adopt both of these methods (dataclass(kw_ony=True) and
>> field(kw_only=True) in dataclasses. The above example would become:
>>
>>  >>> @dataclasses.dataclass
>> ... class A:
>> ... a: Any = field(kw_only=True)
>>
>>  >>> @dataclasses.dataclass(kw_only=True)
>> ... class A:
>> ... a: Any
>> ... b: Any
>>
>> But, I'd also like to make this a little easier to use, especially in
>> the case where you're defining a dataclass that has some normal fields
>> and some keyword-only fields. Using the attrs approach, you'd need to
>> declare the keyword-only fields using the "=field(kw_only=True)" syntax,
>> which I think is needlessly verbose, especially when you have many
>> keyword-only fields.
>>
>> The problem is that if you have 1 normal parameter and 10 keyword-only
>> ones, you'd be forced to say:
>>
>> @dataclasses.dataclass
>> class LotsOfFields:
>>  a: Any
>>  b: Any = field(kw_only=True, default=0)
>>  c: Any = field(kw_only=True, default='foo')
>>  d: Any = field(kw_only=True)
>>  e: Any = field(kw_only=True, default=0.0)
>>  f: Any = field(kw_only=True)
>>  g: Any = field(kw_only=True, default=())
>>  h: Any = field(kw_only=True, default='bar')
>>  i: Any = field(kw_only=True, default=3+4j)

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Ethan Furman]

On 3/16/21 1:19 PM, Brendan Barnwell wrote:

On 2021-03-16 06:20, Eric V. Smith wrote:



I'd like to avoid field() as much as possible. I think it's just too
easy to miss what it's doing, since it has many arguments. And I'd like
to make it easy to have a style that encourages all non-keyword-only
fields to come first.


 From my perspective it's quite the contrary.  `field` is an actual
function call and its arguments may affect its behavior in the way that
arguments generally affect function calls.  This thing with a dummy
attribute holding a magic value whose sequential position in the class
body influences *different* attributes based on their *relative*
sequential position. . . I find that much more confusing and strange.
I think Simão's version where you give a class-level default for
keyword-only-ness and then override it with field() arguments where
necessary is much cleaner.


I agree with Eric.  The class body is basically a vertical representation of 
the horizontal `__init__` header.  As such, `KW_ONLY` and (maybe in the future) 
POS_ONLY match very nicely.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S6EMN2BDFZMESALHLAPLZDUGN2BJL7LF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Brendan Barnwell]

On 2021-03-16 06:20, Eric V. Smith wrote:

I'd like to avoid field() as much as possible. I think it's just too
easy to miss what it's doing, since it has many arguments. And I'd like
to make it easy to have a style that encourages all non-keyword-only
fields to come first.


	From my perspective it's quite the contrary.  `field` is an actual 
function call and its arguments may affect its behavior in the way that 
arguments generally affect function calls.  This thing with a dummy 
attribute holding a magic value whose sequential position in the class 
body influences *different* attributes based on their *relative* 
sequential position. . . I find that much more confusing and strange.  I 
think Simão's version where you give a class-level default for 
keyword-only-ness and then override it with field() arguments where 
necessary is much cleaner.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SWOLR3XPQ4PZ6UYFZEWVJVIJHDBHBUIV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enum: determining if a value is valid

[Ethan Furman]

On 3/16/21 11:43 AM, Matt Wozniski wrote:

On Tue, Mar 16, 2021, 2:39 PM Marco Sulla wrote:

On Tue, 16 Mar 2021 at 05:38, Matt Wozniski wrote:



Color.from_value(1)  # returns Color.RED


What if I have an alias?


Aliases are different names for a single Enum member, so a by-value search is 
unaffected by them.


That's a problem with any attempt to find an enum member by value,
since values aren't guaranteed to be unique. With either proposal,
we'd just need to pick one - probably the one that appears first
in the class dict.


This is incorrect.  Enum values are unique -- there is only one member that 
will be returned for any given value.  Aliases are additional names for that 
one member:

from enum import Enum

class Color(Enum):
RED = 1
GREEN = 2
BLUE = 3
REDD = 1# to support a silly misspelling

>>> Color.RED


>>> Color(1)


>>> Color['RED']


>>> Color['REDD']


Notice that 'REDD' returns the RED member.  There is no member named REDD in 
Color.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XBGO35VFGC7CQLIZJTKH6EAXEKCJJQRC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Eric V. Smith]

And now I have a question for you, Guido.

I'm looking at the code and I see the additions for __match_args__. Is 
there any bad interaction between this proposal and the match statement? 
I assume __match_args__ be the re-ordered arguments to __init__, but I 
want to make sure.


So this:

@dataclasses.dataclass
class C:
 a: Any
 b: Any = field(kw_only=True)
 c: Any
 d: Any = field(kw_only=True)

Which generates:

def __init__(self, a, c, *, b, d):

Would have __match_args__ equal to ('a', 'c', 'b', 'd'), right? Even 
though the repr would have fields in order a, b, c, d.


Eric

On 3/15/2021 7:45 PM, Guido van Rossum wrote:

Good proposal! I have a few questions.

On Mon, Mar 15, 2021 at 2:22 PM Eric V. Smith > wrote:


[I'm sort of loose with the terms field, parameter, and argument
here.
Forgive me: I think it's still understandable. Also I'm not
specifying
types here, I'm using Any everywhere. Use your imagination and
substitute real types if it helps you.]

Here's version 2 of my proposal:

There have been many requests to add keyword-only fields to
dataclasses.
These fields would result in __init__ parameters that are
keyword-only.

In a previous proposal, I suggested also including positional
arguments
for dataclasses. That proposal is at

https://mail.python.org/archives/list/python-ideas@python.org/message/I3RKK4VINZUBCGF2TBJN6HTDV3PVUEUQ/



. After some discussion, I think it's clear that positional arguments
aren't going to work well with dataclasses. The deal breaker for
me is
that the generated repr would either not work with eval(), or it
would
contain fields without names (since they're positional). There are
additional concerns mentioned in that thread. Accordingly, I'm
going to
drop positional arguments from this proposal.

Basically, I want to add a flag to each field, stating whether the
field
results in a normal parameter or a keyword-only parameter to
__init__.
Then when I'm generating __init__, I'll examine those flags and
put the
normal arguments first, followed by the keyword-only ones.

The trick becomes: how do you specify what type of parameter each
field
represents?


What attrs does
---

First, here's what attrs does. There's a parameter to their attr.ib()
function (the moral equivalent of dataclasses.field()) named kw_only,
which if set, marks the field as being keyword-only. From
https://www.attrs.org/en/stable/examples.html#keyword-only-attributes

:

 >>> @attr.s
... class A:
... a = attr.ib(kw_only=True)
 >>> A()
Traceback (most recent call last):
   ...
TypeError: A() missing 1 required keyword-only argument: 'a'
 >>> A(a=1)
A(a=1)

There's also a parameter to attr.s (the equivalent of
dataclasses.dataclass), also named kw_only, which if true marks every
field as being keyword-only:

 >>> @attr.s(kw_only=True)
... class A:
... a = attr.ib()
... b = attr.ib()
 >>> A(1, 2)
Traceback (most recent call last):
   ...
TypeError: __init__() takes 1 positional argument but 3 were given
 >>> A(a=1, b=2)
A(a=1, b=2)


dataclasses proposal


I propose to adopt both of these methods (dataclass(kw_ony=True) and
field(kw_only=True) in dataclasses. The above example would become:

 >>> @dataclasses.dataclass
... class A:
... a: Any = field(kw_only=True)

 >>> @dataclasses.dataclass(kw_only=True)
... class A:
... a: Any
... b: Any

But, I'd also like to make this a little easier to use, especially in
the case where you're defining a dataclass that has some normal
fields
and some keyword-only fields. Using the attrs approach, you'd need to
declare the keyword-only fields using the "=field(kw_only=True)"
syntax,
which I think is needlessly verbose, especially when you have many
keyword-only fields.

The problem is that if you have 1 normal parameter and 10
keyword-only
ones, you'd be forced to say:

@dataclasses.dataclass
class LotsOfFields:
 a: Any
 b: Any = field(kw_only=True, default=0)
 c: Any = field(kw_only=True, default='foo')
 d: Any = field(kw_only=True)
 e: Any = field(kw_only=True, default=0.0)
 f: Any = field(kw_only=True)
 g: Any = field(kw_only=True, default=())
 h: Any = field(kw_only=True, default='bar')
 i: Any = field(kw_only=True, default=3+4j)
 j: Any = field(kw_only=True, default=10)
 k: Any = field(kw_only=True)

That's way too verbose for me.

Ideally

[Python-ideas] Re: Enum: determining if a value is valid

[Matt Wozniski]

That's a problem with any attempt to find an enum member by value, since
values aren't guaranteed to be unique. With either proposal, we'd just need
to pick one - probably the one that appears first in the class dict.

On Tue, Mar 16, 2021, 2:39 PM Marco Sulla 
wrote:

> On Tue, 16 Mar 2021 at 05:38, Matt Wozniski  wrote:
> > Color.from_value(1)  # returns Color.RED
>
> What if I have an alias?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/NQ535PUFCWRBBN5QVTGB7QOBNJNJJEPO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/B7PEYLOVWD7KOI4SUUXLU224N6XAJ2JR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enum: determining if a value is valid

[Marco Sulla]

On Tue, 16 Mar 2021 at 05:38, Matt Wozniski  wrote:
> Color.from_value(1)  # returns Color.RED

What if I have an alias?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NQ535PUFCWRBBN5QVTGB7QOBNJNJJEPO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Eric V. Smith]

On 3/16/2021 12:16 PM, Ricky Teachey wrote:
On Tue, Mar 16, 2021 at 11:59 AM Eric V. Smith > wrote:


On 3/16/2021 10:06 AM, Ricky Teachey wrote:

...
I think I prefer it, too. But what about using something like
`mark=dataclasses.KW_ONLY` rather than `kw_only=True` (in the
field constructor)? So it isn't an on/off switch and as to leave
open the door for positional arguments? Is that door to be
totally closed? I'm not here to argue in favor of it necessarily,
just asking whether we really want to close the door more tightly
against it than we have to.


I don't see how my proposal prohibits a future use of positional
arguments, much as '/' was added after '*' for positional
arguments for functions.

Eric


Here I am only trying to help by pointing out a few things that might 
be worth considering. However I am FULLY willing to be told "Rick: 
we've been designing language features a long time and, trust me, none 
of this a big deal." :)
I hope I'm not coming off as unappreciative of anyone's comments. I 
asked for them! And it's because of comments on the first version of 
this proposal that I've modified it to become this one.


It doesn't prohibit it, but choosing `kw_only` as the argument name 
(in both dataclasses.dataclass and dataclasses.field) semantically 
limits it to only being used as an on/off switch for a kw-only 
setting. Later, if it became desirable to add positional only, you'd 
need to add another separate on/off setting for it (say, `posit_only`) 
and then you'd end up in situations where the flag combos could be in 
conflict, and you have to check for that conflict:


kw_only=True, posit_only=True

The above would be an invalid combination. So it doesn't prohibit it 
but it makes it a bit harder to add it later.


That's what my previous proposal suggested, and I still think it's okay. 
I think "kw_only=True" is clearer than "mark=dataclasses.KW_ONLY". I 
don't think field(kw_only=True) will be used very often, and I think 
field(posit_only=True) would be used almost never. So I'm going to 
optimize the API for the more common usage.


And I don't mind checking for invalid combinations. There's already 
plenty of that in dataclasses, just check out the charts at the top of 
dataclasses.py and look for "raise".


There's also lots of this checking already in Python:

open('foo', 'b', encoding='utf-8')

Gives:

ValueError: binary mode doesn't take an encoding argument

Eric



And is there another possible "setting" possibly a bit exotic, 
maybe something that would end up being specific to dataclasses... 
that would also exclude OR require one or both of either/or kw_only 
and posit_only...? I am not sure, but maybe there is. And in that case 
you'd end up with a third on/off switch, and some other set of 
possibly ponderous checking:


kw_only=True, exotic_setting=True
posit_only=True, exotic_setting=True

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going 
home or actually going home." - Happy Chandler





--
Eric V. Smith

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/36O5LCMLDWP6NZZQIEFUA2DMTNOVA7N3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Eric V. Smith]

This was discussed on this thread: 
https://mail.python.org/archives/list/python-ideas@python.org/message/I3RKK4VINZUBCGF2TBJN6HTDV3PVUEUQ/


Ultimately the thing that doomed it for me was the repr that would be 
required for eval(repr(dataclass_instance)) to work. You'd have to drop 
the field name, combined with re-ordering the parameters. It just seemed 
ugly, and it's not a battle I'm willing to fight while trying to 
keyword-only in to 3.10.


But I believe this current proposal is a subset of that one, and it 
could be added in the future if demand is high.


Also, note that attrs doesn't support this, and I don't think we need to 
be blazing a trail here.


Eric

On 3/16/2021 12:17 PM, Abdulla Al Kathiri wrote:
Why don’t we also add dataclasses.POS_ONLY as well? Anything before it 
is positional argument.


@dataclasses.dataclass
class LotsOfFields:
    x: Any
    y: Any
    z: Any
    _:dataclasses.POS_ONLY
    a: Any
    __: dataclasses.KW_ONLY
    b: Any = 0
    c: Any = 'foo'
    d: Any
    e: Any = 0.0
    f: Any
    g: Any = ()
    h: Any = 'bar'
    i: Any = 3+4j
    j: Any = 10
    k: Any

The generated __init__ would look like:

def __init__(self, x, y, z, /, a, *, b=0, c='foo', d, e=0.0, f, g=(), 
h='bar', i=3+4j, j=10, k):


Similar to dataclasses.KW_ONLY, you can use dataclasses.POS_ONLY only 
once. It should always come before dataclasses.KW_ONLY. Anything else, 
it should raise an error. If dataclasses.POS_ONLY came right after the 
class declaration (no instance attribute preceding it), an error is 
generated similar to what we have right now. Inheritance is build up 
(from super class to sub class) of three groups of arguments: pos_only 
arguments together, then mixed arguments, and then kw_only arguments. 
repr should work the same way. We would like to reconstruct the object 
from repr. We don’t want too much change from current behavior.


Lets create a class that inherits from the above class..

@dataclasses.dataclass
class LessFields(LotsOfFields):
x2: Any
_: dataclasses.POS_ONLY
a2: Any
__:dataclasses.KW_ONLY
b2: Any

The generated __init__ would look like:

def __init__(self, x, y, z, x2, /, a, a2, *, b=0, c='foo', d, e=0.0, 
f, g=(), h='bar', i=3+4j, j=10, k, b2):


Another class..

@dataclasses.dataclass
Class EvenLessFields(LessFields):
a3: Any
_: dataclasses.KW_ONLY
b3: Any = 9

The generated __init__ would look like:

def __init__(self, x, y, z, x2, /, a, a2, a3, *, b=0, c='foo', d, 
e=0.0, f, g=(), h='bar', i=3+4j, j=10, k, b2, b3=9):


All arguments are ordered from the super super class until 
the subclass all in their respective path or group of arguments.


Abdulla

On 16 Mar 2021, at 1:18 AM, Eric V. Smith > wrote:


@dataclasses.dataclass
class LotsOfFields:
    a: Any
    _: dataclasses.KW_ONLY
    b: Any = 0
    c: Any = 'foo'
    d: Any
    e: Any = 0.0
    f: Any
    g: Any = ()
    h: Any = 'bar'
    i: Any = 3+4j
    j: Any = 10
    k: Any

Which I think is a lot clearer.

The generated __init__ would look like:

def __init__(self, a, *, b=0, c='foo', d, e=0.0, f, g=(), h='bar', 
i=3+4j, j=10, k):



___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5SA2XVRAGCPHTVTFO3WCD36BDARY2MTA/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Eric V. Smith

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S7C35R5MGM5JSL2BPLO5CNCE2VRXNGB7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Abdulla Al Kathiri]

Why don’t we also add dataclasses.POS_ONLY as well? Anything before it is 
positional argument. 

@dataclasses.dataclass
class LotsOfFields:
x: Any 
y: Any
z: Any 
_:dataclasses.POS_ONLY 
a: Any
__: dataclasses.KW_ONLY
b: Any = 0
c: Any = 'foo'
d: Any
e: Any = 0.0
f: Any
g: Any = ()
h: Any = 'bar'
i: Any = 3+4j
j: Any = 10
k: Any

The generated __init__ would look like:

def __init__(self, x, y, z, /, a, *, b=0, c='foo', d, e=0.0, f, g=(), h='bar', 
i=3+4j, j=10, k):

Similar to dataclasses.KW_ONLY, you can use dataclasses.POS_ONLY only once. It 
should always come before dataclasses.KW_ONLY. Anything else, it should raise 
an error. If dataclasses.POS_ONLY came right after the class declaration (no 
instance attribute preceding it), an error is generated similar to what we have 
right now. Inheritance is build up (from super class to sub class) of three 
groups of arguments: pos_only arguments together, then mixed arguments, and 
then kw_only arguments. repr should work the same way. We would like to 
reconstruct the object from repr. We don’t want too much change from current 
behavior. 

Lets create a class that inherits from the above class.. 

@dataclasses.dataclass
class LessFields(LotsOfFields):
x2: Any
_: dataclasses.POS_ONLY 
a2: Any 
__:dataclasses.KW_ONLY 
b2: Any 

The generated __init__ would look like:

def __init__(self, x, y, z, x2, /, a, a2, *, b=0, c='foo', d, e=0.0, f, g=(), 
h='bar', i=3+4j, j=10, k, b2):

Another class.. 

@dataclasses.dataclass 
Class EvenLessFields(LessFields):
a3: Any
_: dataclasses.KW_ONLY
b3: Any = 9 

The generated __init__ would look like:

def __init__(self, x, y, z, x2, /, a, a2, a3, *, b=0, c='foo', d, e=0.0, f, 
g=(), h='bar', i=3+4j, j=10, k, b2, b3=9):

All arguments are ordered from the super super class until the subclass all in 
their respective path or group of arguments. 

Abdulla 

> On 16 Mar 2021, at 1:18 AM, Eric V. Smith  wrote:
> 
> @dataclasses.dataclass
> class LotsOfFields:
> a: Any
> _: dataclasses.KW_ONLY
> b: Any = 0
> c: Any = 'foo'
> d: Any
> e: Any = 0.0
> f: Any
> g: Any = ()
> h: Any = 'bar'
> i: Any = 3+4j
> j: Any = 10
> k: Any
> 
> Which I think is a lot clearer.
> 
> The generated __init__ would look like:
> 
> def __init__(self, a, *, b=0, c='foo', d, e=0.0, f, g=(), h='bar', i=3+4j, 
> j=10, k):

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5SA2XVRAGCPHTVTFO3WCD36BDARY2MTA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Ricky Teachey]

On Tue, Mar 16, 2021 at 11:59 AM Eric V. Smith  wrote:

> On 3/16/2021 10:06 AM, Ricky Teachey wrote:
>
> ...
> I think I prefer it, too. But what about using something like
> `mark=dataclasses.KW_ONLY` rather than `kw_only=True` (in the field
> constructor)? So it isn't an on/off switch and as to leave open the door
> for positional arguments? Is that door to be totally closed? I'm not here
> to argue in favor of it necessarily, just asking whether we really want to
> close the door more tightly against it than we have to.
>
>
> I don't see how my proposal prohibits a future use of positional
> arguments, much as '/' was added after '*' for positional arguments for
> functions.
>
> Eric
>

Here I am only trying to help by pointing out a few things that might be
worth considering. However I am FULLY willing to be told "Rick: we've been
designing language features a long time and, trust me, none of this a big
deal." :)

It doesn't prohibit it, but choosing `kw_only` as the argument name (in
both dataclasses.dataclass and dataclasses.field) semantically limits it to
only being used as an on/off switch for a kw-only setting. Later, if it
became desirable to add positional only, you'd need to add another separate
on/off setting for it (say, `posit_only`) and then you'd end up in
situations where the flag combos could be in conflict, and you have to
check for that conflict:

kw_only=True, posit_only=True

The above would be an invalid combination. So it doesn't prohibit it but it
makes it a bit harder to add it later.

And is there another possible "setting" possibly a bit exotic, maybe
something that would end up being specific to dataclasses... that would
also exclude OR require one or both of either/or kw_only and posit_only...?
I am not sure, but maybe there is. And in that case you'd end up with a
third on/off switch, and some other set of possibly ponderous checking:

kw_only=True, exotic_setting=True
posit_only=True, exotic_setting=True

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7TI6GS6BFYA3TYAZHOVMZ7WSOBZROE57/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Eric V. Smith]

On 3/16/2021 10:06 AM, Ricky Teachey wrote:
On Tue, Mar 16, 2021 at 10:03 AM Eric V. Smith > wrote:


On 3/16/2021 9:48 AM, Ricky Teachey wrote:

On Tue, Mar 16, 2021 at 9:23 AM Eric V. Smith mailto:e...@trueblade.com>> wrote:

On 3/16/2021 7:01 AM, Simão Afonso @ Powertools Tech wrote:
>> The problem is that if you have 1 normal parameter and 10
keyword-only
>> ones, you'd be forced to say:
>>
>> @dataclasses.dataclass
>> class LotsOfFields:
>>       a: Any
>>       b: Any = field(kw_only=True, default=0)
>>       c: Any = field(kw_only=True, default='foo')
>>       d: Any = field(kw_only=True)
>>       e: Any = field(kw_only=True, default=0.0)
>>       f: Any = field(kw_only=True)
>>       g: Any = field(kw_only=True, default=())
>>       h: Any = field(kw_only=True, default='bar')
>>       i: Any = field(kw_only=True, default=3+4j)
>>       j: Any = field(kw_only=True, default=10)
>>       k: Any = field(kw_only=True)
>>
>> That's way too verbose for me.


Here's another option I just thought of, that might have some
strengths:

@dataclasses.dataclass
class LotsOfFields:
     #  first member assumed to be kw_or_posit unless marked
otherwise
 a: Any
     #  start kw only here because `mark= dataclasses.KW_ONLY`
 b: Any = field(default=0, mark=dataclasses.KW_ONLY)
     #  all members following above line continue to be kw_only
 c: Any = 'foo'
 d: Any
 e: Any = 0.0
 f: Any
 g: Any = ()
 h: Any = 'bar'
 i: Any = 3+4j
 j: Any = 10
 k: Any

I changed the kw argument name from `kw_only` to `mark`.

The idea is that every supplied member (above, members c through
k) is assumed to have the same `mark` as the most recently
explicitly designated field (above, member b). Or, if there has
not yet been an explicitly designated `mark` for a member, the
first field (above, member a) is assumed to be
`dataclasses.KW_OR_POSIT` (or whatever other singleton name makes
sense).

In this way we only have to use the field() call once, we can go
back and forth, we eliminate a line like `_:
dataclasses.KW_OPTIONAL` that to some people might be a bit
inscrutable, and we leave the door open to support positional
arguments in the future (perhaps through something like `mark=
dataclasses.KW_OR_POSIT`) if it becomes desirable for some reason.


I prefer the "_: dataclasses.KW_ONLY" version, because it more
closely matches "def foo(a, *, b, c, d)". The "everything else is
a keyword" isn't attached to one parameter, it's between parameters.

Eric


I think I prefer it, too. But what about using something like 
`mark=dataclasses.KW_ONLY` rather than `kw_only=True` (in the field 
constructor)? So it isn't an on/off switch and as to leave open the 
door for positional arguments? Is that door to be totally closed? I'm 
not here to argue in favor of it necessarily, just asking whether we 
really want to close the door more tightly against it than we have to.


I don't see how my proposal prohibits a future use of positional 
arguments, much as '/' was added after '*' for positional arguments for 
functions.


Eric

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LJME45OZEWP3WEKE5YWQWMGQKX5FICOX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Multiple dispatch transpilation

[Todd]

Numba already provides as-needed JIT compilation and type annotations. I am
not sure it supports multiple dispatch but if that was useful it could be
added with decorators.  I am not sure integrating this into the language
will help much.

On Tue, Mar 16, 2021, 10:07 Marvin van Aalst 
wrote:

> Hi fellow Pythonistas!
>
> A colleague of mine recently got me involved in the Julia language and
> while I was really impressed by the performance, the complete lack of OOP
> and thus bad discoverability (not to mention all their unicode function
> names) for me leaves a lot to be desired.
>
> TL;DR:
>
> Julia uses a type-based multi-method system (multiple dispatch), that
> because of type-stability allows JIT compilation of very efficient code.
> Since Pythons single-dispatch classes are a subset of that system, it
> should in principle be possible to transform the code from Class.method
> to method(class:type), *before compilation* essentially allowing the same
> optimizations. For the other arguments could utilize the existing type
> annotations. The idea would be to allow this via decorators etc for code
> where it makes sense (e.g. high volume number crunching), while keeping the
> rest of the language free from JIT compiler issues and other nuisances.
>
> Very long version:
>
> Julia is a high level dynamically typed language, that often approaches or
> matches C performance. This is due to type-based multiple dispatch and
> type-stability through specialization. However, the coolest part is that
> the type system is set-theoretic, which makes it unnecessary to repeat
> functions for related types. This page
> 
> and this blog post
> 
> give a good explanations of how this works. *However*, since with their
> multiple dispatch system everything can be written without using classes,
> they have opted to not include any OOP. This leads to a very high amount of
> functions that are accessible in the global namespace and hinders one to
> explore the packages in the usual, playful way that probably all of us are
> used to. So the usual resort is to have to read documentation. What a shame
> ;)
>
> Since all of Julia needs to be JIT compiled, importing packages usually
> takes a lot of time (it does some pre-compilation on first import, which
> takes a lot longer, but depending on the system its still quite a while). A
> quick search for "time-to-first-plot" or "latency" will be plenty to show
> that this is quite a nuisance. I believe that its perfectly fine for some
> code to be interpreted, as the python community has frequently shown, so
> that might not be the best approach. Only performance-critical code needs
> to be fast. In our world this is usually done by offloading the quick stuff
> into C, but in that case it gets really hard to expand those libraries
> (e.g. numpy has its own dispatch system, so pypy cannot help it as much as
> it could). Also extending numerical types for arrays is basically
> impossible.
>
> So how can we try to retain usability and still gain the performance for
> the code that needs it? In general I'd argue that multiple dispatch and JIT
> compilation is fine, as our performance critical code usually runs for very
> long times, so the added overhead is minimal. If the code doesn't take a
> large amount of time, you probably don't need to optimize it anyway. I'd
> argue that one way to get there would be to "transpile" our Python code by
> inserting a step before compilation that utilizes the type annotations that
> already exist and then pulls typed versions out of the classes. So e.g.
> Class.method(x:int) would be transformed into the typed version 
> method(class:type,
> x:int), from where on multiple dispatch could be run.
>
> This would have the further advantage, that in Julia it can be very hard
> to see, which attributes a type should have and which methods necessarily
> have to be defined in order to guarantee library compatibility. In OOP, we
> can easily achieve that by defining the type as an abstract base class.
>
> A lot of the statements about Julia here come from Jeff Bezansons (one of
> the Julia main devs PhD thesis)
> . It's a quick read and I
> would in general recommend reading it.
>
> On the one hand, in general I think that julia is more compiler-friendly
> than it is user or tooling-friendly (since methods for your type can be
> defined outside of the scope of the class, its very hard for your IDE to
> tell you if that function you just misspelled doesn't exist). On the other
> hand, its quite nice to be able to create a custom array and just push it
> through all the numerical libraries in a very efficient way, which works
> because you have defined all the required methods. I think this way of
> speeding up things would be cooler than enabling static t

[Python-ideas] Re: allow initial comma

[Guido van Rossum]

Hi Roland,

Can you please give up on this particular idea? You've given it a fair try,
and nobody is showing any interest in changing Python to match your
proposal. That's usually a good indication that it will Never Happen, and
if you keep arguing beyond that point you tend to be written off as out of
tune.

Personally, I'd like to remind you that when I designed Python my ideal was
to use punctuation in ways that are similar to the way it is used in plain
English, with exceptions only for forms commonly found in many other
programming languages such as foo.bar. Leading with a comma is most
definitely not something one would do in English.

I hope to see you continue brainstorming on other ideas.

--Guido

On Fri, Mar 12, 2021 at 5:21 AM roland.puntaier--- via Python-ideas <
python-ideas@python.org> wrote:

> I had posted this as https://github.com/python/peps/issues/1867
> The discussion so far is below.
>
> Please make some arguments.
>
> The major point to me is, that the symmetry is broken,
> which leads to extra editing actions, like removing the comma in the first
> line.
> I guess, this was the reason to allow the comma after the last line/entry:
> `[1,2,]`.
> ``[,1,2]`` should also be allowed, too.
>
> The best argument is one that says: less or more effort in this or that
> situation.
> For example, with `[1,2,]`, in line-wise formatting,
> one can do without special action at the last line (removing the comma
> there).
>
> All code from previous versions of Python would still work
> after a `[,1,2]` syntax allowance were introduced.
>
>
>
> =
> rpuntaie wrote:
>
> =
>
> Allow initial comma
> ===
>
> Final comma works:
>
> t = (
>  1,
>  2,
> )
> x = [
>  1,
>  2,
> ]
> y = {
>  1,
>  2,
> }
> z = {
>  1:11,
>  2:22,
> }
> def fun(
>   a,
>   b,
>  ):
>   pass
>
> Initial comma does not work:
>
> t = (
>  , 1
>  , 2
> )
> x = [
>  , 1
>  , 2
> ]
> y = {
>  , 1
>  , 2
>  }
> z = {
>  , 1:11
>  , 2:22
>  }
> def fun(
>  , a
>  , b
>  ):
>   pass
>
>
> To make the syntax symmetric in this regard\
> gives more freedom to format the code.
>
> I occasionally found the restriction an unnecessary nuisance.
>
> Before writing a PEP, I would like to discuss,
>
> -   whether something like that has been proposed already?
> -   what counter-arguments there could be?
>
>
> =
> pxeger wrote:
>
> =
>
> This is not the appropriate place to propose language changes.
> Try the [python-ideas](
> https://mail.python.org/mailman3/lists/python-ideas.python.org/)
> mailing list. However, I don't think you'll get anyone to agree.
>
> What kind of code style are you using where you want to put commas at
> the start of the line? That is totally non-standard
> (see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and
> confusing.
>
> Arbitrary symmetry is not a good reason for changing the language. We
> don't have a `tnirp` function just for the sake of symmetry with
> `print` because it would be pointless and add extra complication
>
>
>
> =
> rpuntaie wrote:
>
> =
>
> I surely agree, that not ignoring the sequence is essential. Else one
> would loose identifier space and thus information. I would never have
> the idea to make all permutations of `p.r.i.n.t` point to the same
> function. Therefore you just made a bad example.
>
> But the comma is just a separator. Why did they allow to have the
> comma before a closing bracket/parenthesis/brace? Because of symmetry
> between lines, is my guess.
>
> Occasionally one sees many spaces just the have the final comma
> aligned vertically. That could be avoided by placing the comma at the
> beginning.
>
> I personally also have a macro in the editor that evaluates a line in
> the parameter list, but drops an initial comma before doing that.
> Therefore this is my preferred formatting.
>
> I don't think that [PEP](https://www.python.org/dev/peps/pep-0008)
> is wrong. I just don't want to be restricted by unnecessary rules.
> Rules need to have a reason beyond someone dictating them. If that is
> the case, I follow them, because I see the reason, but not because
> someone dictates them.
>
> I'll go to
> [Python Ide as](
> https://mail.python.org/mailman3/lists/python-ideas.python.org/),
> then

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Ricky Teachey]

On Tue, Mar 16, 2021 at 10:03 AM Eric V. Smith  wrote:

> On 3/16/2021 9:48 AM, Ricky Teachey wrote:
>
> On Tue, Mar 16, 2021 at 9:23 AM Eric V. Smith  wrote:
>
>> On 3/16/2021 7:01 AM, Simão Afonso @ Powertools Tech wrote:
>> >> The problem is that if you have 1 normal parameter and 10 keyword-only
>> >> ones, you'd be forced to say:
>> >>
>> >> @dataclasses.dataclass
>> >> class LotsOfFields:
>> >>   a: Any
>> >>   b: Any = field(kw_only=True, default=0)
>> >>   c: Any = field(kw_only=True, default='foo')
>> >>   d: Any = field(kw_only=True)
>> >>   e: Any = field(kw_only=True, default=0.0)
>> >>   f: Any = field(kw_only=True)
>> >>   g: Any = field(kw_only=True, default=())
>> >>   h: Any = field(kw_only=True, default='bar')
>> >>   i: Any = field(kw_only=True, default=3+4j)
>> >>   j: Any = field(kw_only=True, default=10)
>> >>   k: Any = field(kw_only=True)
>> >>
>> >> That's way too verbose for me.
>>
>
> Here's another option I just thought of, that might have some strengths:
>
> @dataclasses.dataclass
> class LotsOfFields:
>  #  first member assumed to be kw_or_posit unless marked otherwise
>  a: Any
>  #  start kw only here because `mark= dataclasses.KW_ONLY`
>  b: Any = field(default=0, mark=dataclasses.KW_ONLY)
>  #  all members following above line continue to be kw_only
>  c: Any = 'foo'
>  d: Any
>  e: Any = 0.0
>  f: Any
>  g: Any = ()
>  h: Any = 'bar'
>  i: Any = 3+4j
>  j: Any = 10
>  k: Any
>
> I changed the kw argument name from `kw_only` to `mark`.
>
> The idea is that every supplied member (above, members c through k) is
> assumed to have the same `mark` as the most recently explicitly designated
> field (above, member b). Or, if there has not yet been an explicitly
> designated `mark` for a member, the first field (above, member a) is
> assumed to be `dataclasses.KW_OR_POSIT` (or whatever other singleton name
> makes sense).
>
> In this way we only have to use the field() call once, we can go back and
> forth, we eliminate a line like `_:  dataclasses.KW_OPTIONAL` that to some
> people might be a bit inscrutable, and we leave the door open to support
> positional arguments in the future (perhaps through something like `mark=
> dataclasses.KW_OR_POSIT`) if it becomes desirable for some reason.
>
> I prefer the "_: dataclasses.KW_ONLY" version, because it more closely
> matches "def foo(a, *, b, c, d)". The "everything else is a keyword" isn't
> attached to one parameter, it's between parameters.
>
> Eric
>

I think I prefer it, too. But what about using something like
`mark=dataclasses.KW_ONLY` rather than `kw_only=True` (in the field
constructor)? So it isn't an on/off switch and as to leave open the door
for positional arguments? Is that door to be totally closed? I'm not here
to argue in favor of it necessarily, just asking whether we really want to
close the door more tightly against it than we have to.


>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
>
>
> --
> Eric V. Smith
>
>
---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HFJMOEB6RHFICS63V3WIYEVWJEASMFR5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Multiple dispatch transpilation

[Marvin van Aalst]

Hi fellow Pythonistas!

A colleague of mine recently got me involved in the Julia language and 
while I was really impressed by the performance, the complete lack of 
OOP and thus bad discoverability (not to mention all their unicode 
function names) for me leaves a lot to be desired.


TL;DR:

Julia uses a type-based multi-method system (multiple dispatch), that 
because of type-stability allows JIT compilation of very efficient code. 
Since Pythons single-dispatch classes are a subset of that system, it 
should in principle be possible to transform the code from 
|Class.method|to |method(class:type)|, *before compilation*essentially 
allowing the same optimizations. For the other arguments could utilize 
the existing type annotations. The idea would be to allow this via 
decorators etc for code where it makes sense (e.g. high volume number 
crunching), while keeping the rest of the language free from JIT 
compiler issues and other nuisances.


Very long version:

Julia is a high level dynamically typed language, that often approaches 
or matches C performance. This is due to type-based multiple dispatch 
and type-stability through specialization. However, the coolest part is 
that the type system is set-theoretic, which makes it unnecessary to 
repeat functions for related types. This page 
and 
this blog post 
give 
a good explanations of how this works. *However*, since with their 
multiple dispatch system everything can be written without using 
classes, they have opted to not include any OOP. This leads to a very 
high amount of functions that are accessible in the global namespace and 
hinders one to explore the packages in the usual, playful way that 
probably all of us are used to. So the usual resort is to have to read 
documentation. What a shame ;)


Since all of Julia needs to be JIT compiled, importing packages usually 
takes a lot of time (it does some pre-compilation on first import, which 
takes a lot longer, but depending on the system its still quite a 
while). A quick search for "time-to-first-plot" or "latency" will be 
plenty to show that this is quite a nuisance. I believe that its 
perfectly fine for some code to be interpreted, as the python community 
has frequently shown, so that might not be the best approach. Only 
performance-critical code needs to be fast. In our world this is usually 
done by offloading the quick stuff into C, but in that case it gets 
really hard to expand those libraries (e.g. numpy has its own dispatch 
system, so pypy cannot help it as much as it could). Also extending 
numerical types for arrays is basically impossible.


So how can we try to retain usability and still gain the performance for 
the code that needs it? In general I'd argue that multiple dispatch and 
JIT compilation is fine, as our performance critical code usually runs 
for very long times, so the added overhead is minimal. If the code 
doesn't take a large amount of time, you probably don't need to optimize 
it anyway. I'd argue that one way to get there would be to "transpile" 
our Python code by inserting a step before compilation that utilizes the 
type annotations that already exist and then pulls typed versions out of 
the classes. So e.g. |Class.method(x:int)|would be transformed into the 
typed version |method(class:type, x:int)|, from where on multiple 
dispatch could be run.


This would have the further advantage, that in Julia it can be very hard 
to see, which attributes a type should have and which methods 
necessarily have to be defined in order to guarantee library 
compatibility. In OOP, we can easily achieve that by defining the type 
as an abstract base class.


A lot of the statements about Julia here come from Jeff Bezansons (one 
of the Julia main devs PhD thesis) 
. It's a quick read and I 
would in general recommend reading it.


On the one hand, in general I think that julia is more compiler-friendly 
than it is user or tooling-friendly (since methods for your type can be 
defined outside of the scope of the class, its very hard for your IDE to 
tell you if that function you just misspelled doesn't exist). On the 
other hand, its quite nice to be able to create a custom array and just 
push it through all the numerical libraries in a very efficient way, 
which works because you have defined all the required methods. I think 
this way of speeding up things would be cooler than enabling static 
typing which many people are asking for, as we still retain the 
flexibility (or might even increase it in the case of arrays), while 
greatly speeding up code.


Since I only understand all these things at a high level, I'm sure that 
I've greatly simplified or misrepresented something. The real hope here 
is that someone smarter than me is inspired by that idea and man

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Eric V. Smith]

On 3/16/2021 9:48 AM, Ricky Teachey wrote:
On Tue, Mar 16, 2021 at 9:23 AM Eric V. Smith > wrote:


On 3/16/2021 7:01 AM, Simão Afonso @ Powertools Tech wrote:
>> The problem is that if you have 1 normal parameter and 10
keyword-only
>> ones, you'd be forced to say:
>>
>> @dataclasses.dataclass
>> class LotsOfFields:
>>       a: Any
>>       b: Any = field(kw_only=True, default=0)
>>       c: Any = field(kw_only=True, default='foo')
>>       d: Any = field(kw_only=True)
>>       e: Any = field(kw_only=True, default=0.0)
>>       f: Any = field(kw_only=True)
>>       g: Any = field(kw_only=True, default=())
>>       h: Any = field(kw_only=True, default='bar')
>>       i: Any = field(kw_only=True, default=3+4j)
>>       j: Any = field(kw_only=True, default=10)
>>       k: Any = field(kw_only=True)
>>
>> That's way too verbose for me.


Here's another option I just thought of, that might have some strengths:

@dataclasses.dataclass
class LotsOfFields:
     #  first member assumed to be kw_or_posit unless marked otherwise
 a: Any
     #  start kw only here because `mark= dataclasses.KW_ONLY`
 b: Any = field(default=0, mark=dataclasses.KW_ONLY)
     #  all members following above line continue to be kw_only
 c: Any = 'foo'
 d: Any
 e: Any = 0.0
 f: Any
 g: Any = ()
 h: Any = 'bar'
 i: Any = 3+4j
 j: Any = 10
 k: Any

I changed the kw argument name from `kw_only` to `mark`.

The idea is that every supplied member (above, members c through k) is 
assumed to have the same `mark` as the most recently explicitly 
designated field (above, member b). Or, if there has not yet been an 
explicitly designated `mark` for a member, the first field (above, 
member a) is assumed to be `dataclasses.KW_OR_POSIT` (or whatever 
other singleton name makes sense).


In this way we only have to use the field() call once, we can go back 
and forth, we eliminate a line like `_: dataclasses.KW_OPTIONAL` that 
to some people might be a bit inscrutable, and we leave the door open 
to support positional arguments in the future (perhaps through 
something like `mark= dataclasses.KW_OR_POSIT`) if it becomes 
desirable for some reason.


I prefer the "_: dataclasses.KW_ONLY" version, because it more closely 
matches "def foo(a, *, b, c, d)". The "everything else is a keyword" 
isn't attached to one parameter, it's between parameters.


Eric



---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going 
home or actually going home." - Happy Chandler


--
Eric V. Smith

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DGEIF34WIYRA3PZNIQ3JKVSQD2SIWAMM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Ricky Teachey]

On Tue, Mar 16, 2021 at 9:23 AM Eric V. Smith  wrote:

> On 3/16/2021 7:01 AM, Simão Afonso @ Powertools Tech wrote:
> >> The problem is that if you have 1 normal parameter and 10 keyword-only
> >> ones, you'd be forced to say:
> >>
> >> @dataclasses.dataclass
> >> class LotsOfFields:
> >>   a: Any
> >>   b: Any = field(kw_only=True, default=0)
> >>   c: Any = field(kw_only=True, default='foo')
> >>   d: Any = field(kw_only=True)
> >>   e: Any = field(kw_only=True, default=0.0)
> >>   f: Any = field(kw_only=True)
> >>   g: Any = field(kw_only=True, default=())
> >>   h: Any = field(kw_only=True, default='bar')
> >>   i: Any = field(kw_only=True, default=3+4j)
> >>   j: Any = field(kw_only=True, default=10)
> >>   k: Any = field(kw_only=True)
> >>
> >> That's way too verbose for me.
>

Here's another option I just thought of, that might have some strengths:

@dataclasses.dataclass
class LotsOfFields:
 #  first member assumed to be kw_or_posit unless marked otherwise
 a: Any
 #  start kw only here because `mark= dataclasses.KW_ONLY`
 b: Any = field(default=0, mark=dataclasses.KW_ONLY)
 #  all members following above line continue to be kw_only
 c: Any = 'foo'
 d: Any
 e: Any = 0.0
 f: Any
 g: Any = ()
 h: Any = 'bar'
 i: Any = 3+4j
 j: Any = 10
 k: Any

I changed the kw argument name from `kw_only` to `mark`.

The idea is that every supplied member (above, members c through k) is
assumed to have the same `mark` as the most recently explicitly designated
field (above, member b). Or, if there has not yet been an explicitly
designated `mark` for a member, the first field (above, member a) is
assumed to be `dataclasses.KW_OR_POSIT` (or whatever other singleton name
makes sense).

In this way we only have to use the field() call once, we can go back and
forth, we eliminate a line like `_:  dataclasses.KW_OPTIONAL` that to some
people might be a bit inscrutable, and we leave the door open to support
positional arguments in the future (perhaps through something like `mark=
dataclasses.KW_OR_POSIT`) if it becomes desirable for some reason.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HDLXG5MOPYVTHTPQBEU4VPLL4OL3V3GS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Eric V. Smith]

On 3/16/2021 7:01 AM, Simão Afonso @ Powertools Tech wrote:

The problem is that if you have 1 normal parameter and 10 keyword-only
ones, you'd be forced to say:

@dataclasses.dataclass
class LotsOfFields:
  a: Any
  b: Any = field(kw_only=True, default=0)
  c: Any = field(kw_only=True, default='foo')
  d: Any = field(kw_only=True)
  e: Any = field(kw_only=True, default=0.0)
  f: Any = field(kw_only=True)
  g: Any = field(kw_only=True, default=())
  h: Any = field(kw_only=True, default='bar')
  i: Any = field(kw_only=True, default=3+4j)
  j: Any = field(kw_only=True, default=10)
  k: Any = field(kw_only=True)

That's way too verbose for me.

Why not:


@dataclasses.dataclass(kw_only=True)
class LotsOfFields:
  a: Any = field(kw_only=False)
  b: Any = 0
  c: Any = 'foo'
  d: Any
  e: Any = 0.0
  f: Any
  g: Any = ()
  h: Any = 'bar'
  i: Any = 3+4j
  j: Any = 10
  k: Any


I'd like to avoid field() as much as possible. I think it's just too 
easy to miss what it's doing, since it has many arguments. And I'd like 
to make it easy to have a style that encourages all non-keyword-only 
fields to come first.


Eric

Avoids weirdness with pragma and singletons that make the order of
parameters important.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/W7VT6KBZETMVBBCU722VTZWP6777SFX4/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Eric V. Smith

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PMSBCGLZSGFNRGV6LQFEWVJXT5D6XBSQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses keyword-only fields, take 2

[Simão Afonso]

> The problem is that if you have 1 normal parameter and 10 keyword-only 
> ones, you'd be forced to say:
> 
> @dataclasses.dataclass
> class LotsOfFields:
>  a: Any
>  b: Any = field(kw_only=True, default=0)
>  c: Any = field(kw_only=True, default='foo')
>  d: Any = field(kw_only=True)
>  e: Any = field(kw_only=True, default=0.0)
>  f: Any = field(kw_only=True)
>  g: Any = field(kw_only=True, default=())
>  h: Any = field(kw_only=True, default='bar')
>  i: Any = field(kw_only=True, default=3+4j)
>  j: Any = field(kw_only=True, default=10)
>  k: Any = field(kw_only=True)
> 
> That's way too verbose for me.

Why not:

> @dataclasses.dataclass(kw_only=True)
> class LotsOfFields:
>  a: Any = field(kw_only=False)
>  b: Any = 0
>  c: Any = 'foo'
>  d: Any
>  e: Any = 0.0
>  f: Any
>  g: Any = ()
>  h: Any = 'bar'
>  i: Any = 3+4j
>  j: Any = 10
>  k: Any

Avoids weirdness with pragma and singletons that make the order of
parameters important.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/W7VT6KBZETMVBBCU722VTZWP6777SFX4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Ned Batchelder]

On 3/16/21 8:22 AM, Roland Puntaier via Python-ideas wrote:

I'd like to write

def my_long_function_name(
    , my_long_option_2 = "some default expression 1".split()
    , my_long_option_1 = "some default expression 1".split()
    ):
    pass



Why not write this instead?:

   def my_long_function_name(
    my_long_option_2="some default expression 1".split(),
    my_long_option_1="some default expression 1".split(),
    ):
    pass

It has all the advantages you are looking for, plus it isn't 
odd-looking, and it's already supported.


--Ned.


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/N5WEMH7FMX5RX55YH2YV6OBDBWLAQL5L/
Code of Conduct: http://python.org/psf/codeofconduct/