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

[Matt Wozniski]

On Fri, Mar 12, 2021, 11:55 PM Eric V. Smith  wrote:

> I should mention another idea that showed up on python-ideas, at
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/WBL4X46QG2HY5ZQWYVX4MXG5LK7QXBWB/
> . It would allow you to specify the flag via code like:
>
> @dataclasses.dataclass
> class Parent:
>  with dataclasses.positional():
>  a: int
>  c: bool = False
>  with dataclasses.keyword():
>  e: list
>
> I'm not crazy about it, and it looks like it would require stack
> inspection to get it to work, but I mention it here for completeness.


I think stack inspection could be avoided if we did something like:

```
@dataclasses.dataclass
class Parent:
 class pos(dataclasses.PositionalOnly):
 a: int
 c: bool = False
 class kw(dataclasses.KeywordOnly):
 e: list
```

Like your proposal, the names for the two inner classes can be anything,
but they must be unique. The metaclass would check if a field in the new
class's namespace was a subclass of PositionalOnly or KeywordOnly, and if
so recurse into its annotations to collect more fields.

This still seems hacky, but it seems to read reasonably nicely, and behaves
obviously in the presence of subclassing.
___
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/IFE35VNDZH5YUNXY23I53QBDCUFB7GRQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

[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.]


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.


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


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


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

In dataclasses, these example become:

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

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

Aside from the name 'kw_only', which we can bikeshed about, I think 
these features are good, and I'd like to implement them as shown here.


But, I'd like to do two other things: make it easier to use, and support 
positional-only fields.


Since the second one is easier, let's tackle it first. I'd do the same 
thing as kw_only, but name it something like pos_only. Again, we can 
argue about the name. Like kw_only, you can either specify individual 
fields as positional-only, or declare that every field is 
positional-only. It would be an error to specify both kw_only and pos_only.


As far as making it simpler: I dislike needing to use 
field(kw_only=True), although it would certainly work. The problem is 
that if you have 1 normal parameter, and 10 keyword-only ones, you'd be 
forced to say:


@dataclasses.dataclass
class A:
    a: Any
    b: Any = field(kw_only=True, default=0)
    c: Any = field(kw_only=True, default='foo')
    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, I'd like something like this example:

@dataclasses.dataclass
class A:
    a: Any
    # pragma: KW_ONLY
    b: Any
    # pragma: POS_ONLY
    c: Any

And then b would become a keyword-only field and c would be 
positional-only. But we need some way of telling dataclasses.dataclass 
what's going on, since obviously pragmas are out.


I propose the following. I'll add 2 (or 3, keep reading) singletons to 
the dataclasses module: KW_ONLY and POS_ONLY. When scanning the 
__attribute__'s that define fields, fields with these types would be 
ignored, except for assigning the kw_only/pos_only/normal flag to fields 
declared after these singletons are used. So you'd get:


@dataclasses.dataclass
class A:
    a: Any
    _: dataclasses.KW_ONLY
    b: Any
    __: dataclasses.POS_ONLY
    c: Any

This would generate:
def __init__(self, c, /, a, *, b):

The names of the KW_ONLY and POS_ONLY fields don't matter, since they're 
discarded. But as you see above, they still need to be unique. I think _ 
is a fine name, and since KW_ONLY will be used much more than POS_ONLY, 
'_: dataclasses.KW_ONLY' would be the pythonic way of saying "the 
following fields are keyword-only".


I do think I'll add a third singleton to specify that subsequent fields 
are "normal" fields, neither keyword-only or positional-only. I don't 
know that we have a name for such a thing, let's call it NORMAL_ARG here 
and bikeshed it later. Then you could say:


@dataclasses.dataclass
class A:
    a: Any
    _: dataclasses.KW_ONLY
    b: Any
    __: dataclasses.POS_ONLY
    c: Any
    ___: dataclasses.NORMAL_ARG
    d: Any

Then a and d are "normal" fields, while b is keyword-only and c is 
positional-only. This would generate:

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

I normally wouldn't propose adding NORMAL_ARG, 

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

[Chris Angelico]

On Sat, Mar 13, 2021 at 1:46 PM Peter Ludemann  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 perhaps the surprising behaviors are trivial compared 
> to the other surprises that Javascript springs on people.)
>

Yes, right up until you try to do something like:

function foo() {
return
thing.goes.here()
}

which becomes extremely common with frameworks like React.js. There's
an implicit semicolon and a big block of dead code.

ChrisA
___
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/JOOXIPHT2LUVLU2OLWP7HP3IBQJJ4R5Q/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Peter Ludemann]

On Fri, 12 Mar 2021 at 18:27, Guido van Rossum  wrote:

> On Fri, Mar 12, 2021 at 6:23 PM Peter Ludemann 
> wrote:
>
>> [I wonder why C didn't adopt BCPL's convention for eliding semi-colons?
>> ...]
>>
>
> [Presumably because it caused too many surprising behaviors...]
>

My guess is that it would have been more work in the parser, and therefore
didn't fit with Unix "minimalism". ;)

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 perhaps the surprising behaviors are trivial
compared to the other surprises that Javascript springs on people.)


>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>
___
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/MJK7MMCZ2NVZM6OL3IWD3BXXAFYIYLMX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Fri, Mar 12, 2021 at 6:23 PM Peter Ludemann 
wrote:

> [I wonder why C didn't adopt BCPL's convention for eliding semi-colons?
> ...]
>

[Presumably because it caused too many surprising behaviors...]

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/4FN7WKW4BJP6XWJPQGFF63RYN2PU5JCC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Peter Ludemann]

Guido van Rossum wrote:
> Can we skip ahead to considering how to implement this? I can think of two
> approaches: either hack the lexer to special-case a newline followed by a
> period (which currently can never start a line), or redesign the syntax to
> allow NEWLINE INDENT ‘.’ . NEWLINE ‘.’  DEDENT at the
> end of an expression. Both have pros and cons.
> Discuss how this allows for certain typos to pass as valid syntax.

