[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

[Neil Muller]

On Thu, 13 Jan 2022 at 02:31, Steven Barker  wrote:
>
> While f-strings in class scope could theoretically be valid docstrings a lot 
> of the time, the equivalent situation for function docstrings is much less 
> positive. A function like this the one below obviously problematic, since the 
> f-string value is not a compile-time constant:
>
> def foo(x): f"is this a docstring? x is {x}"
>
> I'm pretty sure f-strings cannot be used as docstrings in other contexts 
> because of how broken they'd be in functions.
>

I don't have a horse in the race of whether this should be allowed or
not for constant f-strings. I do however believe that having something
like the example given previously where the code doesn't do what it
appears to do, by silently not setting the docstring without giving a
warning, is bad behaviour.

-- 
Neil Muller
drnlmul...@gmail.com
___
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/Y3AVDHPBVEEJERIG2P326XHR5FT6UAH5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 677 (Callable Type Syntax): Final Call for Comments

[Dennis Sweeney]

Like others expressed, I don't like the idea of the typing and non-typing parts 
of Python separating.

Has anyone considered adding a new special method like `__arrow__` or 
something, that would be user-definable, but also defined for tuples and types 
as returning a Callable? For example `int -> str` could mean Callable[[int], 
str], and (int, str) -> bool could mean Callable[[int, str], bool]. I would 
find that sort of semantics more agreeable since Python already has operators 
that dispatch to dunder methods, and anyone who knows how that bit of Python 
works would automatically mostly know how the new operator works.

If I understand right, this is a sort of combination of two things for which 
there is more precedent: first, adding a new operator based on the needs of a 
subset of users (the @ operator and __matmul__), and second, adding new 
operators to existing objects for the sake of typing (like the list[int] syntax 
in which type.__getitem__ was implemented to dispatch to 
the_type.__class_getitem__).

If people don't want to add a new operator and dunder, I assume using the right 
shift operator like `(int, bool) >> str` would be too cheesy?
___
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/GTYLK4QA6DHQDZH7NLYLELYCFUKOTNDT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

[Steven Barker]

On Wed, Jan 12, 2022 at 2:58 AM Neil Muller 
wrote:

> Having something that looks like it sets the docstring, but silently
> doesn't is very surprising, though. Linters can warn about this, but
> linters are not a universal fix, and this is something that
> superficially looks entirely reasonable.
>

While f-strings in class scope could theoretically be valid docstrings a
lot of the time, the equivalent situation for function docstrings is much
less positive. A function like this the one below obviously problematic,
since the f-string value is not a compile-time constant:

def foo(x): f"is this a docstring? x is {x}"

I'm pretty sure f-strings cannot be used as docstrings in other contexts
because of how broken they'd be in functions.

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

[Python-Dev] PEP 677 (Callable Type Syntax): Final Call for Comments

[Steven Troxler]

Hello all,

We’d like to make a last call for discussion on PEP 677: Callable Type Syntax 
[1] before sending this to the Steering Council.

For context, PEP 677 proposes an arrow-like callable syntax for python:
```
(int, str) -> bool # equivalent to Callable[[int, str], bool]
```

Thanks everyone for comments on our earlier thread [2]. We made some changes to 
the PEP, but not the proposal itself, in response to that discussion:
 - More discussion about readability of return types and parentheses
 - Noting that complex code might be improved by using TypeAliases
 - Discussion of additional ideas in the Rejected Alternatives section

Many of the concerns in the previous thread are about whether new callable 
syntax is worth the implementation complexity, which is an important question. 
We’ve seen demand for this from regular typed Python users. And given that 
Callable is one of the most used and complicated type annotations, we at 
typing-sig favor new syntax.

We have considered the feedback here and in typing-sig and feel that the syntax 
in the PEP is a reasonable tradeoff between usability and simplicity.

One concern raised was that the `async` portion of the proposed syntax may not 
be worthwhile, even if the rest of the proposal is. We considered removing it, 
but several heavy users of async pointed out [3] that:
 - For authors of large, typed async codebases, this syntax would be very 
helpful
 - For everyone else there’s minimal readability cost, because async callables
   will almost never come up.

As a result, we decided to leave it in for now, but would be happy to remove it 
if the SC would prefer that.

If there are no other concerns, we'd like to move forward and submit it to the 
SC.

Cheers,
Steven

---
[1] PEP 677: https://www.python.org/dev/peps/pep-0677/
[2] Previous RFC thread in python-dev: 
https://mail.python.org/archives/list/python-dev@python.org/thread/OGACYN2X7RX2GHAUP2AKRPT6DP432VCN/
 
[3] Discussion in typing-sig about removing `async` keyword: 
https://mail.python.org/archives/list/typing-...@python.org/thread/RFZOSCJHDS66MOVQO6XMVVX43VEKJJBW/
___
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/GQB36XDSPIJBAPBQCYVNVPGXS4W2NZA2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion: a little language for type definitions

[Steven D'Aprano]

TL;DR: declaration only syntax is a non-starter. Even if we tried to add 
specialised syntax that only appears in annotations, it would become a 
regular Python expression almost immediately.


On Sun, Jan 09, 2022 at 08:42:14AM -0800, Christopher Barker wrote:

> Is it more clear for readers to have two different (but related) related
> syntaxes for two different (but related) purposes, or to have one Sytax
> that is used in different ways?

That is not a valid "either/or" choice. The choice is:

* Python expressions that have multiple meanings (the status quo);

  (e.g. subscripting `obj[x]` already had 4+ meanings before its
  use in typing)

* or Python expressions that have multiple meanings, PLUS new 
  declaration syntax that is only valid in annotations.

And I will argue below that the culture of Python is such that the 
second choice is practically *impossible* without a radical shift in the 
culture.

Let's say that we decide to add specialist declaration-only syntax for 
type-hints. What next?

First, we need a way to distinguish between type-hints that are 
declarations from type-hints that are expressions. Let's say that we use 
the proposed t-string syntax:

spam: t"declaration goes here"

That tells the interpreter to treat everything inside the quotes as a 
pure declaration, not an expression, with no runtime effect.

I'm going to put aside the question of what syntax is allowed for the 
declarations inside the quotes, because that's actually not that 
important. What happens after we add this declaration syntax?

The first thing that happens is that people interested in runtime 
processing of annotations will want to inspect the declaration, without 
having to scan the source code (which might not be available).

Python has a strong culture of runtime introspection, starting with 
dir() way back in Python 1.x days, so if you think the core devs are 
going to resist the call to make those annotations visible at runtime, 
I think you are remarkably ~~wrong~~ optimistic :-)

That means that the declaration has to have a runtime effect. 
Something has to go into the `__annotations__` dict:

__annotations__['spam'] = ... # what goes here?

(It doesn't matter precisely what the value that goes into the mapping 
is, it could be a string, or a type object, whatever it is, it is a 
value.)

So our declaration is no longer a declaration, like `global`, it is an 
expression that returns a value. The parser merely restricts its use to 
annotations like `spam: t"declaration"`.

Why can't we use that nifty new declaration syntax in type aliases? I 
mean, it already evaluates to a value that can be inspected at runtime, 
so we just have to relax the restriction on where it can appear so we 
can use it in type aliases as well as directly in annotations:

T = t"declaration goes here"
spam: T|None

But if we can do that, then our declaration is just another expression.

It has a value, it can appear outside of annotations. People are going 
to want to treat it as a first-class value (no pun intended), even if 
only for testing purposes:

# Unit tests
for T in [t"declaration",
  t"another declaration",
  t"yet another",
  t"my hovercraft is full of eels"]:
self.assertIsInstance(T, typing.Generic)
...

Even if it doesn't happen from day 1, rapidly whatever restrictions on 
where the syntax is allowed will be relaxed, because that's the sort of 
language Python is. Once we make that first (and inevitable!) step to 
give these type declarations an introspectable value, then they will 
become first-class expressions as sure as death and taxes.

So I maintain that *declaration only syntax* is doomed. Whatever syntax 
we invent, there is going to be irresistable pressure to make it a 
first-class expression and not just restrict it to annotations.

And if that is the case, then why do we need the t-string quotes?

That's not a rhetorical question.

Something like t-string quotes, or some other pair of delimiters, *may* 
be useful if we have our hearts set on syntax which is radically 
different from regular Python expressions:

spam: t"array 1 to 50 of int"  # Hybrid of Pascal and Hyperscript
eggs: t"{(+⌿⍵)÷≢⍵}"  # I don't even...

Just as we have `[ ... ]` delimiters for list comprehensions. Maybe it 
turns out that there are cases where we need delimiters. But if so, I 
hope they aren't quotation marks (with or without the t-prefix), since 
that will be confusing as far as the existing use of strings as forward 
references.

But why do we want type hints to be so radically different from regular 
Python expressions? How does that make typing easier to read and the 
language less complicated, if we have to learn *two* languages to be 
fluent in Python instead of one?

Outside of that, the t-string delimiters are redundant. There is no need 
to wrap the proposed arrow syntax in quotes, as the PEP makes clear they 
can be handled 

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

[Guido van Rossum]

On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin  wrote:

> Matthew Rahtz wrote:
> > Hi everyone,
> >
> > We've got to the stage now with PEP 646 that we're feeling pretty happy
> > with it. So far though we've mainly been workshopping it in typing-sig,
> so
> > as PEP 1 requires we're asking for some feedback here too before
> submitting
> > it to the steering council.
> >
> > If you have time over the next couple of weeks, please take a look at the
> > current draft and let us know your thoughts:
> > https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of
> > sections are out of date; https://github.com/python/peps/pull/1880
> > clarifies which grammar changes would be required, now that PEP 637 has
> > been rejected. We also have a second PR in progress at
> > https://github.com/python/peps/pull/1881 clarifying some of the
> motivation.)
> >
> > Thanks!
> > Matthew and Pradeep
>
> Hi,
> I'm very late to the discussion -- I relied on the typing-sig and SC to
> handle this, but now that I'm on the SC, I no longer have that luxury :)
> This mail has my own opinions, not necessarily the SC's.
>
>
> I've read the PEP, and I quite like it! It's clear that typing-sig
> thought this through very well.
> The thing that surprised me is the proposed changes that affect more
> than typing annotations. Quite deep in the PEP, the "Grammar Changes"
> section explains the (quite exciting) change to make star-unpacking
> possible in normal indexing operations, e.g.::
>
>  idxs_to_select = (1, 2)
>  array[0, *idxs_to_select, -1]  # Equivalent to [0, 1, 2, -1]
>
> However, the PEP is silent about indexing assignment, e.g.::
>
>  array[0, *idxs_to_select, -1] = 1
>
> IMO, it would be very confusing to not keep these in sync. If they are,
> the assignment change should be documented and tested appropriately. Is
> that the plan?
>

