[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Antoine Pitrou]

On Fri, 15 Oct 2021 12:36:15 +1100
Steven D'Aprano  wrote:
> Hello Doug,
> 
> On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
> 
> > I believe strong and valid arguments can be made about the use of None 
> > being a fundamental flaw in some types of coding  
> 
> Can you elaborate on that? Obviously it is not always appropriate to use 
> None, but I've never seen it called a *fundamental* flaw.
> 
> I know that the null pointer has been called a billion-dollar mistake,
> but Python's None is not a null pointer.

(except in Cython, but that's Cython's fault here)

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

[Python-Dev] Re: What is __int__ still useful for?

[Mark Dickinson]

I'd propose that we relegate `__trunc__` to the same status as `__floor__`
and `__ceil__`: that is, have `__trunc__` limited to being support for
`math.trunc`, and nothing more. Right now the `int` constructor potentially
looks at all three of `__int__`, `__index__` and `__trunc__`, so the
proposal would be to remove that special role of `__trunc__` and reduce the
`int` constructor to only looking at `__int__` and `__index__`.

Obviously that's a backwards incompatible change, but a fairly mild one,
with an obvious place to insert a `DeprecationWarning` and a clear
transition path for affected code: code that relies on `int` being able to
use `__trunc__` would need to add a separate implementation of `__int__`.
(We made this change recently for the `Fraction` type in
https://bugs.python.org/issue44547.)

I opened an issue for this proposal a few weeks back:
https://bugs.python.org/issue44977

Mark




On Thu, Oct 14, 2021 at 11:50 AM Serhiy Storchaka 
wrote:

> 14.10.21 12:24, Eryk Sun пише:
> > Maybe an alternate constructor could be added -- such as
> > int.from_number() -- which would be restricted to calling __int__(),
> > __index__(), and __trunc__().
>
> See thread "More alternate constructors for builtin type" on Python-ideas:
>
> https://mail.python.org/archives/list/python-id...@python.org/thread/5JKQMIC6EUVCD7IBWMRHY7DRTTNSBOWG/
>
> ___
> 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/NU3774YDVCIUH44C7RZXCSSVRVYSLCUI/
> 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/WX6246JW43A25MJJ6YRBLTN3GCQQQXZF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What is __int__ still useful for?

[Mark Dickinson]

Meta: apologies for failing to trim the context in the previous post.

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

[Python-Dev] Re: What is __int__ still useful for?

[Eryk Sun]

On 10/15/21, Mark Dickinson  wrote:
>
> the proposal would be to remove that special role of `__trunc__` and
> reduce the `int` constructor to only looking at `__int__` and `__index__`.

For Real and Rational numbers, currently the required method to
implement is __trunc__(). ISTM that this proposal should include a
change to require __int__() in numbers.Real.
___
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/R3JI6EGLMMBDNPCKFSNPLUNR2Q3ISAID/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Documenting Python versioning and stability expectations

[Petr Viktorin]

Hello,
I heard not everyone is Discourse, so I'm re-posting here as well.



Information about  is current scattered over the FAQs, active 
PEPs (387, 602), an active-but-severely-outdated PEP (6) and the Devguide.


I would like to consolidate as much of this as possible into user-facing 
reference documentation.


* Does that sound like a good idea?
* Where in the docs should such a page live?

Here is a draft of the docs; if added they’d be accompanied by more changes:

* The relevant FAQs would be replaced by links to these docs
* PEP 6 would be retired in favor of 602, 387 and these docs
* Parts of PEP 387/602 might be replaced by links here (or this document 
should link to the PEP rather than duplicating it)
* The examples of “backwards-incompatible APIs” from PEP 387 would only 
live in one place, and be linked from the other.
* C-API stability docs should link back to this more general document. 
(Details specific to the C-API shoudl still be there.)


Most of this is, hopefully, just capturing existing tribal knowledge, but:

* the “Unstable API” section contains several additional examples that 
PEP 387 doesn’t have. I’m proposing them as an update to the PEP; all of 
this will need SC approval anyway.
* “Most planned changes (such as removal of deprecated features) are 
done in alpha releases.” – this is also a newly proposed rule; I intend 
to formalize it further for the devguide. Combined with our deprecation 
periods, this rule would allow more time for testing the actual effect 
of removals.



A rendered (and up-to-date) version is at:
https://github.com/encukou/cpython/blob/cpython-version-docs/Doc/stability-docs/index.rst







.. _python-versioning:

==
Python's Versioning and Stability Expectations
==


Python Versions
===

The Python language is developed together with its reference
:ref:`implementation `, *CPython*.  Both share the same
release schedule and versioning scheme.

Production-ready Python versions numbered with three numbers,
``major.minor.micro``.

* New *major* versions are exceptional, and are planned very long in 
advance.

* New *minor* versions are feature releases; they get released annually.
* New *micro* versions are *bugfix* releases, which get released roughly
  every 2 months for 5 years after a minor release; or *security* releases
  which are made irregularly afterwards.

We also publish non-final *pre-release* versions with an additional
qualifier: *Alpha* (``a``), *Beta* (``b``) and *release candidates* 
(``rc``).
These versions are not production use; they're aimed at testers and 
maintainers

of third-party libraries.

The version number is combined into a single string, for example:


+--+---+---+---++
   | Version  | Major | Minor | Micro | Prerelease 
   |


+==+===+===+===++
   | Python ``3.6.3`` | 3 | 6 | 3 | Final 
(production-ready)   |


+--+---+---+---++
   | Python ``3.7.0a3``   | 3 | 7 | 0 | Third *alpha* 
   |


+--+---+---+---++
   | Python ``3.9.4b1``   | 3 | 9 | 4 | First *beta* 
   |


+--+---+---+---++
   | Python ``2.7.14rc2`` | 2 | 7 | 14| Second *release 
candidate* |


+--+---+---+---++

When discussing features that do not change in *micro* or *minor* releases,
or ones that are new in `x.y.0` or `x.0.0` versions,
it is common to only specify the relevant numbers:

   +-+---+---+---+
   | Version | Major | Minor | Micro |
   +=+===+===+===+
   | Python ``3.10`` | 3 | 10| any   |
   +-+---+---+---+
   | Python ``3``| 3 | any   | any   |
   +-+---+---+---+


See also the documentation for :data:`sys.version_info`,
:data:`sys.hexversion`, :data:`sys.version`, and :ref:`apiabiversion`,
which expose version numbers in different formats.


.. _python-releases:

Python Releases
===

All releases, including pre-releases, are available
from https://www.python.org/downloads/.  New releases are announced on the
comp.lang.python and comp.lang.python.announce newsgroups and on the Python
home page at `python.org`_; an RSS feed of news is available.

.. _python.org: https://python.org


.. _python-stability:

Versioning details and Stability Expectations
=

This section documents stability expectations for the various types of 
Python

releases. It is intended for users of Python, th

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-10-08 - 2021-10-15)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7401 (+27)
  closed 49822 (+50)
  total  57223 (+77)