IIRC, BCPL's compiler would continue and expression on the next line if a line 
ended with an operator. E.g.:

x = a +
b

would parse like 
x = (a +
   b);

(I think this was a bit more general - if a line didn't end with ";", the 
parser would try adding a ";" and if that failed to parse, it would continue to 
the next line.)

This leads result in a different style for method-chaining:

y = x.rstrip("\n").
   split(":")[0].
   lower()

... and if you don't like ending lines with a ".", you could always add a 
parenthesis:

y = (x.rstrip("\n")
   .split(":")[0]
   .lower())

[I wonder why C didn't adopt BCPL's convention for eliding semi-colons? ...]
___
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/A344DHD4YD25DQFM2OYBNKU63HTHO4FN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

Yeah, all the shenanigans with `__all__` make it clear that it's the wrong
solution, and we should do something better.

Fortunately the PEG parser and its "soft keywords" feature (debuting for
match/case in 3.10) makes it much easier to do this.

I had thought about this and came up with similar syntax as you did
(`export def` etc.) but instead of writing
```
y = 2
export y
```
That's okay, but maybe we can do better, like this?
```
export y = 2
```
This could also be combined with a type annotation, e.g.
```
export y: int = 2
```
I'm not sure about the import+export syntax you gave, maybe something like
this instead?
```
import export foo
import foo, export bar, baz as export babaz
```
Hm, maybe your version is okay too -- just bikeshedding here. :-)

