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

[Ethan Furman]

On 3/14/21 12:42 PM, Stestagg wrote:


The value of being able to (in specific cases) reach into third-party code, and 
customize it to work for your specific situation should not be disregarded.


I completely agree with this.  One of the hallmarks of Python is the ability to 
query, introspect, and modify Python code.  It helps with debugging, with 
experimenting, with fixing.  Indeed, one of the few frustrating bits about 
Python is the inability to work with the C portions as easily as the Python 
portions (note: I am /not/ suggesting we do away with the C portions).

What would be the benefits of locking down modules in this way?

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

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

[Guido van Rossum]

Hi Steve,

I don't think I can explain adequately why I challenged you, so I'll just
apologize.  Your feedback (about the 'export' proposal, and about my
challenge of your credentials) is duly noted. Sorry!

--Guido

On Sun, Mar 14, 2021 at 4:11 PM Stestagg  wrote:

> On Sun, Mar 14, 2021 at 8:22 PM Guido van Rossum  wrote:
>
>> If you feel so strongly about it maybe we need to see some credentials.
>> What's your background? (This may sound like an odd request, but reputation
>> matters, and right now I have no idea who you are or why I should take your
>> opinion seriously, no matter how eloquently it is stated.)
>>
>>
> Hi Guido, I have enormous respect for you, but have no interest in
> attempting to prove I'm a 'good-enough egg' to warrant your serious
> attention.
>
> The entire question makes me somewhat uncomfortable, and to illustrate
> why, I'm going to willfully misinterpret it to make my point:
>
> My background is: White, Middle-class British male, mid-30s, my family is
> descended from the illigitimate son of the governor of the Isle of Wight.
> I've dined with the Queen, and my last two schools were both over 400 years
> old.  Does this qualify me for attention?  What if I were a BAME teen woman
> living in Bangladesh?
>
> Of course, sarcastic responses aside, I assume you meant technical
> background/credentials. Similar concerns still apply there, this
> python-ideas list is full of people with ideas, many of which are held
> strongly, that don't get their background questioned openly (although, as
> in most communities, there's evidence of this happening subtextually in
> places).
>
> In fact, when I previously pointed out a critical flaw in one of your
> proposals in another thread on this list, I wasn't questioned about my
> credentials then (I assume because you realised your mistake at that
> time).  If you're still interested in my CV, it's easily findable online,
> along with other technical context about me that may be relevant to
> assessing my worthiness.
>
> Regardless of the above, I'm not going to argue further about the proposal
> or my plea to keep some control/override. That's why I made my case as
> robustly as I could initially. It's a single data-point, other people may
> reinforce it, or counter it, in the disucssion.  By broaching the subject,
> I was hoping to ensure that this aspect of the proposed change would be
> considered, if you decide I'm not worth it, then that's your call.
>
> Regards
>
> Steve
>
> Note that C extensions allow none of the introspection mechanisms you're
>> proposing here (they have a `__dict__` but it is fully controlled by the
>> author of the C code) and they thrive just fine.
>>
>> I am happy with giving module authors a way to tell the system "it's
>> okay, users can reach in to access other attributes as well". But I think
>> module authors should *also* be given a way to tell the system "please
>> prevent users from accessing the private parts of this API no matter how
>> hard they try". And using 'export' seems a reasonable way to enable the
>> latter. (To be clear I am fine if there's a flag to override this default
>> even when 'export' is used.)
>>
>> I know there are package authors out there who have this desire to
>> restrict access (presumably because they've been burned when trying to
>> evolve their API) and feel so strongly about it that they implement their
>> own restrictive access controls (without resorting to writing C code).
>>
>> On Sun, Mar 14, 2021 at 12:42 PM Stestagg  wrote:
>>
>>> On Sun, 14 Mar 2021 at 18:58, Guido van Rossum  wrote:
>>>
 On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel  wrote:

