[Python-ideas] Recursive submit in concurrent.future.ProcessPoolExecutor
Hi, Currrently, is it allowed for process worker to submit new task to its parent executor? Considering the following Python script: ```python3 import concurrent.futures with concurrent.futures.ProcessPoolExecutor(max_workers=12) as ppe: def hello(n: int) -> int: if n == 0: return 0 return n+ ppe.submit(hello, n-1).result() future = ppe.submit(hello, 1) print(future.result()) ``` It will never stuck and never ended. Sent with [ProtonMail](https://protonmail.com/) Secure Email.___ 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/2LD5WH4LT7TSOPYE4WHNWJAHPYW4YRPV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
I too have used plain strings in Annotated[...] to document fields in
dataclasses.
On Thu, 2021-11-18 at 13:51 -0500, Ricky Teachey wrote:
> On Thu, Nov 18, 2021 at 1:39 PM Thomas Grainger
> wrote:
> > Ricky Teachey wrote:
> > > Could this be a use case for typing.Annotated?
> > > In [6]: from dataclasses import dataclass
> > > In [7]: from typing import Annotated
> > > In [8]: class A:
> > > ...: """Docstring for class A."""
> > > ...: x: Annotated[int, "Docstring for x"]
> > > ...: y: Annotated[bool, "Docstring for y"] = True
> > > In [9]: A.__annotations__
> > > Out[9]:
> > > {'x': typing.Annotated[int, 'Docstring for x'],
> > > 'y': typing.Annotated[bool, 'Docstring for y']}
> > > The syntax is a bit arduous; I'd be in favor of thinking through
> > ways to
> > > make it easier to write. But the basic functionality already
> > exists;
> > > there's no reason to duplicate it with another language feature.
> > > Rick.
> > > ---
> > > Ricky.
> > > "I've never met a Kentucky man who wasn't either thinking about
> > going home
> > > or actually going home." - Happy Chandler
> > > On Thu, Nov 18, 2021 at 5:50 AM tmkehrenb...@gmail.com wrote:
> > > > Stephen J. Turnbull wrote:
> > > > @standard_class_docstring_parser
> > > > class A:
> > > > """
> > > > Class docstring.
> > > > x: Docstring for x
> > > > y: Docstring for y
> > > > """
> > > > x: int
> > > > y: bool = True
> > > > Oh, this is actually a nice idea. You could have a
> > > > decorator that parses reST and then according
> > > > to some conventions extracts the attribute
> > > > docstrings. I think I will try to write something like
> > > > that.
> > > > Thomas
> > > > ___
> > > > 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/F2QJ3Q.
> > ..
> > > > Code of Conduct: http://python.org/psf/codeofconduct/
> > > >
> >
> > I think you need to use another type rather than a plain string
> > here eg:
> >
> >
> > ```
> > @dataclasses.dataclass(frozen=True)
> > class Doc:
> > v: str
> >
> > @dataclasses.dataclass
> > class A:
> > """docstring for class A."""
> > x: typing.Annotated[int, Doc("docstring for x")]
> > ```
> >
>
>
> I don't know why you would? It seems to work just fine with a plain
> string?
>
> One thing that is bad about it: the class member "docstrings"
> (actually the annotations) are repeated all over the place (look like
> 4 times total?) in the help() output-- example is below:
>
> >>> help(A)
> Help on class A in module __main__:
>
> class A(builtins.object)
> | A(x: typing.Annotated[int, 'docstring for x']) -> None
> |
> | docstring for class A.
> |
> | Methods defined here:
> |
> | __eq__(self, other)
> |
> | __init__(self, x: typing.Annotated[int, 'docstring for x']) ->
> None
> |
> | __repr__(self)
> |
> | -
> -
> | Data descriptors defined here:
> |
> | __dict__
> | dictionary for instance variables (if defined)
> |
> | __weakref__
> | list of weak references to the object (if defined)
> |
> | -
> -
> | Data and other attributes defined here:
> |
> | __annotations__ = {'x': typing.Annotated[int, 'docstring for x']}
> |
> | __dataclass_fields__ = {'x':
> Field(name='x',type=typing.Annotated[int,...
> |
> | __dataclass_params__ =
> _DataclassParams(init=True,repr=True,eq=True,or...
> |
> | __hash__ = None
>
> ---
> 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/BXCEE4G6SDYWI4LQMTPZ3AWAJN2I3EMD/
> 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/KG67DQKZYMDZNZTLSZIHSYG5IGBH2REG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
On Thu, Nov 18, 2021 at 1:39 PM Thomas Grainger wrote:
> Ricky Teachey wrote:
> > Could this be a use case for typing.Annotated?
> > In [6]: from dataclasses import dataclass
> > In [7]: from typing import Annotated
> > In [8]: class A:
> >...: """Docstring for class A."""
> >...: x: Annotated[int, "Docstring for x"]
> >...: y: Annotated[bool, "Docstring for y"] = True
> > In [9]: A.__annotations__
> > Out[9]:
> > {'x': typing.Annotated[int, 'Docstring for x'],
> > 'y': typing.Annotated[bool, 'Docstring for y']}
> > The syntax is a bit arduous; I'd be in favor of thinking through ways to
> > make it easier to write. But the basic functionality already exists;
> > there's no reason to duplicate it with another language feature.
> > Rick.
> > ---
> > Ricky.
> > "I've never met a Kentucky man who wasn't either thinking about going
> home
> > or actually going home." - Happy Chandler
> > On Thu, Nov 18, 2021 at 5:50 AM tmkehrenb...@gmail.com wrote:
> > > Stephen J. Turnbull wrote:
> > > @standard_class_docstring_parser
> > > class A:
> > > """
> > > Class docstring.
> > > x: Docstring for x
> > > y: Docstring for y
> > > """
> > > x: int
> > > y: bool = True
> > > Oh, this is actually a nice idea. You could have a
> > > decorator that parses reST and then according
> > > to some conventions extracts the attribute
> > > docstrings. I think I will try to write something like
> > > that.
> > > Thomas
> > > ___
> > > 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/F2QJ3Q.
> ..
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > >
>
> I think you need to use another type rather than a plain string here eg:
>
>
> ```
> @dataclasses.dataclass(frozen=True)
> class Doc:
> v: str
>
> @dataclasses.dataclass
> class A:
> """docstring for class A."""
> x: typing.Annotated[int, Doc("docstring for x")]
> ```
>
I don't know why you would? It seems to work just fine with a plain string?
One thing that is bad about it: the class member "docstrings" (actually the
annotations) are repeated all over the place (look like 4 times total?) in
the help() output-- example is below:
>>> help(A)
Help on class A in module __main__:
class A(builtins.object)
| A(x: *typing.Annotated[int, 'docstring for x']*) -> None
|
| docstring for class A.
|
| Methods defined here:
|
| __eq__(self, other)
|
| __init__(self, x: *typing.Annotated[int, 'docstring for x']*) -> None
|
| __repr__(self)
|
| --
| Data descriptors defined here:
|
| __dict__
| dictionary for instance variables (if defined)
|
| __weakref__
| list of weak references to the object (if defined)
|
| --
| Data and other attributes defined here:
|
| __annotations__ = {'x': *typing.Annotated[int, 'docstring for x']*}
|
| __dataclass_fields__ = {'x': Field(name='x',type=
*typing.Annotated[int,..*.
|
| __dataclass_params__ =
_DataclassParams(init=True,repr=True,eq=True,or...
|
| __hash__ = None
---
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/BXCEE4G6SDYWI4LQMTPZ3AWAJN2I3EMD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
Ricky Teachey wrote:
> Could this be a use case for typing.Annotated?
> In [6]: from dataclasses import dataclass
> In [7]: from typing import Annotated
> In [8]: class A:
>...: """Docstring for class A."""
>...: x: Annotated[int, "Docstring for x"]
>...: y: Annotated[bool, "Docstring for y"] = True
> In [9]: A.__annotations__
> Out[9]:
> {'x': typing.Annotated[int, 'Docstring for x'],
> 'y': typing.Annotated[bool, 'Docstring for y']}
> The syntax is a bit arduous; I'd be in favor of thinking through ways to
> make it easier to write. But the basic functionality already exists;
> there's no reason to duplicate it with another language feature.
> Rick.
> ---
> Ricky.
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
> On Thu, Nov 18, 2021 at 5:50 AM tmkehrenb...@gmail.com wrote:
> > Stephen J. Turnbull wrote:
> > @standard_class_docstring_parser
> > class A:
> > """
> > Class docstring.
> > x: Docstring for x
> > y: Docstring for y
> > """
> > x: int
> > y: bool = True
> > Oh, this is actually a nice idea. You could have a
> > decorator that parses reST and then according
> > to some conventions extracts the attribute
> > docstrings. I think I will try to write something like
> > that.
> > Thomas
> > ___
> > 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/F2QJ3Q...
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
I think you need to use another type rather than a plain string here eg:
```
@dataclasses.dataclass(frozen=True)
class Doc:
v: str
@dataclasses.dataclass
class A:
"""docstring for class A."""
x: typing.Annotated[int, Doc("docstring for x")]
```
___
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/VAQA5BDLL3PZAGDP6YW4Y4APDMMTGQCP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
On 17.11.2021 15:26, tmkehrenb...@gmail.com wrote:
> Hi all,
>
> I have seen discussion of docstrings for class attributes before on this
> list, but not with this exact proposal.
>
> My motivation is that I have a dataclass for which I want to write
> docstrings that can be accessed at runtime. In my specific case, the
> docstrings would be used to create a help message.
>
> Sphinx supports a syntax to document class attributes. It looks like
> this:
>
> @dataclass
> class A:
> """Docstring for class A."""
> x: int
> """Docstring for x"""
> y: bool = True
> "Docstring for y"
See https://www.python.org/dev/peps/pep-0224/
Perhaps it's time to revive the idea for its 20th anniversary :-)
> It is a bit awkward that the docstring is *below* the definition of the
> attribute, but it can't be put above because it could be confused for
> the class docstring.
>
> My proposal would be to just enshrine this syntax as the syntax for
> attribute docstring, and to make them available at runtime. They would
> be stored in a dictionary like the type annotations. For example like
> this:
>
> A.__attrdoc__ == {"x": "Docstring for x", "y": "Docstring for y"}
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Nov 18 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/
___
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/HLBTXCBOTQYD7JJ5WVH3TZEVJEB6H2XB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
+1
On Thu, Nov 18, 2021 at 09:31 Michael Foord wrote:
>
>
> On Thu, 18 Nov 2021 at 04:38, Steven D'Aprano wrote:
>
>> On Wed, Nov 17, 2021 at 02:26:16PM -, tmkehrenb...@gmail.com wrote:
>>
>> > @dataclass
>> > class A:
>> > """Docstring for class A."""
>> > x: int
>> > """Docstring for x"""
>> > y: bool = True
>> > "Docstring for y"
>> >
>> > It is a bit awkward that the docstring is *below* the definition of the
>> > attribute, but it can't be put above because it could be confused for
>> > the class docstring.
>>
>> Function and class docstrings follow *below* the function/class
>> signature, so I don't think that's a problem.
>>
>> However a real problem is that bare strings like that are already legal,
>> although only as a no-op. People sometimes use them as multiline
>> comments.
>>
>> So we would have no real way of distinguishing between these cases:
>>
>> class A:
>> """Docstring for class A."""
>> x: int
>> """Docstring for x"""
>> y: bool = True
>> """Just a comment."""
>>
>> Making such strings syntactically meaningful would be a breaking change,
>> although one with a very small impact. (Some strings which were
>> previously ignored by the interpreter will now be kept in memory as
>> docstrings.)
>>
>>
> It wouldn't be a breaking change, there's no compatibility issue as
> nothing could break from this. It's a new feature so you'd have an
> unexpected attribute docstring that you're not using.
>
> Michael
>
>
>
>>
>> > My proposal would be to just enshrine this syntax as the syntax for
>> > attribute docstring, and to make them available at runtime. They would
>> > be stored in a dictionary like the type annotations. For example like
>> > this:
>> >
>> > A.__attrdoc__ == {"x": "Docstring for x", "y": "Docstring for y"}
>>
>> You could get that same effect with a decorator:
>>
>>
>> @attrdoc(x="Doctring for x",
>> y="Doctring for y")
>> class A:
>> """Class docstring."""
>> x: int
>> y: bool = True
>>
>>
>> There's some duplication of the names, which is sad, but otherwise I
>> don't mind it.
>>
>> --
>> 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/2F7CZRNSEEWRIBUFTTR3CBTLWO6APKJW/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
>
> Michael Foord
>
> Python Consultant, Contractor and Trainer
>
> https://agileabstractions.com/
>
> ___
> 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/OGSJU4YK6WX6FNK3C5BWCOPYCZMHRJ4P/
> 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/JCMMFJO3VSEPQN5YMALAL55GW2XM5ALS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
On Thu, 18 Nov 2021 at 04:38, Steven D'Aprano wrote:
> On Wed, Nov 17, 2021 at 02:26:16PM -, tmkehrenb...@gmail.com wrote:
>
> > @dataclass
> > class A:
> > """Docstring for class A."""
> > x: int
> > """Docstring for x"""
> > y: bool = True
> > "Docstring for y"
> >
> > It is a bit awkward that the docstring is *below* the definition of the
> > attribute, but it can't be put above because it could be confused for
> > the class docstring.
>
> Function and class docstrings follow *below* the function/class
> signature, so I don't think that's a problem.
>
> However a real problem is that bare strings like that are already legal,
> although only as a no-op. People sometimes use them as multiline
> comments.
>
> So we would have no real way of distinguishing between these cases:
>
> class A:
> """Docstring for class A."""
> x: int
> """Docstring for x"""
> y: bool = True
> """Just a comment."""
>
> Making such strings syntactically meaningful would be a breaking change,
> although one with a very small impact. (Some strings which were
> previously ignored by the interpreter will now be kept in memory as
> docstrings.)
>
>
It wouldn't be a breaking change, there's no compatibility issue as nothing
could break from this. It's a new feature so you'd have an unexpected
attribute docstring that you're not using.
Michael
>
> > My proposal would be to just enshrine this syntax as the syntax for
> > attribute docstring, and to make them available at runtime. They would
> > be stored in a dictionary like the type annotations. For example like
> > this:
> >
> > A.__attrdoc__ == {"x": "Docstring for x", "y": "Docstring for y"}
>
> You could get that same effect with a decorator:
>
>
> @attrdoc(x="Doctring for x",
> y="Doctring for y")
> class A:
> """Class docstring."""
> x: int
> y: bool = True
>
>
> There's some duplication of the names, which is sad, but otherwise I
> don't mind it.
>
> --
> 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/2F7CZRNSEEWRIBUFTTR3CBTLWO6APKJW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Michael Foord
Python Consultant, Contractor and Trainer
https://agileabstractions.com/
___
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/OGSJU4YK6WX6FNK3C5BWCOPYCZMHRJ4P/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
I've seen this proposed before, but it is, as you said, a bit arduous. For dataclasses specifically, there is also another possibility: add a `doc` argument to dataclasses.field. Like this: from dataclasses import dataclass, field @dataclass class A: x: int = field(doc="Docstring for x.") y: bool = field(default=False, doc="Docstring for y.") And then it would be retrievable with dataclasses.fields(A). Thomas ___ 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/K7VUWXZQYPUMTRT5S553HRFVDHC2LDRJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
On Thu, Nov 18, 2021 at 10:28 AM Ricky Teachey wrote: > Could this be a use case for typing.Annotated? > > ... > > The syntax is a bit arduous; I'd be in favor of thinking through ways to > make it easier to write. But the basic functionality already exists; > there's no reason to duplicate it with another language feature. > > Rick. > Whoops sorry, forgot the @dataclass decoration: In [10]: @dataclass ...: class A: ...: """Docstring for class A.""" ...: x: Annotated[int, "Docstring for x"] ...: y: Annotated[bool, "Docstring for y"] = True ...: --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3RQNYZ2IG7QOORECD2DXO7BQ27AROCGX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
Could this be a use case for typing.Annotated?
In [6]: from dataclasses import dataclass
In [7]: from typing import Annotated
In [8]: class A:
...: """Docstring for class A."""
...: x: Annotated[int, "Docstring for x"]
...: y: Annotated[bool, "Docstring for y"] = True
In [9]: A.__annotations__
Out[9]:
{'x': typing.Annotated[int, 'Docstring for x'],
'y': typing.Annotated[bool, 'Docstring for y']}
The syntax is a bit arduous; I'd be in favor of thinking through ways to
make it easier to write. But the basic functionality already exists;
there's no reason to duplicate it with another language feature.
Rick.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
On Thu, Nov 18, 2021 at 5:50 AM wrote:
> Stephen J. Turnbull wrote:
> > @standard_class_docstring_parser
> > class A:
> > """
> > Class docstring.
> > x: Docstring for x
> > y: Docstring for y
> > """
> > x: int
> > y: bool = True
>
> Oh, this is actually a nice idea. You could have a
> decorator that parses reST and then according
> to some conventions extracts the attribute
> docstrings. I think I will try to write something like
> that.
>
> Thomas
> ___
> 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/F2QJ3Q3HFX5VR7MG37FXET5JJ2XVNKSF/
> 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/GXPHAXUXQ3UGWK6YZFSNVSWYGL22INDM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Python Developer’s Guide chinese version
hi all, I want to know does Python Developer’s Guide have chinese version, If not, i want to do some translation, may i tell to PSF(or other people) to grant authorization? May you also want to do this translation, please contact me. Best, bobozi ___ 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/WGNOF45NQWJF77MFDYTCJQENLW2CYD5A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
Neil Girdhar wrote: > The proposal to change list and str is way too ambitious. Maybe the uppercase versions of dict, list and tuple in the typing module could be turned into direct aliases of the built-in types? With Python 3.9, there is no real distinction anyway between builtins.list and typing.List, so might as well make the latter an alias of the former. That way, people can continue to use the lowercase versions or switch to the uppercase ones. You could then even go one step further and add uppercase aliases for str, int, float, bool to the typing module. Thomas ___ 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/6CIVN4Q5BVRL3WERQLQLM6KXDBID23YW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
Stephen J. Turnbull wrote: > @standard_class_docstring_parser > class A: > """ > Class docstring. > x: Docstring for x > y: Docstring for y > """ > x: int > y: bool = True Oh, this is actually a nice idea. You could have a decorator that parses reST and then according to some conventions extracts the attribute docstrings. I think I will try to write something like that. Thomas ___ 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/F2QJ3Q3HFX5VR7MG37FXET5JJ2XVNKSF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
On Thu, Nov 18, 2021 at 7:44 PM Stephen J. Turnbull
wrote:
>
> Steven D'Aprano writes:
> > On Wed, Nov 17, 2021 at 02:26:16PM -, tmkehrenb...@gmail.com wrote:
> >
> > > @dataclass
> > > class A:
> > > """Docstring for class A."""
> > > x: int
> > > """Docstring for x"""
> > > y: bool = True
> > > "Docstring for y"
>
> > However a real problem is that bare strings like that are already legal,
> > although only as a no-op. People sometimes use them as multiline
> > comments.
>
> I agree it's a real problem. But I don't think it's a show-stopper.
> That is, the proposal as written also seems to be a near no-op from
> the point of view of backwards compatibility (I guess if you list the
> attributes of the class you would discover the new dunder).
>
> > So we would have no real way of distinguishing between these cases:
> >
> > class A:
> > """Docstring for class A."""
> > x: int
> > """Docstring for x"""
> > y: bool = True
> > """Just a comment."""
>
> True, but why would one want to, except to save the space? And for
> that, there's -OO.
>
Possible wrinkle: What if a string literal immediately follows
something that isn't an attribute declaration?
class A:
"Class docstring"
x: int
"x docstring"
y: bool; True
"y docstring?"
print("Hello, world?")
"print docstring??"
def spam(self): ...
"spam docstring???"
I presume it would have to be permitted and ignored, as per current
behaviour (otherwise it'd create bizarre errors in currently-legal
code). But that may make for some hard-to-track-down bugs when there's
an error in a declaration, or when something technically breaks the
declaration from the docstring (like the presumably-unintended
semicolon in the y line).
I'm personally -0 on this - I don't declare class level type
annotations enough to want to use this, but if it existed, I'd
probably find a way to use it for a DSL or something. It's of minimal
value, but it should also be of minimal disruption.
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/D6QWPRMYETJCGQOWRUH2KBW2ZHMPCDE2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
Steven D'Aprano writes:
> On Wed, Nov 17, 2021 at 02:26:16PM -, tmkehrenb...@gmail.com wrote:
>
> > @dataclass
> > class A:
> > """Docstring for class A."""
> > x: int
> > """Docstring for x"""
> > y: bool = True
> > "Docstring for y"
> However a real problem is that bare strings like that are already legal,
> although only as a no-op. People sometimes use them as multiline
> comments.
I agree it's a real problem. But I don't think it's a show-stopper.
That is, the proposal as written also seems to be a near no-op from
the point of view of backwards compatibility (I guess if you list the
attributes of the class you would discover the new dunder).
> So we would have no real way of distinguishing between these cases:
>
> class A:
> """Docstring for class A."""
> x: int
> """Docstring for x"""
> y: bool = True
> """Just a comment."""
True, but why would one want to, except to save the space? And for
that, there's -OO.
> > A.__attrdoc__ == {"x": "Docstring for x", "y": "Docstring for y"}
>
> You could get that same effect with a decorator:
>
>
> @attrdoc(x="Doctring for x",
> y="Doctring for y")
> class A:
> """Class docstring."""
> x: int
> y: bool = True
Such a decorator moves the documentation even farther from its
subjects? And doesn't simply
class A:
"""Class docstring."""
__attrdoc__ == {"x": "Docstring for x", "y": "Docstring for y"}
x: int
y: bool = True
do the trick? Or if you just like decorating (bear with me now, this
is revolutionary):
@standard_class_docstring_parser
class A:
"""
Class docstring.
x: Docstring for x
y: Docstring for y
"""
x: int
y: bool = True
which must exist somewhere already (I'm sure Sphinx has a nice fancy
function for this).
I guess that brings me all the way to -1 on the proposal as is; the
"below the attribute" syntax isn't sufficiently attractive to justify
syntax.
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/FFL3B6ZK7QGVAACZK775AOSHHM7SSDMT/
Code of Conduct: http://python.org/psf/codeofconduct/