The previous SC approved the PEP despite this.

If you want to convince the SC to request this feature parity in the PEP, I
won't stop you.

But unless that happens I would rather not update the PEP again (it's been
tough to get to this point).

Maybe you can write a separate PEP? That would probably be simpler for all
involved (the PEP 646 authors would not have to be involved, and the
separate PEP would be very straightforward.


> For a second point, the PEP says:
>
> > this PEP disallows multiple unpacked TypeVarTuples within a single type
> parameter list. This requirement would therefore need to be implemented in
> type checking tools themselves rather than at the syntax level.
>
> Typing annotations are sometimes used for other things than *static*
> typing, and I wouldn't be surprised if type checkers themselves started
> allowing this (as a non-standard extension in cases where things aren't
> ambiguous):
>
>  def tprod(Generic[*T1], Generic[*T2]) -> Generic[*T1, *T2]: ...
>

I don't think that sentence is trying to forbid this. The problem appears
in things like

def foo(*args: tuple[*Ts1, *Ts2]) -> ...

Maybe the wording in the PEP can be imrpoved?


> If multiple unpackings in a tuple aren't blocked by the compiler, they
> should be tested and documented as syntactically valid annotations --
> just not valid static typing annotations (even though other uses are
> currently deprecated). In particular, once the compiler allows multiple
> unpackings, disallowing them at the syntax level later would mean
> breaking backwards compatibility.
> Do we share that view?
>

Agreed that the syntax with multiple stars will not be deprecated at
runtime, but type checkers may reject it. (Just as type checkers reject
many other programs that would run fine.)


> And after reading the PEP again, I'm unclear on some details in the
> Aliases section. Could you please clarify these examples for me?
>
> SplitDataset = Tuple[Array[*Ts], Array[*Ts]]
> SplitDataset[Height]  # Valid? What would this be equivalent to?
>
>
> TwoArrays = Tuple[Array[*Ts1], Array[*Ts2]]
> TwoArrays[Height]  # Valid? Equivalent to what? How to specify this fully?
>

I'll leave this to the PEP authors to address.

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

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

[Petr Viktorin]

Matthew Rahtz wrote:

Hi everyone,

We've got to the stage now with PEP 646 that we're feeling pretty happy
with it. So far though we've mainly been workshopping it in typing-sig, so
as PEP 1 requires we're asking for some feedback here too before submitting
it to the steering council.

If you have time over the next couple of weeks, please take a look at the
current draft and let us know your thoughts:
https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of
sections are out of date; https://github.com/python/peps/pull/1880
clarifies which grammar changes would be required, now that PEP 637 has
been rejected. We also have a second PR in progress at
https://github.com/python/peps/pull/1881 clarifying some of the motivation.)

Thanks!
Matthew and Pradeep


Hi,
I'm very late to the discussion -- I relied on the typing-sig and SC to 
handle this, but now that I'm on the SC, I no longer have that luxury :)

This mail has my own opinions, not necessarily the SC's.


I've read the PEP, and I quite like it! It's clear that typing-sig 
thought this through very well.
The thing that surprised me is the proposed changes that affect more 
than typing annotations. Quite deep in the PEP, the "Grammar Changes" 
section explains the (quite exciting) change to make star-unpacking 
possible in normal indexing operations, e.g.::


idxs_to_select = (1, 2)
array[0, *idxs_to_select, -1]  # Equivalent to [0, 1, 2, -1]

However, the PEP is silent about indexing assignment, e.g.::

array[0, *idxs_to_select, -1] = 1

IMO, it would be very confusing to not keep these in sync. If they are, 
the assignment change should be documented and tested appropriately. Is 
that the plan?




For a second point, the PEP says:


this PEP disallows multiple unpacked TypeVarTuples within a single type 
parameter list. This requirement would therefore need to be implemented in type 
checking tools themselves rather than at the syntax level.


Typing annotations are sometimes used for other things than *static* 
typing, and I wouldn't be surprised if type checkers themselves started 
allowing this (as a non-standard extension in cases where things aren't 
ambiguous):


def tprod(Generic[*T1], Generic[*T2]) -> Generic[*T1, *T2]: ...

If multiple unpackings in a tuple aren't blocked by the compiler, they 
should be tested and documented as syntactically valid annotations -- 
just not valid static typing annotations (even though other uses are 
currently deprecated). In particular, once the compiler allows multiple 
unpackings, disallowing them at the syntax level later would mean 
breaking backwards compatibility.

Do we share that view?



And after reading the PEP again, I'm unclear on some details in the 
Aliases section. Could you please clarify these examples for me?


SplitDataset = Tuple[Array[*Ts], Array[*Ts]]
SplitDataset[Height]  # Valid? What would this be equivalent to?


TwoArrays = Tuple[Array[*Ts1], Array[*Ts2]]
TwoArrays[Height]  # Valid? Equivalent to what? How to specify this fully?


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

[Python-Dev] Re: [PSA] OpenSSL 3.0 support is preliminary and experimental

[Christian Heimes]

On 10/01/2022 17.01, Miro Hrončok wrote:

On 09. 01. 22 19:39, Christian Heimes wrote:

Hi,

I would like to remind everybody that Python's support for OpenSSL 3.0 
is preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code 
kinda works. However there are known performance regressions, missing 
features (e.g. usedforsecurity flag), and potential bugs cause by API 
incompatibilities.


Due to the experimental state I advise against using Python with 
OpenSSL 3.0 in production.


It may take a while until Python gains full support for the next 
version of OpenSSL. I have shifted my personal OSS time to more fun 
topics like performance and WASM. My work time is currently limited, too.


Hello Christian.

Do you think we should switch Python in Fedora 36 to OpenSSL 1.1.1? 
Python was naturally rebuilt with OpenSSL 3.0 when the distro upgraded 
OpenSSL. But the older version is still available.


Note that Fedora 36 is also "preliminary" so we still have time to make 
this decision until +- the beta freeze/release (end of February, early 
March this year).



Hi Miro,

I suggest to wait and re-evaluate the situation in a month from now. The 
situation might improve by then. OpenSSL Upstream is working on 
performance improvements. I have a pending fix for the hashlib 
usedforsecurity feature.


For the other issues, somebody has to put in the work and review all 
differences between OpenSSL 1.1.1 and 3.0.


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

[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

[Neil Muller]

On Wed, 12 Jan 2022 at 00:12, Eric V. Smith  wrote:
>
> On 1/11/2022 3:44 PM, Brett Cannon wrote:
>
>
>
> >>> class C: 'foo'
> ...
> >>> C.__doc__ == 'foo'
> True
>
> >>> class C: f'foo'
> ...
> >>> C.__doc__ == 'foo'
> False
> >>> C.__doc__ is None
> True
>
> And there's a test to make sure constant f-strings are not doc strings: 
> https://github.com/python/cpython/blob/dce642f24418c58e67fa31a686575c980c31dd37/Lib/test/test_fstring.py#L406
>

Having something that looks like it sets the docstring, but silently
doesn't is very surprising, though. Linters can warn about this, but
linters are not a universal fix, and this is something that
superficially looks entirely reasonable.

-- 
Neil Muller
drnlmul...@gmail.com
___
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/V3RS2Y2FGTIWLUMBAMJKRGHXUF4HUN2J/
Code of Conduct: http://python.org/psf/codeofconduct/