> > import the_module
>
> > the_module.sys
>
> > would work, but
>
> > from the_module import sys
>
> > would not work?
>
> > That might be odd and confusing.
>
> Good point. I'm not familiar with CPython internals so I'm not sure
> how this would work on the implementation side, but I definitely think it
> would be important to not have an inconsistency here.
>

 So I think there is no technical reason why we couldn't make it so that
 a module that uses `export` returns a proxy that only lets you use
 attributes that are explicitly exported. If users disagree with this, they
 can negotiate directly with the module authors. It's not a principle of
 Python that users *must* be given access to implementation details, after
 all -- it was just more convenient to do it this way when the language was
 young. (For example, it's not possible to root around like this in C
 extensions -- these only export what the author intends to export.)


>>>
>>> If this is implemented, then please ensure that some mechanism is
>>> included (either keeping __dict__, or functions in inspect, or some other
>>> mechanism) to both get and set all attributes of a module irrespective of
>>> any  export/__all__ controls.
>>>
>>> I understan

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

[Stestagg]

On Sun, Mar 14, 2021 at 8:22 PM Guido van Rossum  wrote:

> If you feel so strongly about it maybe we need to see some credentials.
> What's your background? (This may sound like an odd request, but reputation
> matters, and right now I have no idea who you are or why I should take your
> opinion seriously, no matter how eloquently it is stated.)
>
>
Hi Guido, I have enormous respect for you, but have no interest in
attempting to prove I'm a 'good-enough egg' to warrant your serious
attention.

The entire question makes me somewhat uncomfortable, and to illustrate why,
I'm going to willfully misinterpret it to make my point:

My background is: White, Middle-class British male, mid-30s, my family is
descended from the illigitimate son of the governor of the Isle of Wight.
I've dined with the Queen, and my last two schools were both over 400 years
old.  Does this qualify me for attention?  What if I were a BAME teen woman
living in Bangladesh?

Of course, sarcastic responses aside, I assume you meant technical
background/credentials. Similar concerns still apply there, this
python-ideas list is full of people with ideas, many of which are held
strongly, that don't get their background questioned openly (although, as
in most communities, there's evidence of this happening subtextually in
places).

In fact, when I previously pointed out a critical flaw in one of your
proposals in another thread on this list, I wasn't questioned about my
credentials then (I assume because you realised your mistake at that
time).  If you're still interested in my CV, it's easily findable online,
along with other technical context about me that may be relevant to
assessing my worthiness.

Regardless of the above, I'm not going to argue further about the proposal
or my plea to keep some control/override. That's why I made my case as
robustly as I could initially. It's a single data-point, other people may
reinforce it, or counter it, in the disucssion.  By broaching the subject,
I was hoping to ensure that this aspect of the proposed change would be
considered, if you decide I'm not worth it, then that's your call.

Regards

Steve

Note that C extensions allow none of the introspection mechanisms you're
> proposing here (they have a `__dict__` but it is fully controlled by the
> author of the C code) and they thrive just fine.
>
> I am happy with giving module authors a way to tell the system "it's okay,
> users can reach in to access other attributes as well". But I think module
> authors should *also* be given a way to tell the system "please prevent
> users from accessing the private parts of this API no matter how hard they
> try". And using 'export' seems a reasonable way to enable the latter. (To
> be clear I am fine if there's a flag to override this default even when
> 'export' is used.)
>
> I know there are package authors out there who have this desire to
> restrict access (presumably because they've been burned when trying to
> evolve their API) and feel so strongly about it that they implement their
> own restrictive access controls (without resorting to writing C code).
>
> On Sun, Mar 14, 2021 at 12:42 PM Stestagg  wrote:
>
>> On Sun, 14 Mar 2021 at 18:58, Guido van Rossum  wrote:
>>
>>> On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel  wrote:
>>>
 > import the_module

 > the_module.sys

 > would work, but

 > from the_module import sys

 > would not work?

 > That might be odd and confusing.

 Good point. I'm not familiar with CPython internals so I'm not sure how
 this would work on the implementation side, but I definitely think it would
 be important to not have an inconsistency here.