Open issues with patches: 2925 


Issues opened (50)
==

#35081: Move internal headers to Include/internal/
https://bugs.python.org/issue35081  reopened by vstinner

#35134: Add a new Include/cpython/ subdirectory for the "CPython API" 
https://bugs.python.org/issue35134  reopened by vstinner

#42248: Raised exception in Enum keeping user objects alive unnecessar
https://bugs.python.org/issue42248  reopened by pitrou

#44559: Enum: revert to 3.9
https://bugs.python.org/issue44559  reopened by pitrou

#45249: Update doctect SyntaxErrors for location range
https://bugs.python.org/issue45249  reopened by pablogsal

#45414: pathlib.Path.parents negative indexing is wrong for absolute p
https://bugs.python.org/issue45414  opened by josh.r

#45415: Assert oparg < INSTR_OFFSET()
https://bugs.python.org/issue45415  opened by steve.dower

#45417: Enum creation non-linear in the number of values
https://bugs.python.org/issue45417  opened by olliemath

#45420: Python 3.10 final installation failure
https://bugs.python.org/issue45420  opened by wyz23x2

#45423: SSL SNI varies when host contains port number
https://bugs.python.org/issue45423  opened by hexf

#45425: There is an error in the Chinese documentation of contextlib.A
https://bugs.python.org/issue45425  opened by laxtiz

#45427: importlib.readers.MultiplexedPath
https://bugs.python.org/issue45427  opened by daveraja

#45429: [Windows] time.sleep() should use CREATE_WAITABLE_TIMER_HIGH_R
https://bugs.python.org/issue45429  opened by vstinner

#45431: [C API] Rename CFrame or hide it to only export names starting
https://bugs.python.org/issue45431  opened by vstinner

#45435: delete misleading faq entry about atomic operations
https://bugs.python.org/issue45435  opened by graingert

#45436: test_tk.test_configure_type() failed on x86 Gentoo Non-Debug w
https://bugs.python.org/issue45436  opened by vstinner

#45438: inspect not capturing type annotations created by __class_geti
https://bugs.python.org/issue45438  opened by rhettinger

