[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

[Greg Ewing]

On 17/12/21 6:58 pm, Steven D'Aprano wrote:


Or a Doctor Who episode. Doctor Who and the Immortal Instances of Doom.


Hmmm... and Guido has a time machine... Is it possible he's
secretly a Time Lord?

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

[Python-Dev] Re: The python command help is too long

[Guido van Rossum]

On Sat, Dec 18, 2021 at 2:16 PM Serhiy Storchaka 
wrote:

> The output of "python -h" is 104 lines long now. It was only 51 lines in
> 3.6. 35% of it is about the -X option, and 30% about environment
> variables. Also some lines in the -X option description are too long
> (102 columns). Both topics are "advanced" and mostly interested for
> debugging. I suggest to move them out of the main help output.
>

Sounds like a good plan.


> The are two options:
>
> 1. Move it to pydoc topics. The advantage is that it is a standard way,
> there are already 88 topics. The disadvantage is that this information
> will be not available in "minimal" installations of Python which do not
> include docs.
>
> 2. Add command-line options like -hX and -henv. The information will
> always be available with the interpreter, but the interface is special.
>

For -X, I suggest we could output the following line:

-X opt : implementation-specific option; use -X help to list options.

We could also see if we can put the help text for each of the supported -X
flags in the table defining these flags (sorry, I can't recall where it
lives, but I'm pretty sure I've seen such a table.)

For env vars I think moving this to pydoc is fine; I don't think we have a
process or mechanism that ensures the docs for env vars are even complete.
(We don't have one for the flags either, but somehow I find it hard to
conceive of someone adding a new command line flag without them or someone
else involved in the code review thinking of updating the help text. But I
find it quite conceivable that someone adds a new env var used only in a
corner case without anyone thinking to update the docs. And I presume that
the -E flag isn't honored 100% of the time either.)

But I wouldn't object to a -h sub-option that lists environment vars either.

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

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

[Python-Dev] The python command help is too long

[Serhiy Storchaka]

The output of "python -h" is 104 lines long now. It was only 51 lines in
3.6. 35% of it is about the -X option, and 30% about environment
variables. Also some lines in the -X option description are too long
(102 columns). Both topics are "advanced" and mostly interested for
debugging. I suggest to move them out of the main help output.

The are two options:

1. Move it to pydoc topics. The advantage is that it is a standard way,
there are already 88 topics. The disadvantage is that this information
will be not available in "minimal" installations of Python which do not
include docs.

2. Add command-line options like -hX and -henv. The information will
always be available with the interpreter, but the interface is special.

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

[Python-Dev] Re: RFC on Callable Syntax PEP

[Batuhan Taskaya]

I think I've posted it as a standalone reply (sorry for my bad mailing list 
skills), so linking my thread about potential concerns/reservations: 
https://mail.python.org/archives/list/python-dev@python.org/thread/FI4AFU3I25PECARIH2EVKAD5C5RJRE2N/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4QFTYRBXNNIIJ7S3ZXDNBDZS63OBHLQT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on Callable Syntax PEP

[Paul Moore]

I agree. The same concerns and reservations apply for me.

On Sat, 18 Dec 2021 at 21:13, Terry Reedy  wrote:
>
> Batuhan expresses my concerns better than I could, so I just add my
> agreement.
>
> On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:
>
> > tl;dr: I find it very troubling that we are going on a path where need
> > to increase the language complexity (syntax) only in the cause
> > 'easier' typing. So I am opposed to this change.
>
> --
> Terry Jan Reedy
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/G6PD5KYVI3CCAPFEOQ3VT7QJAN3Y6Z6W/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LS7DT7QVJ5RO5VX4IVCBMVQILGD2UQMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on Callable Syntax PEP

[Terry Reedy]

Batuhan expresses my concerns better than I could, so I just add my 
agreement.


On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:


tl;dr: I find it very troubling that we are going on a path where need
to increase the language complexity (syntax) only in the cause
'easier' typing. So I am opposed to this change.


--
Terry Jan Reedy

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

[Python-Dev] Re: RFC on Callable Syntax PEP

[Batuhan Taskaya]

First of all, thank you for authoring a really well-written PEP.

tl;dr: I find it very troubling that we are going on a path where need
to increase the language complexity (syntax) only in the cause
'easier' typing. So I am opposed to this change.

Most of the native typing use cases until now (PEP 585 / PEP 604) was
using the existing syntax, with slight adjustments on runtime. And
personally, I really liked them (being able to write `list[int | str]`
is nice), but not as much as I like the simplicity of the language. I
think the new syntax proposal for only a typing use case is really
destructive when we already have a very formal way of creating
callable types. I personally don't think it is verbose (as claimed by the PEP),
since the only thing that we have an extra is the `Callable` name. Aside from
these concerns, a few comments on the actual proposal:

- The syntax itself would probably confuse people, considering in
other languages (like javascript) the arrow functions are a thing that
loosely translates to our lambdas. People might try to write code like
`(x, y) -> x + y`, with the expectation that it would work (since it
is a valid syntax now), but it would immediately throw an error (if
x/y is not defined) and create confusion.

- Callables that return callables look very awkward with a double
arrow. `) -> (int, str) -> R:` (compared to `) -> Callable[[int, str],
R]:`. This was one of the examples that really made me look twice to
understand.

- `async` keyword used to be coupled with `def`/`for`/`with`, but
without any of these, it doesn't feel good to have it as some sort of
prefix to these expressions. I think it would be nice if the PEP can
address how much of the code out there uses `Callable[...,
Awaitable[...]]` syntax, since from what I understand by the current
proposal `async (int, str) -> bool` is the same with `(int, str) ->
Awaitable[bool]`, which is, in theory, a new syntax that we might be
adding for a very restricted use case.

- The parameter part (`(x, y) -> `) seem to be even diverging from an
actual expression (by allowing standalone [double-]starred operations,
and disallowing `(int, ...) ->`), which I think would complicate the
actual parsing process (even though we have an advanced parser in
CPython, that does not mean community maintained projects such as
jedi, parso, black will have one).

- Out of 4 concerns that are listed on the PEP about the current
callable syntax; only 1 is about the actual runtime behaviour, which
even if I did not agree initially, we have other solutions. Like an
open issue on the tracker about making `callable()` generic
https://bugs.python.org/issue42102.

- The other 3 is pretty much the same, claiming the syntax is dense.
Which I partly agree on. We probably could find other solutions (using
tuples to represent the parameter group, etc.), but I do not see those
points as very big deals (at least not as big as adding a very
complicated piece of new syntax).

I would assume some of these were previously discussed during the
typing-sig/python-dev threads, but as someone who recently learned
about this proposal, I feel like this is really overworked for a
problem that is (subjectively, again) small.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FI4AFU3I25PECARIH2EVKAD5C5RJRE2N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

[Antoine Pitrou]

On Sat, 18 Dec 2021 08:40:57 -
"Jim J. Jewett"  wrote:
> Why are Immutability and transitive Immortality needed to share an object 
> across interpreters? 

Immutability is a functional requirement: you don't want one
interpreter to be able to change the state of another one by mistake.
Unlike multi-threading, where shared mutable state is a feature, 
a multi-interpreter setup is defined by full semantic isolation
between interpreters (even if some structures may technically be shared
under the hood: e.g. process-wide immortal immutable objects).

As for transitive immortality, it is just a necessary effect of
immortality: if an object is immortal, by construction all the objects
that it references will also be immortal.  For example, if you decide
that the tuple `("foo", "bar")` is immortal, then the "foo" and "bar"
strings will also be *de facto* immortal, even if they are not
explicitly marked as such.

Regards

Antoine.



> 
> Are you assuming that a change in one interpreter should not be seen by 
> others?  (Typical case, but not always true.)  
> 
> Or are you saying that there is a technical problem such that a change -- 
> even just to the reference count of a referenced string or something -- would 
> cause data corruption?  (If so, could you explain why, or at least point me 
> in the general direction?)
> 
> -jJ



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

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

[Jim J. Jewett]

Why are Immutability and transitive Immortality needed to share an object 
across interpreters?  

Are you assuming that a change in one interpreter should not be seen by others? 
 (Typical case, but not always true.)  

Or are you saying that there is a technical problem such that a change -- even 
just to the reference count of a referenced string or something -- would cause 
data corruption?  (If so, could you explain why, or at least point me in the 
general direction?)

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