>>>
>>> So I think there is no technical reason why we couldn't make it so that
>>> a module that uses `export` returns a proxy that only lets you use
>>> attributes that are explicitly exported. If users disagree with this, they
>>> can negotiate directly with the module authors. It's not a principle of
>>> Python that users *must* be given access to implementation details, after
>>> all -- it was just more convenient to do it this way when the language was
>>> young. (For example, it's not possible to root around like this in C
>>> extensions -- these only export what the author intends to export.)
>>>
>>>
>>
>> If this is implemented, then please ensure that some mechanism is
>> included (either keeping __dict__, or functions in inspect, or some other
>> mechanism) to both get and set all attributes of a module irrespective of
>> any  export/__all__ controls.
>>
>> I understand that perspective that says library authors should be able to
>> control their API, for various reasons, but this has to be balanced against
>> the fact that library authors are not perfect, and can either include bugs,
>> or fail to consider all reasonable use-cases when designing their code.
>> Historically, this has been done, by convention, through use of the "_"
>> private specifier for module

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

[Brendan Barnwell]

On 2021-03-12 19:57, Eric V. Smith wrote:

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?


	Without getting too much into the details of your proposal, my main 
reaction to all this is that it's either trying to shoehorn too much 
into the typing annotations, or being too timid about what to put in the 
typing annotations.


	If we want to use typing annotations to document types then we should 
use them for that, and not try to sneakily also use them to define 
actual behavior.


	If, on the other hand, we *are* okay with using type annotations for 
defining behavior, then there isn't any need to resort to odd tricks 
like `_: dataclasses.KW_ONLY`.  You can just put the behavior constraint 
directly in the annotation:


@dataclass
class Foo:
 a: (Any, dataclasses.KW_ONLY)
# or
b: {'type': Any, 'kw_only': True}
# or (where "Any" and kw_only are is some new objects provided by a 
library that handles this usage)

c: Any + kw_only

. . . and then say that it's the job of dataclass and of typecheckers to 
separate the different sorts of information.


	I don't see value in trying to force additional information into type 
annotations while simultaneously trying to obey various conventions 
established by typechecking libraries that expect types to be specified 
in certain ways.  I was never a big fan of the type annotations and I 
think this kind of thing illustrates the difficulty of having 
"advisory-only" annotations that aren't supposed to affect runtime 
behavior but then gradually begin to do so via things like dataclasses.


	If type annotations are advisory only they should remain 100% advisory 
only and for use only by static type checkers with zero effect on the 
code's runtime behavior.  If we're going to use type checking to 
influence runtime behavior then we should acknowledge that people can 
put ANYTHING in the type annotations and thus ANY library can make 
totally arbitrary use of any type annotation to perform arbitrary 
actions at runtime.


	So basically, if we want to indicate stuff like keyword-only-ness using 
type annotations, that's fine, but we should acknowledge that at that 
point we are no longer annotating types.  We are using type annotation 
syntax to implement arbitrary runtime behavior, and we should accept 
that doing that may break typecheckers or make life painful for their 
maintainers.


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

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

[Guido van Rossum]

If you feel so strongly about it maybe we need to see some credentials.
What's your background? (This may sound like an odd request, but reputation
matters, and right now I have no idea who you are or why I should take your
opinion seriously, no matter how eloquently it is stated.)

Note that C extensions allow none of the introspection mechanisms you're
proposing here (they have a `__dict__` but it is fully controlled by the
author of the C code) and they thrive just fine.

I am happy with giving module authors a way to tell the system "it's okay,
users can reach in to access other attributes as well". But I think module
authors should *also* be given a way to tell the system "please prevent
users from accessing the private parts of this API no matter how hard they
try". And using 'export' seems a reasonable way to enable the latter. (To
be clear I am fine if there's a flag to override this default even when
'export' is used.)