#45442: Update `Virtual Environment` tutorial
https://bugs.python.org/issue45442  opened by shivnaren

#45443: 'ThreadPoolExecutor' object has no attribute 'map'
https://bugs.python.org/issue45443  opened by zohim

#45444: test.test_concurrent_futures fail in x86_ 64 architecture
https://bugs.python.org/issue45444  opened by sxt1001

#45445: Fail if an invalid -X option is provided
https://bugs.python.org/issue45445  opened by pablogsal

#45446: Add a way to hide fields in dataclasses
https://bugs.python.org/issue45446  opened by formigacomcaimbra

#45447: IDLE: Support syntax highlighting for .pyi stub files
https://bugs.python.org/issue45447  opened by AlexWaygood

#45449: Document that collections.abc types are subscriptable
https://bugs.python.org/issue45449  opened by FFY00

#45450: Improve syntax error for parenthesized arguments
https://bugs.python.org/issue45450  opened by pablogsal

#45451: IDLE Shell GUI - remove window border
https://bugs.python.org/issue45451  opened by primexx

#45452: Support crash tolerance feature for gdbm module
https://bugs.python.org/issue45452  opened by corona10

#45455: Fill func.__doc__ lazily
https://bugs.python.org/issue45455  opened by methane

#45457: Documentation for ssl.load_default_certs is outdated
https://bugs.python.org/issue45457  opened by LincolnPuzey

#45459: Limited API support for Py_buffer
https://bugs.python.org/issue45459  opened by christian.heimes

#45460: distutils.sysconfig.get_python_lib() does not respect sysconfi
https://bugs.python.org/issue45460  opened by hroncok

#45463: Documentation inconsistency on the number of identifiers allow
https://bugs.python.org/issue45463  opened by lucach

#45464: TypeError when inheriting from both OSError and AttributeError
https://bugs.python.org/issue45464  opened by marmarek

#45466: Simple curl/wget-like download functionality in urllib (like h
https://bugs.python.org/issue45466  opened by tom.pohl

#45468: Add support for preloading a Python script
https://bugs.python.org/issue45468  opened by Gabriele Tornetta

#45472: Add public C API for partial "unicode-escape" and "raw-unicode
https://bugs.python.org/issue45472  opened by serhiy.storchaka

#45473: Enum: add "name" and "value" keywords to call syntax
https://bugs.python.org/issue45473  opened by aekoch

#45475: gzip fails to read a gzipped file (ValueError: readline of clo
https://bugs.python.org/issue45475  opened by minstrelofc

#45476: [C API] Disallow using PyFloat_AS_DOUBLE() as l-value
https://bugs.python.org/issue45476  opened by vstinner

#45477: configure script cannot detect float word ordering on linux
https://bugs.python.org/issue45477  opened by sourish.basu

#45

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

[Pradeep Kumar Srinivasan]

Thanks for the responses, everyone. Overall, it seems like there were no strong 
objections to the proposal.

I didn't hear much about Question 2, though: Should we propose features beyond 
present-day `Callable` in the same PEP or defer it to a future PEP?

In case that question got lost in the other details, feel free to respond here. 
If not, I'll take it there aren't strong opinions either way.



Some of my other takeaways:

+ Address the implications of the syntax changes for Python.
+ Address edge cases like trailing commas, `Concatenate` for `ParamSpec`, and 
runtime value of the expression.
+ Explicitly discuss the function-name-as-a-type proposal.

We will be drafting the PEP over the coming month.
___
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/ZL3KPQCB7IBW2YFAUAGNQAV3EXGPBDTO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Fri, Oct 15, 2021 at 12:22 PM Pradeep Kumar Srinivasan <
gohan...@gmail.com> wrote:

> Thanks for the responses, everyone. Overall, it seems like there were no
> strong objections to the proposal.
>
> I didn't hear much about Question 2, though: Should we propose features
> beyond present-day `Callable` in the same PEP or defer it to a future PEP?
>
> In case that question got lost in the other details, feel free to respond
> here. If not, I'll take it there aren't strong opinions either way.
>

Sorry I didn't make it to the meeting. You know my opinion. :-)


> Some of my other takeaways:
>
> + Address the implications of the syntax changes for Python.
>

In particular, when the syntax is used in a non-annotation position, it
must evaluate to some object that represents the information present in the
syntax (like Callable does ATM).

+ Address edge cases like trailing commas, `Concatenate` for `ParamSpec`,
> and runtime value of the expression.
> + Explicitly discuss the function-name-as-a-type proposal.
>
> We will be drafting the PEP over the coming month.
>

Awesome. You have my blessing.

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