On Tue, Feb 8, 2022 at 9:49 AM Serhiy Storchaka wrote:
>
> 07.02.22 17:55, Victor Stinner пише:
> > I'm asking to replace runtime checks with assertions when the C API is
> > "obviously" misused: replace PyErr_BadInternalCall(),
> > _Py_CheckFunction
On Tue, Feb 8, 2022 at 12:19 AM Brett Cannon wrote:
> Do we have a buildbot that has a CPU or OS that can't handle IEEE-754? What
> are the chances we will get one? If the answers are "none" and "slim", then
> it seems reasonable to require NaN and IEEE-754.
All CPU architectures of current bui
Hi Mark,
Aha, good, you posted an email to python-dev, good :-) Last days, I
was trying to collect more data about this topic, especially find
platforms which *don't* support IEEE 754, before posting to
python-dev.
Nowadays, outside museums, it's hard to find computers which don't
implement IEEE
Hi,
I made a change to require C99 "NAN" constant and I'm was
asked to update the PEP 7 to clarify the C subset is needed to build
Python 3.11.
Python 3.6 requires a subset of the C99 standard to build defined by the PEP 7:
https://www.python.org/dev/peps/pep-0007/
I modified Python 3.11 to req
On Mon, Feb 7, 2022 at 5:48 PM Guido van Rossum wrote:
> So you're proposing to completely get rid of those three?
I don't propose to remove them, but only call them if Python is built
in debug mode. Or remove them from the release build, unless
./configure --with-assertions is used.
> And you'
On Mon, Feb 7, 2022 at 5:38 PM Guido van Rossum wrote:
> ISTM this is better discussed on a case-by-case basis than as a blanket
> policy change. (The latter could end up causing a flood of trivial PRs from
> wannabe-contributors who found and fix yet another violation of the policy,
> which is
Hi,
I would like to replace runtime checks on C function arguments with
assertions. For example, replace:
PyObject *
PyDict_GetItemWithError(PyObject *op, PyObject *key)
{
if (!PyDict_Check(op)) {
PyErr_BadInternalCall();
return NULL;
}
...
}
with:
PyObject *
PyDict_
On Mon, Jan 31, 2022 at 3:57 PM Petr Viktorin wrote:
> Remove the point from the Abstract?
> (...)
> I think you should make it clear that the percentage was taken after
> fixing many of the projects.
Thanks for your review.
I pushed a change to take your remarks in account:
https://github.com/p
On Mon, Feb 7, 2022 at 2:26 PM Victor Stinner wrote:
> CPython is also affected by these issues, but the benefits of PEP 674
> (alone) are too indirect, so I chose to avoid mentioning CPython
> issues directly, to avoid confusion.
A concrete example of problem caused by exposing stru
On Mon, Feb 7, 2022 at 2:08 PM Petr Viktorin wrote:
> Basically, instead of "We'll remove this API now because it prevents
> moving to a hypothetical moving garbage collector", it should be "Here
> is a moving garbage collector that speeds Python up by 30%, but to add
> it we need to remove these
On Sun, Feb 6, 2022 at 3:35 PM Paul Moore wrote:
> urllib.request may not be "best practice", but it's still extremely
> useful for simple situations, and urllib.parse is useful for basic
> handling of URLs.Yes, the more complex aspects of urllib are better
> handled by external packages, but that
On Sun, Feb 6, 2022 at 3:48 PM Damian Shaw wrote:
>
> Pip vendors requests for network calls:
> https://github.com/pypa/pip/tree/main/src/pip/_vendor/requests
>
> But still does depend on functions from urllib.parse and urllib.request in
> many places:
> https://github.com/pypa/pip/blob/main/sr
On Sun, Feb 6, 2022 at 3:33 PM Ezekiel Adetoro wrote:
> Hello,
> My name is Ezekiel, and it is my desire to start contributing to Python, be
> part of the core development of Python. I have forked the CPython and cloned
> it. What is the next step I need to do?
Welcome Ezekiel! I suggest you to
Hi,
I propose to deprecate the urllib module in Python 3.11. It would emit
a DeprecationWarning which warn users, so users should consider better
alternatives like urllib3 or httpx: well known modules, better
maintained, more secure, support HTTP/2 (httpx), etc.
I don't propose to schedule its re
On Fri, Feb 4, 2022 at 12:52 AM Eric V. Smith wrote:
>
> On 2/3/2022 12:15 PM, Victor Stinner wrote:
> >
> > IMO if PyObject* becomes a handle, the migration to the HPy API should
> > be much easier.
>
> It seems to me that moving PyObject* to be a handle leaves yo
On Thu, Feb 3, 2022 at 11:49 PM Eric Snow wrote:
> I suppose I'd like to know what the value of _Py_IDENTIFIER() is for
> 3rd party modules.
_Py_IDENTIFIER() API is simple and short, Python creates the Python
string object automatically, *and* clears this object at exit. It's
convenient.
On the
bject* obj, PyObject*
attr_name) {
Oh, that's not "_PyObject_LookupSpecial()", it doesn't use the
_Py_Identifier type:
static CYTHON_INLINE PyObject*
__Pyx_PyObject_LookupSpecial(PyObject* obj, PyObject* attr_name)
{ ... }
Victor
On Thu, Feb 3, 2022 at 7:27 PM wrote:
>
> Vi
Hi Guido,
My "north star", as you say, is the HPy "design" (not the actual HPy
API). I would like to convert PyObject* to opaque handles:
dereferencing a PyObject* pointer would simply fail with a compiler
error.
I'm working bottom-to-top: prepare PyObject and PyVarObject to become
opaque, *and*
By the way, Argument Clinic now produces way faster calling
conventions than hand-written METH_VARARGS with PyArg_ParseTuple(). It
would be make this tool available to 3rd party projects.
Either extract it and put it on PyPI, but it means that Python will
need to Python and pip install something t
On Wed, Feb 2, 2022 at 11:43 PM Eric Snow wrote:
> My plan is to replace our use of _Py_IDENTIFIER() with statically
> initialized string objects (as fields under _PyRuntimeState). That
> involves the following:
>
> * add a PyUnicodeObject field (not a pointer) to _PyRuntimeState for
> each strin
On Wed, Feb 2, 2022 at 11:49 PM Eric Snow wrote:
> FTR, here is the (private/internal) C-API affected by getting rid of
> _Py_IDENTIFIER():
>
> * 21 C-API functions with `_Py_Identifer` parameters - would be dropped
>+ _PyUnicode_FromId()
>+ _PyUnicode_EqualToASCIIId()
>+ _PyObject_Cal
On Wed, Feb 2, 2022 at 3:54 PM Stefan Behnel wrote:
> > So people using stable Python versions like Python 3.10 would not need
> > Cython, but people testing the "next Python" (Python 3.11) would not
> > have to manually removed generated C code.
>
> That sounds like an environment variable might
On Wed, Feb 2, 2022 at 9:25 AM wrote:
> Guido van Rossum wrote:
> > My question for you is if you're willing to write up a list of things in
> > CPython that you depend on. Or is this just something you're not willing to
> > commit to? It would be nice to know which it is, just so the CPython team
I wish that there would be a 3rd option: ship C code generated by
Cython *but* run Cython if this C code "looks" outdated, for example
if building the C code fails with a compiler error.
So people using stable Python versions like Python 3.10 would not need
Cython, but people testing the "next Pyt
On Tue, Feb 1, 2022 at 5:37 PM Irit Katriel wrote:
> _PyErr_StackItem is not part of the C API, it's an internal struct that
> cython accesses directly.
numpy currently fails on building Cython
__Pyx_PyErr_GetTopmostException() function which access
tstate->exc_info->exc_type, so it's about the
On Tue, Feb 1, 2022 at 4:42 PM Christian Heimes wrote:
> I would prefer if we can get Cython and all the other code generator and
> bindings library off the unstable C-API. They should use the limited API
> instead. If they require any C-APIs outside the limited API, then we
> should investigate a
Hi,
It became more and more common that a C API incompatible change
introduced in Python breaks Cython and all Python projects using
Cython (ex: numpy). Hopefully, usually only some projects using Cython
are broken, not all of them.
Some of you may remind the PEP 590 (vectorcall) implementation w
On Mon, Jan 31, 2022 at 4:03 PM Petr Viktorin wrote:
> > If we change the stable ABI, I would prefer to fix multiple issues at
> > once. Examples:
> >
> > * No longer return borrowed references (ex: PyDict_GetItem is part of
> > the stable ABI) and no longer steal references (ex:
> > PyModule_AddO
On Mon, Jan 31, 2022 at 1:48 PM Petr Viktorin wrote:
> (* we could also break the stable ABI, and we could even do it
> reasonably safely over a long period of time, but that's a whole
> different discussion.)
IMO the stable ABI must be change in the long term, it still leaks too
many implementat
On Mon, Jan 31, 2022 at 2:31 PM Petr Viktorin wrote:
> > PEP: 674
> > Title: Disallow using macros as l-value
>
> The current PEP is named "Disallow using Py_TYPE() and Py_SIZE() macros
> as l-values", which is misleading: it proposes to change 65 macros.
Right, I made changes since I posted the
On Fri, Jan 28, 2022 at 6:28 PM Guido van Rossum wrote:
> I think we will get *one* chance in the next decade to get it right. Whether
> that's HPy or evolution of the C API I'm not sure.
Would you mind to elaborate? Which risk do you expect from switching
to HPy and from fixing the C API (intro
Wait, where is the HPy project in that plan? :-) The HPy project
(brand new C API) is a good solution for the long term!
My concerns about HPy right now is that, in short, CPython has to
continue supporting the C API for a few more years, and we cannot
evolve CPython before it will become reasonab
Hi,
There is a reason why I'm bothering C extensions maintainers and
Python core developers with my incompatible C API changes since Python
3.8. Let me share my plan with you :-)
In 2009 (Python 3.2), Martin v. Löwis did an amazing job with the PEP
384 "Defining a Stable ABI" to provide a "limit
ode, _overlapped,
_curses_panel, termios, _sha256, scproxy, cmath, _lsprof, unicodedata)
* Nick Coghlan (PEP 489, PEP 573)
* Paulo Henrique Silva (modules: time, operator, _functools)
* Petr Viktorin (PEP 489, PEP 573, PEP 630)
* Stefan Behnel (PEP 489)
* Victor Stinner (modules _string, mashal,_imp, _warni
On Thu, Jan 27, 2022 at 1:14 AM Larry Hastings wrote:
> Just so I understand: is this effectively permanent? My first thought was,
> we get SWIG to change its code generation, and in a couple of years we can
> follow up and make this change. But perhaps there's so much SWIG code out
> there a
Hi,
My PEP 674 proposed to change PyDescr_TYPE() and PyDescr_NAME()
macros. This change breaks M2Crypto and mecab-python3 projects in code
generated by SWIG. I tried two solutions to prevent SWIG accessing
PyDescrObject members directly:
https://bugs.python.org/issue46538
At the end, IMO it's too
On Wed, Jan 19, 2022 at 11:58 AM Sebastian Rittau wrote:
>
> Am 18.01.22 um 22:57 schrieb Victor Stinner:
> > At the end of my first email, I also suggest thinking about
> > incompatible changes differently, try to make affected projects
> > compatible in advance. The pro
On Tue, Jan 18, 2022 at 5:48 PM Steve Dower wrote:
> Discovering during alpha that some packages haven't updated for the
> release that hasn't happened yet isn't the end of the world. Reverting
> the changes now is probably a bit premature - realistically we can undo
> these anytime during beta if
ttributeError: module 'configparser' has no attribute
'SafeConfigParser'.
Victor Stinner -- in the name of the Python Red Hat / Fedora maintenance team
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-D
How does someone know if a database is corrupted? Why is a separated
script needed?
A single script cannot automatically detect a corrupted database and
load the latest snapshot?
How is different from simply copying the whole database file?
Victor
--
Night gathers, and now my watch begins. It s
Hi Dong-hee,
Can you please show me a short full example opening a database with
automatic snapshop recovery (with your proposed API)?
Do you ask us our opinion on the Python API that you propose? Or if
the whole feature is worth it?
Victor
On Tue, Jan 18, 2022 at 2:41 AM Dong-hee Na wrote:
>
ine:
https://python.github.io/peps/ep-0674/
And you can find the plain text below.
Victor
PEP: 674
Title: Disallow using macros as l-value
Author: Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30-Nov-2021
Python-Version: 3.11
Abstract
Incompat
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 pa
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 lo
On Mon, Jan 10, 2022 at 4:04 PM Guido van Rossum wrote:
> Note that Pablo explicitly requested all feedback to Discourse.
Oooops sorry, I missed that part of his email!
Victor
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an
Does someone know if linters like pylint or pylakes current warn on
"assert(test, msg)" statements?
If a project use such assertions which are always true, they can start
failing wit the PEP 679, right? Hopefully, the fix is easy: removing
the parenthesis give the same behavior on old and new Pyth
On Thu, Jan 6, 2022 at 12:33 PM Pablo Galindo Salgado
wrote:
> * https://bugs.python.org/issue46006
>
> Victor made a revert of his PR but unfortunately, we cannot easily backport
> it to 3.10 as it affects the ABI. It affects the interpreter state structure
> that although is not on the stable
On Thu, Dec 16, 2021 at 12:00 AM Guido van Rossum wrote:
> Sam's approach is to use the lower bit of the ob_refcnt field to indicate
> immortal objects. This would not work given the stable ABI (which has macros
> that directly increment and decrement the ob_refcnt field). (...) we can test
> f
On Thu, Dec 16, 2021 at 2:29 AM Nathaniel Smith wrote:
> On Wed, Dec 15, 2021 at 3:07 AM Victor Stinner wrote:
> > I wrote https://bugs.python.org/issue39511 and
> > https://github.com/python/cpython/pull/18301 to have per-interpreter
> > None, True and False singletons.
Hi,
One option to solve the https://bugs.python.org/issue40601 "[C API]
Hide static types from the limited C API" issue without breaking the
backward compatibility is to leave the C API and the stable ABI as
they are for the main interpreter (static types), but force
subinterpreters running in par
Hi,
On Tue, Dec 14, 2021 at 6:13 PM Eric Snow wrote:
> I'm still hoping to land a per-interpreter GIL for 3.11. There is
> still a decent amount of work to be done but little of it will require
> solving any big problems:
>
> * pull remaining static globals into _PyRuntimeState and PyInterpreter
On Tue, Dec 14, 2021 at 7:27 PM Eric Snow wrote:
> We have some options:
>
> * live with the full penalty
> * make other changes to reduce the penalty to a more acceptable
> threshold than 5%
> * eliminate the penalty (e.g. claw back 5% elsewhere)
The last time I saw a benchmark on immortal objec
Hi Brett,
IMO the PEP 630 is a good summary and a practical guide explaining how
to port existing C extensions to newer C API which are compatible with
subinterpreters, unloading a C extension and be able to load a C
extension more than once (in the same interpreter):
https://www.python.org/dev/pe
Yeah, another Python 3.11 alpha release!
The asyncore, asynchat and smtpd modules are back into Python 3.11!
They were removed but the removal has been reverted to respect the PEP
387 process: have two Python versions (3.10 and 3.11) emitting a
DeprecationWarning.
In general, I strongly advice yo
Are you talking about gcc -Wignored-qualifiers? It seems like such
warning is only emitted where the function is *defined*, not where the
function is *called*. Example:
---
const int f(void) { return 1; }
int main() { return f(); }
---
Output:
---
$ gcc -Wextra y.c -o y
y.c:1:1: warning: type qual
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.
HPy can already be used today on CPython, even if
ge.
>
>
>
> On Tue, 7 Dec 2021 at 12:40, Antoine Pitrou wrote:
>>
>> On Tue, 7 Dec 2021 15:39:25 +0100
>> Petr Viktorin wrote:
>>
>> > On 30. 11. 21 19:52, Victor Stinner wrote:
>> > > On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum
>&
ue, Dec 7, 2021 at 4:41 PM Antoine Pitrou wrote:
>
> On Tue, 7 Dec 2021 15:39:25 +0100
> Petr Viktorin wrote:
>
> > On 30. 11. 21 19:52, Victor Stinner wrote:
> > > On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum wrote:
> > >> How about *not*
On Tue, Dec 7, 2021 at 3:43 PM Petr Viktorin wrote:
> If we would deprecate using Py_REFCNT as l-value in the docs, but wait
> with the conversion until it was *actually* needed, we would not lose
> anything:
> (...)
> ## CPython nogil fork
>
> In CPython, we cannot change structs that are part of
Interesting! Some remarks about the proposed API.
On Tue, Dec 7, 2021 at 4:58 PM Mark Shannon wrote:
> There is no change to the language and it adds 7 functions to the sys module,
> so shouldn't be too intrusive for those of who aren't planning on
> implementing any of those tools.
Where are
On Mon, Dec 6, 2021 at 9:54 PM Guido van Rossum wrote:
> Also, it looks like Mark is proposing to *remove* _PyObject_GC_Malloc from
> stable_abi.txt
In Python 3.2, _PyObject_GC_Malloc() is implemented as a function.
PyObject_GC_New() macro calls _PyObject_GC_New() function. Internally,
PyType_Ge
Hi,
The "master" branch of the following Python GitHub repositories have
been renamed to "main":
* devguide
* peps
* voters
For the rationale of the rename, see:
https://sfconservancy.org/news/2020/jun/23/gitbranchname/
If you already have a Git checkout of one of these repositories, you
can re
Hi Steve,
I completely agree with all you said ;-)
I will not debate here if incompatible changes are worth it or not,
this topic was discussed recently in another thread.
On Fri, Dec 3, 2021 at 2:56 PM Steve Dower wrote:
> FTR, I don't consider the top projects on PyPI to be representative of
likely
that old versions are also affected.
Victor
On Fri, Dec 3, 2021 at 8:35 AM Michał Górny wrote:
>
> On Fri, 2021-12-03 at 00:44 +0100, Victor Stinner wrote:
> > I wrote two scripts based on the work of INADA-san's work to (1)
> > download the source code of the PyPI top 5000
Hi,
I wrote two scripts based on the work of INADA-san's work to (1)
download the source code of the PyPI top 5000 projects (2) search for
a regex in these projects (compressed source archives).
You can use these tools if you work on an incompatible Python or C API
change to estimate how many pro
Hi Ezio,
What is the status of migrating Python issues to GitHub? Is it done?
If not, what are remaining issues?
Victor
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.
On Tue, Nov 30, 2021 at 7:52 PM Victor Stinner wrote:
> For this specific PEP changes, I consider that the number of impacted
> projects is low enough to skip a deprecation process: only 4 projects
> are known to be impacted. One year ago (Python 3.10), 16 were
> impacted, and 12
On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum wrote:
> How about *not* asking for an exception and just following the PEP 387
> process? Is that really too burdensome?
The Backward Compatibility section gives an explanation:
"This change does not follow the PEP 387 deprecation process. There
for
older Python versions. I already prepared major projects like Cython
and numpy for these changes (in total, 14 impacted projects have
already been updated).
Victor
---
PEP: 674
Title: Disallow using macros as l-value
Author: Victor Stinner
Status: Draft
Type: Standards Track
Content-Type:
If someone wants to experiment such optimization, there is no need to
modify the Python internal optimizer, it can be done externally:
https://faster-cpython.readthedocs.io/ast_optimizer.html
For example, I implemented many optimizations like constant
propagation and loop unrolling in my old AST f
optimized neither.
Oh. I made the assumptions that other operations were already
optimized.
Victor
On Mon, Nov 29, 2021 at 6:11 PM Serhiy Storchaka wrote:
>
> 29.11.21 18:36, Victor Stinner пише:
> > You should consider "no longer have to justify why it's not optimize
You should consider "no longer have to justify why it's not optimized"
as a clear benefit of making this change :-) This optimization is
proposed once a year for many years...
For me, any possible compilation-ahead optimization (which doesn't
break the Python semantics) is worth it ;-) It's done o
24, 2021 at 12:27 AM Guido van Rossum wrote:
>
> On Tue, Nov 23, 2021 at 3:15 PM Antoine Pitrou wrote:
>>
>> On Tue, 23 Nov 2021 18:00:28 +0100
>> Victor Stinner wrote:
>>
>> > I didn't run benchmarks on Python built in release mode, since gcc -O3
>&g
On Wed, Nov 24, 2021 at 2:18 PM Petr Viktorin wrote:
> >> The "Backwards Compatibility" section is very small. Can you give a list
> >> of macros which lost/will lose "return values"?
> >
> > https://bugs.python.org/issue45476 lists many of them. See also:
> > https://github.com/python/cpython/pul
On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin wrote:
> Since this is about converting existing macros (and not writing new
> ones), can you talk about which of the "macro pitfalls" apply to the
> macros in CPython that were/will be changed?
The PEP 670 lists many pitfalls affecting existing macr
On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin wrote:
> Are there more macros that are yet to be converted to macros,
I suppose that you mean "to be converted to functions". Yes, there are
many, it's the purpose of the PEP.
I didn't provide a list. I would prefer to do it on a case by case
basis
Hi Antoine,
I completed the PEP: https://python.github.io/peps/pep-0670/
* Add benchmarks on a Python debug build: (1) macros vs static inline
functions and (2) gcc -O0 vs gcc -Og
* Elaborate the Debug Build section
* Explain why the "keep macros" idea was rejected
Diff:
https://github.com/pyth
Maybe once a function is deprecated in Python, pyupgrade should be
updated? I mean, more collaboration between Python core devs and the
pyupgrade development.
https://github.com/asottile/pyupgrade
Victor
On Thu, Nov 18, 2021 at 8:39 AM Jeremiah Paige wrote:
>
> I’ve seen a few people in this th
I created https://github.com/python/steering-council/issues/86 to ask
for a SC exception.
Victor
On Tue, Nov 16, 2021 at 8:11 PM Brett Cannon wrote:
>
>
>
> On Tue, Nov 16, 2021 at 3:05 AM Petr Viktorin wrote:
>>
>> On 12. 11. 21 13:09, Victor Stinner wrote:
>&g
On Tue, Nov 16, 2021 at 1:15 AM Brett Cannon wrote:
> But have they been raising exceptions for two releases?
As I wrote previously, the DeprecationWarning warning is only emitted
at runtime since Python 3.10.
Since my PR got 5 approvals, I just merged it:
https://github.com/python/cpython/pull/
On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith wrote:
> On second thought, I guess the existing policy already does this. Maybe
> we should make it more than 2 versions for deprecations? I've written
> libraries where I support 4 or 5 released versions. Although maybe I
> should just trim that back
I guess that you should agree on constants and then stick to them.
Otherwise, we might have to add a parameter later to chose the
conversion standard.
The PR uses "ATSC BT.709 standard constant".
Wikipedia says:
"When encoding Y’CBCR video, BT.709 creates gamma-encoded luma (Y’)
using matrix coef
For me, deprecated functions cause me a lot of thinking when I met
them as a Python maintainer and as a Python user. Why is it still
there? What is its purpose? Is there a better alternative? It's
related to the Chesterton's fence principle. Sometimes, reading the
doc is enough. Sometimes, I have t
> The current backwards compatibility policy (PEP 387) sets a *minimum*
> timeline for deprecations and removals -- "deprecation period must last
> at least two years."
About the PEP 387 process and the 3 examples.
On Fri, Nov 12, 2021 at 11:58 AM Petr Viktorin wrote:
>AttributeError: module
> > It was decided to start deprecating the asyncore, asynchat and smtpd
> > modules in Python 3.6 released in 2016, 5 years ago. Python 3.10 emits
> > DeprecationWarning.
>
> Wait, only Python 3.10?
> According to the policy, the warning should be there for *at least* two
> releases. (That's a min
Hi,
The asyncore module is a very old module of the Python stdlib for
asynchronous programming, usually to handle network sockets
concurrently. It's a common event loop, but its design has many flaws.
The asyncio module was added to Python 3.4 with a well designed
architecture. Twisted developers
IMO if someone is motivated to get a new container type in Python, a
PEP is required.
A PEP has been written for the new removeprefix() and removesuffix()
methods which are way simpler ;-)
I expect many questions on corner cases for a sorted container type.
Having a reference implementation, eve
IMO it was a bad idea to merge 2 ncurses C functions into a single
Python function. In the C API, there are two different functions:
* mvwadd_wch(win, y, x, char): 4 arguments
* wadd_wch(win, char): 2 arguments
The Python curses module could/can have a separated function when (y,
x) arguments are
On Mon, Nov 8, 2021 at 8:21 PM Ethan Furman wrote:
> The difference with the built-in ascii is the absence of extra quotes and the
> `b` indicator when a string is used:
>
> ```
> >>> u_var = u'abc'
> >>> bytes.ascii(u_var)
> b'abc'
What about bytes, bytearray and memoryview? What is the expec
What's New in Python 3.10 lists other suggestions and enhanced error messages:
https://docs.python.org/dev/whatsnew/3.10.html#better-error-messages
Victor
On Fri, Oct 29, 2021 at 7:22 PM Steven D'Aprano wrote:
>
> I was using Python 3.10 and got this NameError when I mistyped a name:
>
> NameErr
The ascii() constructor is not well specified by the PEP. There are
only a few examples. I don't understand how it's supposed by be
implemented. Would you mind to elaborate its specification?
Is it implement "like" ascii(obj).encode("ascii") but with minor
changes? What changes?
Victor
__
On Wed, Oct 20, 2021 at 10:58 AM Petr Viktorin wrote:
> I think this info should be in the PEP.
Ok, we added (and completed) the list to the PEP:
https://www.python.org/dev/peps/pep-0670/#macros-converted-to-functions-since-python-3-8
> If the PEP is rejected, would all these previous changes ne
One of my motivation to write this PEP was decide how to solve the
issue: "[C API] Disallow using PyFloat_AS_DOUBLE() as l-value"
https://bugs.python.org/issue45476
I proposed two fixes:
* Convert macros to static inline functions:
https://github.com/python/cpython/pull/28961
* Fix the macro, add
Extra info that I didn't put in the PEP to keep the PEP short.
Since Python 3.8, multiple macros have already been converted,
including Py_INCREF() and Py_TYPE() which are very commonly used and
so matter for Python performance.
Macros converted to static inline functions:
* Py_INCREF(), Py_DECR
Python C API
Author: Erlend Egeberg Aasland ,
Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 19-Oct-2021
Python-Version: 3.11
Abstract
Convert macros to static inline functions or regular functions.
Remove the return value of macros having a
Hi Antoine,
I have a lot of troubles to reminder how Python converts numbers, I
collected notes about the Python "number tower" and the C
implementation:
https://pythondev.readthedocs.io/numbers.html
Honestly, I don't understand well the difference between __int__() and
__index__().
* https://do
Hi,
I'm digging into the Python bug tracker history and I found links to
Subversion commits:
"Fixed in r77062 (trunk), r77063 (py3k)."
https://bugs.python.org/issue1811#msg96910
Roundup adds links which are redirected:
* https://hg.python.org/lookup/r77062 ->
https://svn.python.org/view?view=rev
To stay consistent with PEP 8, exception groups should use 4 spaces.
Victor
On Sun, Oct 3, 2021 at 5:54 PM Irit Katriel via Python-Dev
wrote:
>
>
> We wonder if people have a view on which of the following is clearer/better:
>
> 1. except *E as e: // except *(E1, E2) as e:
> 2. except* E as e:
Hi Jeff,
The decimal module docstring starts with:
"""
This is an implementation of decimal floating point arithmetic based on
the General Decimal Arithmetic Specification:
http://speleotrove.com/decimal/decarith.html
and IEEE standard 854-1987:
http://en.wikipedia.org/wiki/IEEE_854-19
+
::
PEP: xxx
Title: Taking the Python C API to the Next Level
Author: Victor Stinner
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 28-Sep-2021
Python-Version: 3.11
While the C API is a key of the Python
101 - 200 of 3215 matches
Mail list logo