I know there are package authors out there who have this desire to restrict
access (presumably because they've been burned when trying to evolve their
API) and feel so strongly about it that they implement their own
restrictive access controls (without resorting to writing C code).

On Sun, Mar 14, 2021 at 12:42 PM Stestagg  wrote:

> On Sun, 14 Mar 2021 at 18:58, Guido van Rossum  wrote:
>
>> On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel  wrote:
>>
>>> > import the_module
>>>
>>> > the_module.sys
>>>
>>> > would work, but
>>>
>>> > from the_module import sys
>>>
>>> > would not work?
>>>
>>> > That might be odd and confusing.
>>>
>>> Good point. I'm not familiar with CPython internals so I'm not sure how
>>> this would work on the implementation side, but I definitely think it would
>>> be important to not have an inconsistency here.
>>>
>>
>> So I think there is no technical reason why we couldn't make it so that a
>> module that uses `export` returns a proxy that only lets you use attributes
>> that are explicitly exported. If users disagree with this, they can
>> negotiate directly with the module authors. It's not a principle of Python
>> that users *must* be given access to implementation details, after all --
>> it was just more convenient to do it this way when the language was young.
>> (For example, it's not possible to root around like this in C extensions --
>> these only export what the author intends to export.)
>>
>>
>
> If this is implemented, then please ensure that some mechanism is included
> (either keeping __dict__, or functions in inspect, or some other mechanism)
> to both get and set all attributes of a module irrespective of any
> export/__all__ controls.
>
> I understand that perspective that says library authors should be able to
> control their API, for various reasons, but this has to be balanced against
> the fact that library authors are not perfect, and can either include bugs,
> or fail to consider all reasonable use-cases when designing their code.
> Historically, this has been done, by convention, through use of the "_"
> private specifier for module-level objects.
>
> The value of being able to (in specific cases) reach into third-party
> code, and customize it to work for your specific situation should not be
> disregarded.
>
> I think every large codebase that I've worked with has had to monkey-patch
> a method deep within at least one third-party library at runtime, in
> production (this is also commonly used for testing purposes), at some point
> to work-around either a limitation of the library, incompatibility with
> other library, or to patch a bug.  This also applies to module-globals that
> are themselves imported modules, being able to rebind a name to reference a
> different module (within careful constraints) in a library module has saved
> me several times.
>
> If external visibility of code units within libraries starts to be
> restricted so that this sort of patching isn't possible, then the cost of
> fixing some problems may start to become significantly greater.
>
> I strongly believe that the access to members of modules should be kept as
> similar to the access of members of class instances as possible. Not only
> will this keep the model simpler, the same arguments and/or concerns apply
> when talking about classes as when talking about modules.  Maybe this means
> that non-exported members of modules get name-mangled as protected class
> attributes do, or maybe the '__dict__' member is always exported.
>
> I think the idea of resolving the issues mentioned above by talking with
> third-party module authors directly, seems like an unlikely solution.  In
> my experience, this sort of 'keyhole surgery' patching is often against
> large, undersupported public libraries (think sqlalchemy, pandas, etc..
> where two factors make it unlikely that these projects will be able to help
> directly:
>
> 1. If your project have unique or uncommon requirements that require this
> sort of patch, often library authors do not want to incur the ma

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

[Stestagg]

On Sun, 14 Mar 2021 at 18:58, Guido van Rossum  wrote:

> On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel  wrote:
>
>> > import the_module
>>
>> > the_module.sys
>>
>> > would work, but
>>
>> > from the_module import sys
>>
>> > would not work?
>>
>> > That might be odd and confusing.
>>
>> Good point. I'm not familiar with CPython internals so I'm not sure how
>> this would work on the implementation side, but I definitely think it would
>> be important to not have an inconsistency here.
>>
>
> So I think there is no technical reason why we couldn't make it so that a
> module that uses `export` returns a proxy that only lets you use attributes
> that are explicitly exported. If users disagree with this, they can
> negotiate directly with the module authors. It's not a principle of Python
> that users *must* be given access to implementation details, after all --
> it was just more convenient to do it this way when the language was young.
> (For example, it's not possible to root around like this in C extensions --
> these only export what the author intends to export.)
>
>

If this is implemented, then please ensure that some mechanism is included
(either keeping __dict__, or functions in inspect, or some other mechanism)
to both get and set all attributes of a module irrespective of any
export/__all__ controls.

I understand that perspective that says library authors should be able to
control their API, for various reasons, but this has to be balanced against
the fact that library authors are not perfect, and can either include bugs,
or fail to consider all reasonable use-cases when designing their code.
Historically, this has been done, by convention, through use of the "_"
private specifier for module-level objects.

The value of being able to (in specific cases) reach into third-party code,
and customize it to work for your specific situation should not be
disregarded.

I think every large codebase that I've worked with has had to monkey-patch
a method deep within at least one third-party library at runtime, in
production (this is also commonly used for testing purposes), at some point
to work-around either a limitation of the library, incompatibility with
other library, or to patch a bug.  This also applies to module-globals that
are themselves imported modules, being able to rebind a name to reference a
different module (within careful constraints) in a library module has saved
me several times.

If external visibility of code units within libraries starts to be
restricted so that this sort of patching isn't possible, then the cost of
fixing some problems may start to become significantly greater.

I strongly believe that the access to members of modules should be kept as
similar to the access of members of class instances as possible. Not only
will this keep the model simpler, the same arguments and/or concerns apply
when talking about classes as when talking about modules.  Maybe this means
that non-exported members of modules get name-mangled as protected class
attributes do, or maybe the '__dict__' member is always exported.

I think the idea of resolving the issues mentioned above by talking with
third-party module authors directly, seems like an unlikely solution.  In
my experience, this sort of 'keyhole surgery' patching is often against
large, undersupported public libraries (think sqlalchemy, pandas, etc..
where two factors make it unlikely that these projects will be able to help
directly:

1. If your project have unique or uncommon requirements that require this
sort of patch, often library authors do not want to incur the maintenance
burden of changing their carefully-designed code to support the use-cases,
especially if they do not consider the requirements to be valid (even if
they are in a different context to that being considered by the authors)
2. Release cycles of these projects can be long and complex.  Maybe you're
using a previous version of this library, and the current release is not
compatible with your stack, so even if the library does release a fix, then
you'd not be able to use it without a major refactor/retest cycle
internally.

I really like the "we're all adults here" approach to private/protected
access that python currently takes, please don't weaken this without a lot
of serious consideration :)

Thanks

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

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

[Guido van Rossum]

On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel  wrote:

> > import the_module
>
> > the_module.sys
>
> > would work, but
>
> > from the_module import sys
>
> > would not work?
>
> > That might be odd and confusing.
>
> Good point. I'm not familiar with CPython internals so I'm not sure how
> this would work on the implementation side, but I definitely think it would
> be important to not have an inconsistency here.
>

You probably should design this in partnership with someone who's more
familiar with those internals. I believe that familiarity with Python
internals is pretty important if you want to be able to design a new
feature. Without thinking about the implementation you might design
something that's awkward to implement; but you might also not think of
something that's easy to do in the implementation but not obvious from
superficial usage. (There are two lines in the Zen of Python devoted to
this. :-)

It is already possible to completely customize what happens when you write
"import X". The returned object doesn't even strictly need to have a
`__dict__` attribute. For  `from X import Y` it first does `import X` (but
doesn't bind X in your namespace) and then gives you `X.Y`, except if `Y`
is `*`, in which case it looks in `X.__all__`, or if that's not found it
looks in `X.__dict__` and imports all keys not starting with `_`. So to
support `from X import *` you need either `__all__` or `__dict__`, else you
get an import error (but neither of those is needed to support `from X
import Y` or `import X; X.Y`).

So I think there is no technical reason why we couldn't make it so that a
module that uses `export` returns a proxy that only lets you use attributes
that are explicitly exported. If users disagree with this, they can
negotiate directly with the module authors. It's not a principle of Python
that users *must* be given access to implementation details, after all --
it was just more convenient to do it this way when the language was young.
(For example, it's not possible to root around like this in C extensions --
these only export what the author intends to export.)

I do think that this means that existing libraries need to be careful when
adding `export` statements, because it effectively becomes a backwards
incompatibility. We could also implement a flag to weaken the strictness in
this area (the flag would have to be set by the module, not by the
importing code).

Such a proxy could also be used to implement lazy imports, to some extent.
(I'm not sure how to do `from X import Y` lazily -- it would have to wrap
`Y` in another proxy, and then it becomes awkward, e.g. if `Y` is supposed
to represent a simple number or string -- we don't want any other part of
the language or stdlib to need to become aware of such proxies.)

Long answer short, yes, we can make it so that `the_module.sys` in your
example above is forbidden -- if we want to.

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

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

[Theia Vogel]

> import the_module

> the_module.sys

> would work, but

> from the_module import sys

> would not work?

> That might be odd and confusing.

Good point. I'm not familiar with CPython internals so I'm not sure how
this would work on the implementation side, but I definitely think it would
be important to not have an inconsistency 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/MRF4UEESEDGFXRRJP7UCVJ7Y3TRHPZXO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Theia Vogel]

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


That was a misconception on my part -- always thought it worked the other
way around! Not sure why I thought that.

I'm open to the idea of not using __all__, if there's the possibility to
have a better interface by breaking away from it. My worries with creating
a new, more strict interface would be:

1, breaking compatibility with old tools that look for __all__
specifically-- though I'm not sure how big the set of "tools that
dynamically introspect __all__" is. It's probably pretty small.

2, I do like that Python gives you the ability to import everything, even
if the library author didn't intend for it. There's benefits to
encapsulation of course, but I like having the option to fiddle with some
library internals if I really need to. I wonder if there's a way to keep
this ability but make it a little "louder", so it's clear you're doing
something abnormal -- like the underscore-prefixed private member
convention or dangerouslySetInnerHTML in React.

As for `export x: int = 1` vs
```
x: int = 1
export x
```

, I like both syntaxes pretty equally. My choice in the original post was
mostly because I was unsure about exactly how flexible the soft keywords in
the new parser are, and if it would be tricky to insert them before an
arbitrary assignment like that instead of making them be their own
statement. If that's not an issue, I'm in favor of either syntax :)

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

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

