[Python-Dev] Re: PEP 674: Disallow using macros as l-value
Hi, The HPy project is great and I'm supporting this cool project! As I wrote, IMO it's the best solution for the long term. My first concern is that right now, HPy is not mature nor widely used, and CPython still has to continue supporting a large amount of C extensions which are not likely to be ported to HPy soon. Well, we can do nothing, continue supporting these C extensions unmodified and we're good. My second concern is the inability to evolve CPython internals to implement new optimizations, and the inefficient implementation of the current C API in PyPy, GraalPython, etc. Sadly, HPy will only solve these problems when the last C extensions will be ported to HPy: when it will be reasonable to drop CPython public C API. Since Python 2.7 is still used in 2021, I expect that porting most C extensions to HPy will take a few years. Porting a C extension to HPy can be done incrementally on CPython. But the port is not cheap, a lot of code has to be adapted. I'm proposing to make the C API "less bad" by fixing the parts which are clearly identified as "bad". Only a minority of C extensions require changes, and on these C extensions, usually only a few lines need to be changed. For example, numpy is made of 307,300 lines of C code, and adapting numpy to the PEP 674 only modified 11 lines (now using Py_SET_TYPE or Py_SET_SIZE) and to add 4 lines (to define Py_SET_TYPE/Py_SET_SIZE for Python 3.8 and older). I expect that porting numpy to HPy will require to modify more lines. Right now, it's hard to bet which approach is the best: fix the current C API, or focus on HPy. IMO it would be too risky to only bet on HPy. At least, the main advantage of HPy is that it's currently fully developed outside CPython and it doesn't require any change in the C API! Victor On Wed, Dec 8, 2021 at 6:21 PM Tim Felgentreff wrote: > > Hi, > > On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum wrote: > > I wonder if there's a role for HPy in this context? What if instead of > > evolving the stable ABI and the limited API, instead we were to focus on > > first-class support for HPy? > > The hope with the HPy project is indeed to provide a C API that is close to > the > original API to make porting easy and have it perform as close to the existing > API as possible. At the same time, HPy is sufficently removed to be a good "C > extension API" (as opposed to a stable subset of the CPython implementation > API) > that does not leak implementation details. To ensure this latter property is > why > we try to develop everything in parallel for CPython, PyPy, and GraalVM > Python. > > On Wed, 8 Dec 2021 01:47:38 +0100 Victor Stinner wrote: > > Providing HPy as a first-class citizen in CPython, as already done in > > PyPy, would be great to promote HPy! However, HPy evolves quickly and > > so needs to be released more frequently than CPython. At least, we > > could promote it more in the C API documentation, as we already > > promote Cython. > > Indeed, at this point HPy is still evolving very fast. We are still solving > issues while migrating NumPy, have begun adding support for HPy to Cython, > and will start working on pybind11 soon. I believe by the time we have these > users of the existing C API working, HPy should be in a state where it is > generally useful and can be deemed stable enough that further development can > follow a more stable process. > > > For me, HPy is the only valid stable API and stable ABI in the long > > term which is efficient on any Python implementation. Its design is > > very different than the C API: HPy avoids all C API design mistakes, > > it doesn't leak any implementation detail. > > In the long run the HPy project would like to become a promoted API to > write Python C extensions. > > Tim Felgentreff > (on behalf of the HPy team) > ___ > 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/2NFJC7UAVIQZ6BNV4NBTY3THI7OIJIMF/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/OKQC45FPL6PII2V5UICVL76VOSQILTYW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 674: Disallow using macros as l-value
On Tue, Dec 7, 2021 at 7:55 PM Sebastian Berg wrote: > One thing we once did in NumPy (for a runtime problem), was to > intentionally break everyone at pre-release/dev time to point out what > code needed fixing. Then flip the switch back at release time as to > not break production. > After a long enough time we enabled it for release mode. > > Not saying that it was nice, but it was the only alternative would have > been to never fix it. > > A similar switch could be worthwhile if it helps Victor with > experimenting on the dev-branch or reach a useful amount of projects. > Of course, I am not sure it would do either... Py_TYPE() and Py_SIZE() macros have been converted to static inline functions in May 2020 (Python 3.10 dev cycle): https://github.com/python/cpython/commit/ad3252bad905d41635bcbb4b76db30d570cf0087 Honestly, when the change was merged, I didn't expect that it would break anything. Sadly, it broke multiple projects, including important ones like Cython and numpy. So it was reverted in Python 3.10. Once enough projects got prepared for these changes, I merged again the change in Python 3.11. Then more affected projects have been discovered. I also worked on tooling to discover affected projects before users start complaining ;-) And I wrote the PEP 674 which documents and justify these changes ;-) Victor ___ 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/EMOJENDQVQOJQA5OHQ6OC5KCYC4PSR4A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring
On 1/11/2022 3:44 PM, Brett Cannon wrote:
On Tue, Jan 11, 2022 at 10:40 AM Gregory P. Smith wrote:
On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum
wrote:
I personally think F-strings should not be usable as
docstrings. If you want a dynamically calculated docstring you
should assign it dynamically, not smuggle it in using a
string-like expression. We don't allow "blah {x}
blah".format(x=1) as a docstring either, not "foo %s bar" % x.
Agreed. If we wanted to remove the wart of constant f-strings
happening to work as an implementation detail in this context,
that /could/ be made into a warning. But that kind of check may
be best left to a linter for /all/ of these dynamic situations
that don't wind up populating __doc__.
Agreed on not supporting it and linters catching such a mistake.
Just to be clear, we don't support this.
>>> 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
Eric
-Brett
-gps
On Tue, Jan 11, 2022 at 8:12 AM Antoine Pitrou
wrote:
On Tue, 11 Jan 2022 10:58:03 -0500
"Eric V. Smith" wrote:
> Constant f-strings (those without substitutions) as doc
strings used to
> work, since the compiler turns them into normal strings.
>
> I can't find exactly where it was removed, but there was
definitely
> discussion about it. See
https://bugs.python.org/issue28739 for at least
> part of the discussion.
Ah, sorry for the misunderstanding. While the example I
showed doesn't
have any substitutions, I'm interested in the non-trivial
(non-constant)
case actually :-)
Regards
Antoine.
>
> Eric
>
> On 1/11/2022 8:41 AM, Antoine Pitrou wrote:
> > Hello,
> >
> > Currently, a f-string is not recognized as a docstring:
> >
> class C: f"foo"
> C.__doc__
>
> > This means you need to use a (admittedly easy) workaround:
> >
> class C: __doc__ = f"foo"
> C.__doc__
> > 'foo'
> >
> > Shouldn't the former be allowed for convenience?
> >
> > Regards
> >
> > Antoine.
> >
> >
> > ___
> > 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/UALMEMQ4QW7W4HE2PIBARWYBKFWJZFB4/
> > 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/37YAHCREZYZFSV4BRDKUEQAX4ZF4JTI6/
Code of Conduct: http://python.org/psf/codeofconduct/
--
--Guido van Rossum (python.org/~guido )
/Pronouns: he/him //(why is my pronoun here?)/
[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring
On Tue, Jan 11, 2022 at 10:40 AM Gregory P. Smith wrote:
>
> On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum
> wrote:
>
>> I personally think F-strings should not be usable as docstrings. If you
>> want a dynamically calculated docstring you should assign it dynamically,
>> not smuggle it in using a string-like expression. We don't allow "blah {x}
>> blah".format(x=1) as a docstring either, not "foo %s bar" % x.
>>
>
> Agreed. If we wanted to remove the wart of constant f-strings happening
> to work as an implementation detail in this context, that *could* be made
> into a warning. But that kind of check may be best left to a linter for
> *all* of these dynamic situations that don't wind up populating __doc__.
>
Agreed on not supporting it and linters catching such a mistake.
-Brett
>
> -gps
>
>
>>
>> On Tue, Jan 11, 2022 at 8:12 AM Antoine Pitrou
>> wrote:
>>
>>> On Tue, 11 Jan 2022 10:58:03 -0500
>>> "Eric V. Smith" wrote:
>>> > Constant f-strings (those without substitutions) as doc strings used
>>> to
>>> > work, since the compiler turns them into normal strings.
>>> >
>>> > I can't find exactly where it was removed, but there was definitely
>>> > discussion about it. See https://bugs.python.org/issue28739 for at
>>> least
>>> > part of the discussion.
>>>
>>> Ah, sorry for the misunderstanding. While the example I showed doesn't
>>> have any substitutions, I'm interested in the non-trivial (non-constant)
>>> case actually :-)
>>>
>>> Regards
>>>
>>> Antoine.
>>>
>>>
>>> >
>>> > Eric
>>> >
>>> > On 1/11/2022 8:41 AM, Antoine Pitrou wrote:
>>> > > Hello,
>>> > >
>>> > > Currently, a f-string is not recognized as a docstring:
>>> > >
>>> > class C: f"foo"
>>> > C.__doc__
>>> >
>>> > > This means you need to use a (admittedly easy) workaround:
>>> > >
>>> > class C: __doc__ = f"foo"
>>> > C.__doc__
>>> > > 'foo'
>>> > >
>>> > > Shouldn't the former be allowed for convenience?
>>> > >
>>> > > Regards
>>> > >
>>> > > Antoine.
>>> > >
>>> > >
>>> > > ___
>>> > > 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/UALMEMQ4QW7W4HE2PIBARWYBKFWJZFB4/
>>> > > 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/37YAHCREZYZFSV4BRDKUEQAX4ZF4JTI6/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)*
>>
[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring
On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum wrote:
> I personally think F-strings should not be usable as docstrings. If you
> want a dynamically calculated docstring you should assign it dynamically,
> not smuggle it in using a string-like expression. We don't allow "blah {x}
> blah".format(x=1) as a docstring either, not "foo %s bar" % x.
>
Agreed. If we wanted to remove the wart of constant f-strings happening to
work as an implementation detail in this context, that *could* be made into
a warning. But that kind of check may be best left to a linter for *all*
of these dynamic situations that don't wind up populating __doc__.
-gps
>
> On Tue, Jan 11, 2022 at 8:12 AM Antoine Pitrou wrote:
>
>> On Tue, 11 Jan 2022 10:58:03 -0500
>> "Eric V. Smith" wrote:
>> > Constant f-strings (those without substitutions) as doc strings used to
>> > work, since the compiler turns them into normal strings.
>> >
>> > I can't find exactly where it was removed, but there was definitely
>> > discussion about it. See https://bugs.python.org/issue28739 for at
>> least
>> > part of the discussion.
>>
>> Ah, sorry for the misunderstanding. While the example I showed doesn't
>> have any substitutions, I'm interested in the non-trivial (non-constant)
>> case actually :-)
>>
>> Regards
>>
>> Antoine.
>>
>>
>> >
>> > Eric
>> >
>> > On 1/11/2022 8:41 AM, Antoine Pitrou wrote:
>> > > Hello,
>> > >
>> > > Currently, a f-string is not recognized as a docstring:
>> > >
>> > class C: f"foo"
>> > C.__doc__
>> >
>> > > This means you need to use a (admittedly easy) workaround:
>> > >
>> > class C: __doc__ = f"foo"
>> > C.__doc__
>> > > 'foo'
>> > >
>> > > Shouldn't the former be allowed for convenience?
>> > >
>> > > Regards
>> > >
>> > > Antoine.
>> > >
>> > >
>> > > ___
>> > > 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/UALMEMQ4QW7W4HE2PIBARWYBKFWJZFB4/
>> > > 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/37YAHCREZYZFSV4BRDKUEQAX4ZF4JTI6/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
>
[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring
I personally think F-strings should not be usable as docstrings. If you
want a dynamically calculated docstring you should assign it dynamically,
not smuggle it in using a string-like expression. We don't allow "blah {x}
blah".format(x=1) as a docstring either, not "foo %s bar" % x.
On Tue, Jan 11, 2022 at 8:12 AM Antoine Pitrou wrote:
> On Tue, 11 Jan 2022 10:58:03 -0500
> "Eric V. Smith" wrote:
> > Constant f-strings (those without substitutions) as doc strings used to
> > work, since the compiler turns them into normal strings.
> >
> > I can't find exactly where it was removed, but there was definitely
> > discussion about it. See https://bugs.python.org/issue28739 for at
> least
> > part of the discussion.
>
> Ah, sorry for the misunderstanding. While the example I showed doesn't
> have any substitutions, I'm interested in the non-trivial (non-constant)
> case actually :-)
>
> Regards
>
> Antoine.
>
>
> >
> > Eric
> >
> > On 1/11/2022 8:41 AM, Antoine Pitrou wrote:
> > > Hello,
> > >
> > > Currently, a f-string is not recognized as a docstring:
> > >
> > class C: f"foo"
> > C.__doc__
> >
> > > This means you need to use a (admittedly easy) workaround:
> > >
> > class C: __doc__ = f"foo"
> > C.__doc__
> > > 'foo'
> > >
> > > Shouldn't the former be allowed for convenience?
> > >
> > > Regards
> > >
> > > Antoine.
> > >
> > >
> > > ___
> > > 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/UALMEMQ4QW7W4HE2PIBARWYBKFWJZFB4/
> > > 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/37YAHCREZYZFSV4BRDKUEQAX4ZF4JTI6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring
On Tue, 11 Jan 2022 10:58:03 -0500 "Eric V. Smith" wrote: > Constant f-strings (those without substitutions) as doc strings used to > work, since the compiler turns them into normal strings. > > I can't find exactly where it was removed, but there was definitely > discussion about it. See https://bugs.python.org/issue28739 for at least > part of the discussion. Ah, sorry for the misunderstanding. While the example I showed doesn't have any substitutions, I'm interested in the non-trivial (non-constant) case actually :-) Regards Antoine. > > Eric > > On 1/11/2022 8:41 AM, Antoine Pitrou wrote: > > Hello, > > > > Currently, a f-string is not recognized as a docstring: > > > class C: f"foo" > C.__doc__ > > > This means you need to use a (admittedly easy) workaround: > > > class C: __doc__ = f"foo" > C.__doc__ > > 'foo' > > > > Shouldn't the former be allowed for convenience? > > > > Regards > > > > Antoine. > > > > > > ___ > > 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/UALMEMQ4QW7W4HE2PIBARWYBKFWJZFB4/ > > 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/37YAHCREZYZFSV4BRDKUEQAX4ZF4JTI6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring
Constant f-strings (those without substitutions) as doc strings used to work, since the compiler turns them into normal strings. I can't find exactly where it was removed, but there was definitely discussion about it. See https://bugs.python.org/issue28739 for at least part of the discussion. Eric On 1/11/2022 8:41 AM, Antoine Pitrou wrote: Hello, Currently, a f-string is not recognized as a docstring: class C: f"foo" C.__doc__ This means you need to use a (admittedly easy) workaround: class C: __doc__ = f"foo" C.__doc__ 'foo' Shouldn't the former be allowed for convenience? Regards Antoine. ___ 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/UALMEMQ4QW7W4HE2PIBARWYBKFWJZFB4/ 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/NCJKOGE4UKHTGBWZOLPAAWZ2DVU4FLZZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Status of Python 3.11.0a4
Hi everyone, I want to report on the status of Python 3.11.0a4. We had a ton of release blockers (some extra ones since I reported the last time) and it seems that we managed to fix them all (thanks to Mark Shannon, Christian Heimes, Gregory P. Smith, Neil Schemenauer, Steve Dower and many others that helped with the blockers. Unfortunately it seems that the release is cursed and we are having some problems with the certificates to create and sign the Windows artefacts so we are waiting for that to unblock us. I will keep you posted on new developments. Regards from rainy London, Pablo Galindo Salgado ___ 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/RZ7EJU66R5J3IMVCPP43ICZ23SQZNCP5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Minor inconvenience: f-string not recognized as docstring
Hello, Currently, a f-string is not recognized as a docstring: >>> class C: f"foo" >>> C.__doc__ >>> This means you need to use a (admittedly easy) workaround: >>> class C: __doc__ = f"foo" >>> C.__doc__ 'foo' Shouldn't the former be allowed for convenience? Regards Antoine. ___ 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/UALMEMQ4QW7W4HE2PIBARWYBKFWJZFB4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [PSA] OpenSSL 3.0 support is preliminary and experimental
On 11/01/2022 12.02, Antoine Pitrou wrote: Hi Christian, On Sun, 9 Jan 2022 19:39:06 +0100 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. Sounds reasonable :-) Out of curiosity, what are the performance regressions about? OpenSSL 3.0 introduced a new context, provider, and algorithm fetch system. It is not optimized yet and has an impact on performance. I noticed that hashlib.sha512(b'12345678') is more than 20% slower with new EVP_MD_fetch() API. Impact on multi threading applications is even bigger due to lock congestion. https://github.com/openssl/openssl/issues/17064 ___ 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/CWM32SJHRXIPM2YZDCTUHZRT5ETE2FGH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [PSA] OpenSSL 3.0 support is preliminary and experimental
Hi Christian, On Sun, 9 Jan 2022 19:39:06 +0100 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. Sounds reasonable :-) Out of curiosity, what are the performance regressions about? Regards Antoine. ___ 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/OQUXLOUHOJZXOKWZSNOIYJHOFMJZIXR7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On Mon, 10 Jan 2022 at 23:04, Greg Ewing wrote:
>
> Most of the effort of learning to read type expressions, in any
> language, is learning their semantics, which is very different
> from value expressions. Whether they happen to superficially
> resemble other parts of the language is pretty much irrelevant
> to me.
While this is true, what *is* a problem with having a different
language, is that you have two very similar syntactic constructs
("expression" and "type expression") and you have to learn which can
be used where. And that's actually not as trivial as you'd think at
first.
The typing.cast function takes a type expression as its first
parameter. If type expressions are not expressions, syntactically,
then that means that typing.cast(MyType, obj) is *not* syntactically a
function call. So what is it? Say it's a new syntactic element, a
"cast expression". Then the syntax for an expression must be extended
to include cast expressions. And what *is* the syntax of a cast
expression? "cast_literal(type_expr, expr)"? Then what's
"cast_literal"? The value "typing.cast"? What about "from typing
import cast", or "import typing as t" with "t.cast", or "from typing
import cast as typecast", or even "my_cast = getattr(typing, "cast")?
Suddenly there are a huge number of unanswered questions to be
considered, and the answers to those questions need to be learned by
people.
Paul.
PS Having said that, existing type checkers may or may not recognise
all of the possible ways to call the cast function that I described.
Do we want to mandate what type checkers do as part of the language
definition? Do we want to restrict the language definition based on
what 3rd party type checkers can achieve?
___
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/LVLWHVSIF3WKDHFPF5MSOYEFR37FBXW2/
Code of Conduct: http://python.org/psf/codeofconduct/