You write about auto-populating `__all__`. I am not aware of it ever
auto-populating. What are you referring to here? (The behavior that in the
absence of `__all__`, everything not starting with `_` is exported, is not
auto-population -- it's a default behavior implemented by `import *`, not
by the exporting module.)

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__` *only*
affects `import *`).

Maybe these ideas should be considered together with lazy import (another
thread here).

On Fri, Mar 12, 2021 at 3:08 PM Theia Vogel  wrote:

> Hi,
>
> I was refactoring some code today and ran into an issue that always bugs
> me with
> Python modules. It bugged me enough this time that I spent an hour banging
> out this
> potential proposal to add a new contextual keyword. Let me know what you
> think!
>
> Theia
>
>
> 
>
> A typical pattern for a python module is to have an __init__.py that looks
> something like:
>
> from .foo import (
> A,
> B,
> C,
> )
>
> from .bar import (
> D,
> E,
> )
>
> def baz():
> pass
>
> __all__ = [
> "A",
> "B",
> "C",
> "D",
> "E",
> "baz",
> ]
>
> This is annoying for a few reasons:
>
> 1. It requires name duplication
> a. It's easy for the top-level imports to get out of sync with __all__,
>meaning that __all__, instead of being useful for documentation, is
>actively misleading
> b. This encourages people to do `from .bar import *`, which screws up
> many
>linting tools like flake8, since they can't introspect the names,
> and
>also potentially allows definitions that have been deleted to
>accidentally persist in __all__.
> 2. Many symbol-renaming tools won't pick up on the names in __all__, as
> they're
>strings.
>
> Prior art:
>
> 
>
> # Rust
>
> Rust distinguishes between "use", which is a private import, "pub use",
> which is
> a globally public import, and "pub(crate) use", which is a library-internal
> import ("crate" is Rust's word for library)
>
>
> # Javascript
>
> In Javascript modules, there's an "export" keyword:
>
> export function foo() { ... }
>
> And there's a pattern called the "barrel export" that looks similar to a
> Python
> import, but additionally exports the imported names:
>
> export * from "./foo"; // re-exports all of foo's definitions
>
> Additionally, a module can be gathered and exported by name, but not in
> one line:
>
> import * as foo from "./foo";
> export { foo };
>
>
> # Python decorators
>
> People have written utility Python decorators that allow exporting a single
> function, such as this SO answer:
> https://stackoverflow.com/a/35710527/1159735
>
> import sys
>
> def export(fn):
> mod = sys.modules[fn.__module__]
> if hasattr(mod, '__all__'):
> mod.__all__.append(fn.__name__)
> else:
> mod.__all__ = [fn.__name__]
> return fn
>
> , which allows you to write:
>
> @export
> def foo():
> pass
>
> # __all__ == ["foo"]
>
> , but this doesn't allow re-exporting imported values.
>
>
> # Python implicit behavior
>
> Python already has a rule that, if __all__ isn't declared, all
> non-underscore-prefixed names are automatically exported. This is /ok/,
> but it's
> not very explicit (Zen) -- it's easy to accidentally "import sys" instead
> of
> "import sys as _sys" -- it makes doing the wrong thing the default state.
>
>
> Proposal:
>
> 
>
> Add a contextual keyword "export" that has meaning in three places:
>
> 1. Preceding an "import" statement, which directs all names imported by
> that
>statement to be added to __all__:
>
> import sys
> export import .foo
> export import (
> A,
> B,
> C,
> D
> ) from .bar
>
> # __all__ == ["foo", "A", "B", "C", "D"]

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

[Guido van Rossum]

On Fri, Mar 12, 2021 at 1:52 PM Ethan Furman  wrote:

> A question that comes up quite a bit on Stackoverflow is how to test to
> see if a value will result in an Enum member, preferably without having to
> go through the whole try/except machinery.
>
> A couple versions ago one could use a containment check:
>
>if 1 in Color:
>
> but than was removed as Enums are considered containers of members, not
> containers of the member values.


Maybe you were a bit too quick in deleting it. Was there a serious bug that
led to the removal? Could it be restored?


> It was also possible to define one's own `_missing_` method and have it
> return None or the value passed in, but that has also been locked down to
> either return a member or raise an exception.
>
> At this point I see three options:
>
> 1) add a `get(value, default=None)` to EnumMeta (similar to `dict.get()`
>

But the way to convert a raw value to an enum value is Color(1), not
Color[1], so Color.get(1) seems inconsistent.

Maybe you can just change the constructor so you can spell this as Color(1,
default=None) (and then check whether that's None)?


> 2) add a recipe to the docs
>

But what would the recipe say? Apparently you're looking for a one-liner,
since you reject the try/except solution.


> 3) do nothing
>

Always a good option. :-) Where's that StackOverflow item? How many upvotes
does it have?

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/QRDMKZBL54GU7A7OSDB5GG2HIAGCDTLE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Theia Vogel]

Hi,

I was refactoring some code today and ran into an issue that always bugs me with
Python modules. It bugged me enough this time that I spent an hour banging out 
this
potential proposal to add a new contextual keyword. Let me know what you think!

Theia



A typical pattern for a python module is to have an __init__.py that looks
something like:

from .foo import (
A,
B,
C,
)

from .bar import (
D,
E,
)

def baz():
pass

__all__ = [
"A",
"B",
"C",
"D",
"E",
"baz",
]

This is annoying for a few reasons:

1. It requires name duplication
a. It's easy for the top-level imports to get out of sync with __all__,
   meaning that __all__, instead of being useful for documentation, is
   actively misleading
b. This encourages people to do `from .bar import *`, which screws up many
   linting tools like flake8, since they can't introspect the names, and
   also potentially allows definitions that have been deleted to
   accidentally persist in __all__.
2. Many symbol-renaming tools won't pick up on the names in __all__, as they're
   strings.

Prior art:


# Rust

Rust distinguishes between "use", which is a private import, "pub use", which is
a globally public import, and "pub(crate) use", which is a library-internal
import ("crate" is Rust's word for library)


# Javascript

In Javascript modules, there's an "export" keyword:

export function foo() { ... }

And there's a pattern called the "barrel export" that looks similar to a Python
import, but additionally exports the imported names:

export * from "./foo"; // re-exports all of foo's definitions

Additionally, a module can be gathered and exported by name, but not in one 
line:

import * as foo from "./foo";
export { foo };


# Python decorators

People have written utility Python decorators that allow exporting a single
function, such as this SO answer: https://stackoverflow.com/a/35710527/1159735

import sys

def export(fn):
mod = sys.modules[fn.__module__]
if hasattr(mod, '__all__'):
mod.__all__.append(fn.__name__)
else:
mod.__all__ = [fn.__name__]
return fn

, which allows you to write:

@export
def foo():
pass

# __all__ == ["foo"]

, but this doesn't allow re-exporting imported values.


# Python implicit behavior

Python already has a rule that, if __all__ isn't declared, all
non-underscore-prefixed names are automatically exported. This is /ok/, but it's
not very explicit (Zen) -- it's easy to accidentally "import sys" instead of
"import sys as _sys" -- it makes doing the wrong thing the default state.


Proposal:


Add a contextual keyword "export" that has meaning in three places:

1. Preceding an "import" statement, which directs all names imported by that
   statement to be added to __all__:

import sys
export import .foo
export import (
A,
B,
C,
D
) from .bar

# __all__ == ["foo", "A", "B", "C", "D"]

2. Preceding a "def", "async def", or "class" keyword, directing that function
   or class's name to be added to __all__:

def private(): pass
export def foo(): pass
export async def async_foo(): pass
export class Foo: pass

# __all__ == ["foo", "async_foo", "Foo"]

3. Preceding a bare name at top-level, directing that name to be added to
   __all__:

x = 1
y = 2
export y

# __all__ == ["y"]


# Big Caveat

For this scheme to work, __all__ needs to not be auto-populated with names.
While the behavior is possibly suprising, I think the best way to handle this is
to have __all__ not auto-populate if an "export" keyword appears in the file.
While this is somewhat-implicit behavior, it seems reasonable to me to expect 
that
if a user uses "export", they are opting in to the new way of managing __all__.
Likewise, I think manually assigning __all__ when using "export" should raise
an error, as it would overwrite all previous exports and be very confusing.
___
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/HL3P7CXZX3U5SMNIJODL45BE6E72MWTI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 3/12/21 2:49 PM, Ricky Teachey wrote:

On Fri, Mar 12, 2021 at 4:52 PM Ethan Furman wrote:



A question that comes up quite a bit on Stackoverflow is how to test
to see if a value will result in an Enum member, preferably without
having to go through the whole try/except machinery.



Could this be an instance where match-case might become the canonical
solution?

I'm probably getting the syntax wrong, but maybe it would be something like:

match value:
 case MyEnum():
 assert isinstance(value, MyEnum)
 case _:
assert not isinstance(value, MyEnum)


The use case is when you have an unknown value that may or may not convert into 
an Enum member.  So a three-member Enum would look something like:

```python
match value:
case MyEnum():
pass
case 1|2|3:
value = MyEnum(value)
case _:
handle_error_or_use_default()
```

Seven lines of code.  try/except would be something like:

```python
try:
value = MyEnum(value)
except ValueError:
handle_error_or_use_default()
```

vs what I'm envisioning:

```python
value = MyEnum.get(value, some_default)
```

or maybe

```python
value = MyEnum.get(value)
if value is None:
handle_error()
```

--
~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/Z7C36KHOFDDM6REA4PN6GPPYOJ22DPBY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ricky Teachey]

On Fri, Mar 12, 2021 at 4:52 PM Ethan Furman  wrote:

> A question that comes up quite a bit on Stackoverflow is how to test to
> see if a value will result in an Enum member, preferably without having to
> go through the whole try/except machinery.
>
> A couple versions ago one could use a containment check:
>
>if 1 in Color:
>
> but than was removed as Enums are considered containers of members, not
> containers of the member values.  It was also possible to define one's own
> `_missing_` method and have it return None or the value passed in, but that
> has also been locked down to either return a member or raise an exception.
>
> At this point I see three options:
>
> 1) add a `get(value, default=None)` to EnumMeta (similar to `dict.get()`
>
> 2) add a recipe to the docs
>
> 3) do nothing
>
> Thoughts?
>
> --
> ~Ethan~


Could this be an instance where match-case might become the canonical
solution?

I'm probably getting the syntax wrong, but maybe it would be something like:

match value:
case MyEnum():
assert isinstance(value, MyEnum)
case _:
 assert not isinstance(value, MyEnum)


---
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/X3DJPKOEQ6IL5BUUS3Y25SNADM2UHYIM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

A question that comes up quite a bit on Stackoverflow is how to test to see if 
a value will result in an Enum member, preferably without having to go through 
the whole try/except machinery.

A couple versions ago one could use a containment check:

  if 1 in Color:

but than was removed as Enums are considered containers of members, not 
containers of the member values.  It was also possible to define one's own 
`_missing_` method and have it return None or the value passed in, but that has 
also been locked down to either return a member or raise an exception.

At this point I see three options:

1) add a `get(value, default=None)` to EnumMeta (similar to `dict.get()`

2) add a recipe to the docs

3) do nothing

Thoughts?

--
~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/N6C2ROUCSLEPPH34BTFQNQE4ZM63WUWC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Eric V. Smith]

On 3/12/2021 4:42 PM, Paul Bryan wrote:
Using your example (thanks, seeing a concrete example is helpful) it 
appears you can do it the SQL way in Python too:


x = (1
,2
,3
)


Right. It's just that no one would want to!

Eric




On Fri, 2021-03-12 at 16:35 -0500, Eric V. Smith wrote:

On 3/12/2021 3:37 PM, Greg Ewing wrote:

On 13/03/21 5:02 am, Ned Batchelder wrote:

I think the only reason anyone ever used leading commas to begin with
was because of languages that didn't allow a final trailing comma.
In those worlds, to keep the editing smooth, people moved the commas
to the beginning of the line,


Which doesn't help unless the language allows leading commas that
are ignored, and I've never seen a language like that.


Things are added to the end of lists more often than to the front. For
example, column names in SQL or parameters in Python.

Because SQL doesn't allow trailing commas, I've often seen things
written as:

select a
,b
,c
,d

Then when you want to add "e" to the end, you just duplicate the ",d"
row and change "d" to "e".

For Python, you'd do:

select(a,
b,
c,
d,
)

And then similarly add "e," to the end.

Anyway, since Python already allows trailing commas, I see no need to
add leading ones. Which is a feature I've never seen in any language,
either. And it would make it slightly easier to leave off the first
parameter.

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/R6AU26PL4QK5LFMW25PP2VUVLFSTDGX6/ 

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/TJVRA2VUX6UIK4KQGZ47W44OFCW65CM6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Paul Bryan]

Using your example (thanks, seeing a concrete example is helpful) it
appears you can do it the SQL way in Python too:

x = (1
,2
,3
)


On Fri, 2021-03-12 at 16:35 -0500, Eric V. Smith wrote:
> On 3/12/2021 3:37 PM, Greg Ewing wrote:
> > On 13/03/21 5:02 am, Ned Batchelder wrote:
> > > I think the only reason anyone ever used leading commas to begin
> > > with 
> > > was because of languages that didn't allow a final trailing
> > > comma.  
> > > In those worlds, to keep the editing smooth, people moved the
> > > commas 
> > > to the beginning of the line,
> > 
> > Which doesn't help unless the language allows leading commas that
> > are ignored, and I've never seen a language like that. 
> 
> Things are added to the end of lists more often than to the front.
> For 
> example, column names in SQL or parameters in Python.
> 
> Because SQL doesn't allow trailing commas, I've often seen things 
> written as:
> 
> select a
> ,b
> ,c
> ,d
> 
> Then when you want to add "e" to the end, you just duplicate the ",d"
> row and change "d" to "e".
> 
> For Python, you'd do:
> 
> select(a,
> b,
> c,
> d,
> )
> 
> And then similarly add "e," to the end.
> 
> Anyway, since Python already allows trailing commas, I see no need to
> add leading ones. Which is a feature I've never seen in any language,
> either. And it would make it slightly easier to leave off the first 
> parameter.
> 
> 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/R6AU26PL4QK5LFMW25PP2VUVLFSTDGX6/
> 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/TDAA4F7S55KS2UHDKJTN6SFBHKDGYTYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow trailing operators [was: allow initial comma]

[Ethan Furman]

On 3/12/21 9:04 AM, Henk-Jaap Wagenaar wrote:


(
     Q(user=user) |
     Q(is_deleted=True) |
)

I am happy to flesh this out more, but as this discussion was ongoing, I 
thought I would throw it out here and see what people think? Are there 
potential problems with this e.g. with parsing it?


Yes, there are major issues for the human parser: it looks like an error.  I 
suspect it would also contribute to errors.

--
~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/4CB5KJFWPE7N7XEYLO7FKDOECLUHHWMY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Eric V. Smith]

On 3/12/2021 3:37 PM, Greg Ewing wrote:

On 13/03/21 5:02 am, Ned Batchelder wrote:
I think the only reason anyone ever used leading commas to begin with 
was because of languages that didn't allow a final trailing comma.  
In those worlds, to keep the editing smooth, people moved the commas 
to the beginning of the line,


Which doesn't help unless the language allows leading commas that
are ignored, and I've never seen a language like that. 


Things are added to the end of lists more often than to the front. For 
example, column names in SQL or parameters in Python.


Because SQL doesn't allow trailing commas, I've often seen things 
written as:


select a
,b
,c
,d

Then when you want to add "e" to the end, you just duplicate the ",d" 
row and change "d" to "e".


For Python, you'd do:

select(a,
b,
c,
d,
)

And then similarly add "e," to the end.

Anyway, since Python already allows trailing commas, I see no need to 
add leading ones. Which is a feature I've never seen in any language, 
either. And it would make it slightly easier to leave off the first 
parameter.


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/R6AU26PL4QK5LFMW25PP2VUVLFSTDGX6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Greg Ewing]

On 13/03/21 5:02 am, Ned Batchelder wrote:
I think the only reason anyone ever used leading commas to begin with 
was because of languages that didn't allow a final trailing comma.  In 
those worlds, to keep the editing smooth, people moved the commas to the 
beginning of the line,


Which doesn't help unless the language allows leading commas that
are ignored, and I've never seen a language like that.

--
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/4E5NN7ENLKMOS2IBAPC7FUXIKU3JBFZE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 3/12/21 7:50 AM, Paul Bryan wrote:


My inclination would be to cede code formatting to a tool like Black and focus 
on function:
https://black.readthedocs.io/en/stable/


We still have to read it after Black munges it.

Like Paul said, add parentheses -- it works for method chaining, string 
concatenation, etc.

--
~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/M2IAKNCMJZZTF6WP674M2SD3U5VIMWP6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz]

I have written tens of thousands of lines of Pandas code, and I've taught
thousands of people to use Pandas. I've worked with the core developers of
Pandas as well.

This is the first time I've ever seen `\` line continuation used for fluent
programming style rather than just using parentheses as a way of expressing
a logical line.

On Fri, Mar 12, 2021, 10:41 AM Matt Williams  wrote:

> Hi,
>
> It's becoming more popular in Python to have interfaces which are built
> around method chaining as a way of applying operations to data. For example
> in pandas is moving more towards a default model where methods do not
> change the object in-place but instead return an altered version (or at
> least an altered view) of it.
>
> The major downside to method chaining is that it ends up creating long
> lines of code which can become hard to read. The two main solutions to this
> are 1) break down the chain and give the steps their own variable names and
> 2) split it over multiple lines using `\` as a line continuation.
>
> e.g.:
>
>   y = x.rstrip("\n").split(":")[0].lower()
>
> would become
>
>   y = x.rstrip("\n") \
>.split(":")[0] \
>.lower()
>
> I find the continuation character visually distracting, easy to forget and
> does not allow for line-by-line commenting (causing `SyntaxError:
> unexpected character after line continuation character`):
>
>   y = x.rstrip("\n") \
>.split(":")[0] \  # grab the key name
>.lower()
>
> My idea is to alter the syntax of Python to allow doing:
>
>   y = x.rstrip("\n")
>.split(":")[0]
>.lower()
>
> i.e., not requiring an explicit line continuation character in the case
> where the next line starts with a period.
>
> I've had a search through the archives and I couldn't see this discussion
> before. Feel free to point me to it if I've missed anything.
>
> Cheers,
> Matt
> ___
> 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/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
> 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/ZVRFLX5QK4C65KWE3U43HHCZSOXK23NJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow trailing operators [was: allow initial comma]

[Richard Damon]

Simple solution for trailing | is put False on the next line.

> On Mar 12, 2021, at 12:07 PM, Henk-Jaap Wagenaar  
> wrote:
> 
> 
> This is a definite tangent. Trailing commas are great for reducing git diffs, 
> not making errors when moving things around (missing commas, which e.g. in 
> strings causes concatenation) but I have often wondered whether the same 
> could be extended to (some?) logical or arithmetic operators, in particular:
> 
> Currently one has to write a logical expression as (using Django Q objects):
> (
>Q(user=user) |
>Q(is_deleted=True)
> )
> 
> and then removing/adding clauses is difficult, whereas if "trailing 
> operators" where allowed, there would be no such issue:
> 
> (
> Q(user=user) |
> Q(is_deleted=True) |
> ) 
> 
> Just like with trailing commas, the "additional" operator would be ignored. I 
> guess (technically) it won't have to match the previous operator, it could 
> just be any operator with no argument after it.
> 
> Unlike with trailing comma, I think an operator on its own would not be 
> allowed (e.g. "(|)" or "|") as it's meaning-as-intended will be context 
> dependent (e.g. in this example, the correct answer is a Q() object).
> 
> I am happy to flesh this out more, but as this discussion was ongoing, I 
> thought I would throw it out here and see what people think? Are there 
> potential problems with this e.g. with parsing it?
> 
>> On Fri, 12 Mar 2021 at 14:28, Paul Bryan  wrote:
>> It seems your proposal is intended to address an aesthetic concern. Is there 
>> a case where using a leading comma would make something actually easier or 
>> more intuitive to express over the use of trailing comma?
>> 
>>> On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas 
>>> 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:
>>> ==

[Python-ideas] Re: allow initial comma

[Chris Angelico]

On Sat, Mar 13, 2021 at 3:28 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> For exmaple, if I have a multiline list like this:
>
> x = [
>   1,
>   2
> ]
>
> and add a new element to the end, then I end up with the diff including
> the 2 even though I didn't change the 2.  But if I had had a trailing
> comma, then the diff only shows the new entry.
>
> I see a lot of SQL with the commas at the beginnings of the lines
> (mostly, I think, due to SQL's syntax), but it solves the same problem.

Also in JSON, and for the same reason: the syntax disallows the
trailing comma. There is no reason to create the awkwardness if
trailing commas are accepted.

ChrisA
___
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/TS7P3FBU6ICLM3XYPC4J3JZEUH5X7Q5N/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

This argument pretty much kills the proposal.

On Fri, Mar 12, 2021 at 9:01 AM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

> To my mind there are too many differences between running code as a
> script and running it in the REPL.  This would, presumably, add another
> one: the initial line would be executed without waiting to see if there
> is a dot continuation line.  And it just feels wrong to have a complete
> syntactically valid line of code ... not be a complete line of code.
> You can always add outer brackets, as in other situations where lines of
> code become over-long:
>
>   y = (x.rstrip("\n")
> .split(":")[0]
> .lower())
>
> -1
> Rob Cliffe
>
> On 12/03/2021 15:32, Matt Williams wrote:
> > Hi,
> >
> > It's becoming more popular in Python to have interfaces which are built
> around method chaining as a way of applying operations to data. For example
> in pandas is moving more towards a default model where methods do not
> change the object in-place but instead return an altered version (or at
> least an altered view) of it.
> >
> > The major downside to method chaining is that it ends up creating long
> lines of code which can become hard to read. The two main solutions to this
> are 1) break down the chain and give the steps their own variable names and
> 2) split it over multiple lines using `\` as a line continuation.
> >
> > e.g.:
> >
> >y = x.rstrip("\n").split(":")[0].lower()
> >
> > would become
> >
> >y = x.rstrip("\n") \
> > .split(":")[0] \
> > .lower()
> >
> > I find the continuation character visually distracting, easy to forget
> and does not allow for line-by-line commenting (causing `SyntaxError:
> unexpected character after line continuation character`):
> >
> >y = x.rstrip("\n") \
> > .split(":")[0] \  # grab the key name
> > .lower()
> >
> > My idea is to alter the syntax of Python to allow doing:
> >
> >y = x.rstrip("\n")
> > .split(":")[0]
> > .lower()
> >
> > i.e., not requiring an explicit line continuation character in the case
> where the next line starts with a period.
> >
> > I've had a search through the archives and I couldn't see this
> discussion before. Feel free to point me to it if I've missed anything.
> >
> > Cheers,
> > Matt
> > ___
> > 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/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
> > 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/GVVLTS2EYLB7WKQ625RUOXSQHR3SOQ6E/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/JZZHPUSTBSWPKIZJ7AERBKLQYGJBU2QO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Allow trailing operators [was: allow initial comma]

[Henk-Jaap Wagenaar]

This is a definite tangent. Trailing commas are great for reducing git
diffs, not making errors when moving things around (missing commas, which
e.g. in strings causes concatenation) but I have often wondered whether the
same could be extended to (some?) logical or arithmetic operators, in
particular:

Currently one has to write a logical expression as (using Django Q objects):
(
   Q(user=user) |
   Q(is_deleted=True)
)

and then removing/adding clauses is difficult, whereas if "trailing
operators" where allowed, there would be no such issue:

(
Q(user=user) |
Q(is_deleted=True) |
)

Just like with trailing commas, the "additional" operator would be ignored.
I guess (technically) it won't have to match the previous operator, it
could just be any operator with no argument after it.

Unlike with trailing comma, I think an operator on its own would not be
allowed (e.g. "(|)" or "|") as it's meaning-as-intended will be context
dependent (e.g. in this example, the correct answer is a Q() object).

I am happy to flesh this out more, but as this discussion was ongoing, I
thought I would throw it out here and see what people think? Are there
potential problems with this e.g. with parsing it?

On Fri, 12 Mar 2021 at 14:28, Paul Bryan  wrote:

> It seems your proposal is intended to address an aesthetic concern. Is
> there a case where using a leading comma would make something
> actually easier or more intuitive to express over the use of trailing comma?
>
> On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas
> 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.
>
> Occasi

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

[Rob Cliffe via Python-ideas]

To my mind there are too many differences between running code as a 
script and running it in the REPL.  This would, presumably, add another 
one: the initial line would be executed without waiting to see if there 
is a dot continuation line.  And it just feels wrong to have a complete 
syntactically valid line of code ... not be a complete line of code.  
You can always add outer brackets, as in other situations where lines of 
code become over-long:


 y = (x.rstrip("\n")
   .split(":")[0]
   .lower())

-1
Rob Cliffe

On 12/03/2021 15:32, Matt Williams wrote:

Hi,

It's becoming more popular in Python to have interfaces which are built around 
method chaining as a way of applying operations to data. For example in pandas 
is moving more towards a default model where methods do not change the object 
in-place but instead return an altered version (or at least an altered view) of 
it.

The major downside to method chaining is that it ends up creating long lines of 
code which can become hard to read. The two main solutions to this are 1) break 
down the chain and give the steps their own variable names and 2) split it over 
multiple lines using `\` as a line continuation.

e.g.:

   y = x.rstrip("\n").split(":")[0].lower()

would become

   y = x.rstrip("\n") \
.split(":")[0] \
.lower()

I find the continuation character visually distracting, easy to forget and does 
not allow for line-by-line commenting (causing `SyntaxError: unexpected 
character after line continuation character`):

   y = x.rstrip("\n") \
.split(":")[0] \  # grab the key name
.lower()

My idea is to alter the syntax of Python to allow doing:

   y = x.rstrip("\n")
.split(":")[0]
.lower()

i.e., not requiring an explicit line continuation character in the case where 
the next line starts with a period.

I've had a search through the archives and I couldn't see this discussion 
before. Feel free to point me to it if I've missed anything.

Cheers,
Matt
___
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/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
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/GVVLTS2EYLB7WKQ625RUOXSQHR3SOQ6E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] dataclasses to have a way to make hashable fields immutable

[Tushar Sadhwani]

currently in a `dataclasses.dataclass` based class, you can either have it 
hashable and completely immutable (using frozen=True and eq=True), or you can 
have it hashable but completely mutable (by using unsafe_hash=True)

unsafe_hash provides the convenience of being able to mutate some fields, while 
computing your hash by other, non-mutable fields. But there is nothing 
enforcing the fact that the fields marked with `hash=True` should stay 
immutable, otherwise it completely breaks hashability.

The suggestion is, for the dataclass to throw an error if you try to mutate a 
field that contributes to the hash of that dataclass. Or, to have a flag that 
allows you to do so.

Suggestions for the flag name could be

@dataclass(freeze_hashable_fields=True)
class A:
...

or


@dataclass(frozen_hash=True)
class A:
...
___
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/BQ75RNKQKV6KCTZ2UWDU2RNDHDIQNCZG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[2QdxY4RzWzUUiLuE]

On 2021-03-12 at 11:02:50 -0500,
Ned Batchelder  wrote:

> I think the only reason anyone ever used leading commas to begin with
> was because of languages that didn't allow a final trailing comma.  In
> those worlds, to keep the editing smooth, people moved the commas to
> the beginning of the line, breaking with every comma-tradition.

Allowing a trailing comma makes historical diffs shorter and easier to
read.

For exmaple, if I have a multiline list like this:

x = [
  1,
  2
]

and add a new element to the end, then I end up with the diff including
the 2 even though I didn't change the 2.  But if I had had a trailing
comma, then the diff only shows the new entry.

I see a lot of SQL with the commas at the beginnings of the lines
(mostly, I think, due to SQL's syntax), but it solves the same problem.

> I don't see a reason to make that odd style easier.

I like allowing a trailing comma (for all of the previously stated
reasons), but I agree that "we" (except the SQL people!) seem to have
settled on trailing delimiters rather than leading delimiters, probably
because of the way we write human languages.
___
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/BQIIQFR4W723C6DQDTQIRXKCMCZHKO4N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Paul Moore]

On Fri, 12 Mar 2021 at 16:06, Ned Batchelder  wrote:
>
> I think the only reason anyone ever used leading commas to begin with was 
> because of languages that didn't allow a final trailing comma.  In those 
> worlds, to keep the editing smooth, people moved the commas to the beginning 
> of the line, breaking with every comma-tradition.

Yes, I've seen it in SQL. But even there, it isn't used before the
*first* element of a list.

> I don't see a reason to make that odd style easier.

Agreed.
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/DA7K5IB5XBCJFQKERQWZKARCIZLCPHQC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jonathan Goble]

On Fri, Mar 12, 2021 at 10:41 AM Matt Williams  wrote:
>
> Hi,
>
> It's becoming more popular in Python to have interfaces which are built 
> around method chaining as a way of applying operations to data. For example 
> in pandas is moving more towards a default model where methods do not change 
> the object in-place but instead return an altered version (or at least an 
> altered view) of it.
>
> The major downside to method chaining is that it ends up creating long lines 
> of code which can become hard to read. The two main solutions to this are 1) 
> break down the chain and give the steps their own variable names and 2) split 
> it over multiple lines using `\` as a line continuation.
>
> e.g.:
>
>   y = x.rstrip("\n").split(":")[0].lower()
>
> would become
>
>   y = x.rstrip("\n") \
>.split(":")[0] \
>.lower()
>
> I find the continuation character visually distracting, easy to forget and 
> does not allow for line-by-line commenting (causing `SyntaxError: unexpected 
> character after line continuation character`):
>
>   y = x.rstrip("\n") \
>.split(":")[0] \  # grab the key name
>.lower()
>
> My idea is to alter the syntax of Python to allow doing:
>
>   y = x.rstrip("\n")
>.split(":")[0]
>.lower()
>
> i.e., not requiring an explicit line continuation character in the case where 
> the next line starts with a period.
>
> I've had a search through the archives and I couldn't see this discussion 
> before. Feel free to point me to it if I've missed anything.

Why isn't the implicit line continuation inside parentheses sufficient?

>From my 3.9 REPL:

>>> x
'TEST:TESTING:TEST3\n'
>>> y = x.rstrip("\n").split(":")[0].lower()
>>> y
'test'
>>> z = (x.rstrip("\n")
...  .split(":")[0]
...  .lower()
... )
>>> z
'test'
>>>

This already works today, and every style guide with an opinion that
I'm aware of prefers this implicit line continuation over the explicit
backslash you demonstrate anyway.
___
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/JFOEB2RY4CWTO4ZM3HTB574DROZRWPTK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

On Fri, 12 Mar 2021 at 15:53, Paul Bryan  wrote:
>
> My inclination would be to cede code formatting to a tool like Black and 
> focus on function:
> https://black.readthedocs.io/en/stable/

... and if you try that out, what you'll find is that black adds parentheses:

y = (
x.rstrip("\n")
.split(":")[0]
.lower()
)

Which is a reasonable solution even if you don't like black's
formatting choices. Black only wraps when the line length is exceeded,
but I can see arguments for wrapping sooner than that in some cases,
and personally I prefer the following indentation scheme:

y = (
x.rstrip("\n")
   .split(":")[0]
   .lower()
)

But the principle is the same - I think adding parentheses is an
acceptable compromise, in the spirit of "Special cases aren't special
enough to break the rules".

I don't like needing to use backslashes to continue lines, but I find
having to think about how to structure my code to avoid continuations
that need backslashes tends to force me to come up with better/more
readable ways of writing the expression. Chained method calls are
right at the limit here. Sometimes (and only sometimes!) they are a
nice way of expressing a computation, but there's no immediately
natural way to line-wrap them. I can sympathise with the request here,
but parentheses seem adequate to me. (And yes, I spotted the irony of
suggesting paren-delimiters for extended expressions in a language
that avoids using braces as delimiters for statement blocks :-))

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/W4A7TKADGRMHGYOKTI2FYR7N2JLMBEWN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Ned Batchelder]

I think the only reason anyone ever used leading commas to begin with 
was because of languages that didn't allow a final trailing comma.  In 
those worlds, to keep the editing smooth, people moved the commas to the 
beginning of the line, breaking with every comma-tradition.


I don't see a reason to make that odd style easier.

--Ned.

On 3/12/21 9:27 AM, Paul Bryan wrote:
It seems your proposal is intended to address an aesthetic concern. Is 
there a case where using a leading comma would make something 
actually easier or more intuitive to express over the use of trailing 
comma?


On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas 
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. Thanks.
___
Python-ideas mailing list -- python-ideas@python.org 

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

[Guido van Rossum]

Can we skip ahead to considering how to implement this? I can think of two
approaches: either hack the lexer to special-case a newline followed by a
period (which currently can never start a line), or redesign the syntax to
allow NEWLINE INDENT ‘.’ . NEWLINE ‘.’  DEDENT at the
end of an expression. Both have pros and cons.

Discuss how this allows for certain typos to pass as valid syntax.

On Fri, Mar 12, 2021 at 07:42 Matt Williams  wrote:

> Hi,
>
> It's becoming more popular in Python to have interfaces which are built
> around method chaining as a way of applying operations to data. For example
> in pandas is moving more towards a default model where methods do not
> change the object in-place but instead return an altered version (or at
> least an altered view) of it.
>
> The major downside to method chaining is that it ends up creating long
> lines of code which can become hard to read. The two main solutions to this
> are 1) break down the chain and give the steps their own variable names and
> 2) split it over multiple lines using `\` as a line continuation.
>
> e.g.:
>
>   y = x.rstrip("\n").split(":")[0].lower()
>
> would become
>
>   y = x.rstrip("\n") \
>.split(":")[0] \
>.lower()
>
> I find the continuation character visually distracting, easy to forget and
> does not allow for line-by-line commenting (causing `SyntaxError:
> unexpected character after line continuation character`):
>
>   y = x.rstrip("\n") \
>.split(":")[0] \  # grab the key name
>.lower()
>
> My idea is to alter the syntax of Python to allow doing:
>
>   y = x.rstrip("\n")
>.split(":")[0]
>.lower()
>
> i.e., not requiring an explicit line continuation character in the case
> where the next line starts with a period.
>
> I've had a search through the archives and I couldn't see this discussion
> before. Feel free to point me to it if I've missed anything.
>
> Cheers,
> Matt
> ___
> 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/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/3BNMTY74DDQMTD6PVH3ZGCVMBCSW3SQ5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Bryan]

My inclination would be to cede code formatting to a tool like Black
and focus on function:
https://black.readthedocs.io/en/stable/


On Fri, 2021-03-12 at 15:32 +, Matt Williams wrote:
> Hi,
> 
> It's becoming more popular in Python to have interfaces which are
> built around method chaining as a way of applying operations to data.
> For example in pandas is moving more towards a default model where
> methods do not change the object in-place but instead return an
> altered version (or at least an altered view) of it.
> 
> The major downside to method chaining is that it ends up creating
> long lines of code which can become hard to read. The two main
> solutions to this are 1) break down the chain and give the steps
> their own variable names and 2) split it over multiple lines using
> `\` as a line continuation.
> 
> e.g.:
> 
>   y = x.rstrip("\n").split(":")[0].lower()
> 
> would become
> 
>   y = x.rstrip("\n") \
>    .split(":")[0] \
>    .lower()
> 
> I find the continuation character visually distracting, easy to
> forget and does not allow for line-by-line commenting (causing
> `SyntaxError: unexpected character after line continuation
> character`):
> 
>   y = x.rstrip("\n") \
>    .split(":")[0] \  # grab the key name
>    .lower()
> 
> My idea is to alter the syntax of Python to allow doing:
> 
>   y = x.rstrip("\n")
>    .split(":")[0]
>    .lower()
> 
> i.e., not requiring an explicit line continuation character in the
> case where the next line starts with a period.
> 
> I've had a search through the archives and I couldn't see this
> discussion before. Feel free to point me to it if I've missed
> anything.
> 
> Cheers,
> Matt
> ___
> 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/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
> 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/X7NMRC4FMO4LBB7E2XP4D76FXZ5MMZVY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Implicit line continuation for method chaining

[Matt Williams]

Hi,

It's becoming more popular in Python to have interfaces which are built around 
method chaining as a way of applying operations to data. For example in pandas 
is moving more towards a default model where methods do not change the object 
in-place but instead return an altered version (or at least an altered view) of 
it.

The major downside to method chaining is that it ends up creating long lines of 
code which can become hard to read. The two main solutions to this are 1) break 
down the chain and give the steps their own variable names and 2) split it over 
multiple lines using `\` as a line continuation.

e.g.:

  y = x.rstrip("\n").split(":")[0].lower()

would become

  y = x.rstrip("\n") \
   .split(":")[0] \
   .lower()

I find the continuation character visually distracting, easy to forget and does 
not allow for line-by-line commenting (causing `SyntaxError: unexpected 
character after line continuation character`):

  y = x.rstrip("\n") \
   .split(":")[0] \  # grab the key name
   .lower()

My idea is to alter the syntax of Python to allow doing:

  y = x.rstrip("\n")
   .split(":")[0]
   .lower()

i.e., not requiring an explicit line continuation character in the case where 
the next line starts with a period.

I've had a search through the archives and I couldn't see this discussion 
before. Feel free to point me to it if I've missed anything.

Cheers,
Matt
___
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/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Paul Bryan]

It seems your proposal is intended to address an aesthetic concern. Is
there a case where using a leading comma would make something
actually easier or more intuitive to express over the use of trailing
comma?

On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas
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. Thanks.
> ___
> 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/E3HYA7AWLHTD3MCWVBRH7AT3GLGXFUOG/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas maili

[Python-ideas] Re: allow initial comma

[Paul Moore]

On Fri, 12 Mar 2021 at 13:22, roland.puntaier--- via Python-ideas
 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.

This layout style is not something I've ever seen used in "real life",
and I don't think it's something that should be encouraged, much less
added to the language.

> 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.

More likely because there are two common schools of thought - lists
have punctuation *separating* items, and lists have punctuation
*terminating* items. I don't even know a commonly used term for the
idea of having something *before* each item. So I think you need to
find examples of other languages that support this style if you want
to advocate for it, otherwise you'll need to demonstrate that it's
important enough for Python to go against the norm here.

> 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.

But (1) "it's my preference" isn't sufficient to change the language,
and (2) why not change your macro to remove a *trailing* comma
instead?

Overall, I don't think this is a good idea. -1 from me.

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/5RENNY6WP5VSWKHAIVTWU4R3VA4BGWIC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] allow initial comma

[roland.puntaier--- via Python-ideas]

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. Thanks.
___
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/E3HYA7AWLHTD3MCWVBRH7AT3GLGXFUOG/
Code of Conduct: http://python.org/psf/codeofconduct/