[Eric V. Smith]

Yeah, I'm beginning to see that positional args are going to make it 
unworkable. I'll write up another proposal with just normal args and 
keyword-only args.


Thanks everyone for your feedback!

Eric

On 3/13/2021 8:19 PM, Matt Wozniski wrote:

Oops, sent a reply too soon.

On Sat, Mar 13, 2021 at 3:14 PM Eric V. Smith > wrote:


The thing is, even without being able to switch back and forth
within a single dataclass, you could achieve the same thing with
inheritance:

...

In both cases, you'd get re-ordered fields in __init__, and
nowhere else:

def __init__(c, d, *, a, b, e, f):

repr, comparisons, etc. would still treat them in today's order:
a, b, c, d, e, f.

...

And the same logic would apply to positional argument fields

This seems like another disadvantage of allowing positional-only 
arguments. If positional-only fields show up just like keyword fields 
in an arbitrary position in the repr, the repr will cease to be a 
representation of a call to the dataclass's constructor suitable for 
passing to `eval`, as it is today when init-only parameters are not in 
use.


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

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

[Peter Otten]

Speaking as someone who's not into dataclasses:

This whole thread seems to be about spelling the initilizer's function 
signature as a class body. Have you considered going in the opposite 
direction, i. e. writing something like


@dataclass
class A:
@attributes_from_signature
def __init__(self, ham, spam=None):
pass

or

@attributes_from_signature
def A(ham, spam=None):
pass


to autogenerate a class A with with attributes ham and spam?

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