While it's different than you proposal, some people may like this
magic "smart imports" project which lazily imports a module when it's
used :-)
Project: https://pypi.org/project/smart-imports/
Replace:
---
import math
from my_project import calc
# 100500 other imports
def my_code(argument, fun
PEP 670 – Convert macros to functions in the Python C API:
https://peps.python.org/pep-0670/
That's great! Thanks to everyone who was involved in PEP 670: the
feedback helped Erlend and me to write a better PEP. It was a long
journey, Erlend started the first discussion about macros in March
2021!
Hi,
In 2017, I proposed to document the feature, but nobody was volunteer
to write the doc (issue still open):
https://bugs.python.org/issue25571
I added a bare minimum mention of this feature in the "Python Debug
Build" documentation:
https://docs.python.org/dev/using/configure.html#python-debug
6 months ago, I wrote a different document based on HPy Manifesto:
"PEP: Taking the Python C API to the Next Level"
https://mail.python.org/archives/list/python-dev@python.org/message/RA7Q4JAUEITJBOUAXFEJKRRM2RR3QSZI/
Victor
On Mon, Apr 4, 2022 at 5:20 PM Petr Viktorin wrote:
>
> On 03. 02. 22
On Wed, Apr 20, 2022 at 10:03 AM Antoine Pitrou wrote:
> If the HPy design is the long term goal, why not just recommend that
> people use HPy? And keep the C API for expert users with specific
> needs that are not accomodated by HPy.
>
> To me, it seems that trying to change the C API to be "lik
On Wed, Apr 20, 2022 at 1:44 PM Antoine Pitrou wrote:
> > For consumers of the C API (C extensions, Cython, pybind11, etc.),
> > once most implementation details will be hidden, the C API will become
> > way more stable.
>
> The *API* is quite stable already if you don't use the private/internal
>
On Fri, Apr 22, 2022 at 2:52 PM Fabio Zadrozny wrote:
> Humm, now I'm a bit worried... the approach the debugger is using gets the
> PyFrameObject that's about to be executed and changes the
> PyFrameObject.f_code just before the execution so that the new code is
> executed instead.
You can al
On Tue, Apr 26, 2022 at 5:47 AM Brett Cannon wrote:
> After talking about this in the SC today, we agreed to deprecate mailcap
> under the auspices of PEP 594:
> https://github.com/python/peps/commit/701999a91dc5f976c00d5bde1510226ebd9c7822
> .
Good. I proposed https://github.com/python/cpytho
Hi,
There are 4 main ways to run Python:
(1) python -m module [...]
(2) python script.py [...]
(3) python -c code [...]
(4) python [...]
(1) and (2) insert the directory of the module/script at sys.path[0].
(3) and (4) insert an empty string at sys.path[0].
This behavior is convenient and is ma
The only purpose of proposed -P option is to "not add sys.path[0]".
There are use cases which only need that.
Victor
On Tue, Apr 26, 2022 at 8:37 PM Steve Dower wrote:
>
> On 4/26/2022 10:46 AM, Victor Stinner wrote:
> > I propose adding a -P option to Python command
On Tue, Apr 26, 2022 at 8:37 PM Steve Dower wrote:
> The biggest issue I see is that the obvious command line options for
> "import site" are already used to imply "do not import site". But then,
> -P isn't obvious either. Maybe an -X option would suffice?
I propose the short option "-P" rather t
On Tue, Apr 26, 2022 at 11:46 AM Victor Stinner wrote:
> I propose adding a -P option to Python command line interface to "not
> add sys.path[0]":
> https://github.com/python/cpython/pull/31542
My plan is to merge this change at 2022-05-05, the day before the
Python 3.11 fea
Oh sorry, I mean that I prefer to *not* add an environment variable,
but I'm not strongly against it.
How would the environment varaible be used? A command line option is not enough?
Victor
On Wed, Apr 27, 2022 at 4:44 PM Antoine Pitrou wrote:
>
> On Tue, 26 Apr 2022 11:46:41 +02
Since I didn't get any serious review on my pull request since
February, I created this thread on python-dev to get more people
looking into this issue.
On Wed, Apr 27, 2022 at 5:30 PM Paul Moore wrote:
>
> On Wed, 27 Apr 2022 at 15:32, Victor Stinner wrote:
> >
> > On
s like use cases are different enough to justify two
options, no?
Victor
On Tue, Apr 26, 2022 at 11:52 PM Victor Stinner wrote:
> The only purpose of proposed -P option is to "not add sys.path[0]".
> There are use cases which only need that.
>
> Victor
>
> On Tue, Apr
On Wed, Apr 27, 2022 at 5:56 PM Antoine Pitrou wrote:
> An environment variable is an easy to influence a program or system
> whose inner workings you don't control (for example a system that
> spawns child Python processes). And it sounds like a good idea to allow
> that given that it improves se
Hi,
If you got issues with using the Python C API in C++,
please speak up! I'm looking for feedback :-)
Extending Python by writing C++ code is now easy with the pybind11 project:
https://pybind11.readthedocs.io/
It seems like over the last years, building C++ extensions with the
Python C API s
Since we are you talking about tests, we can easily run the tests on
multiple C++ versions. But we have to start somewhere, so I propose to
start with C++11. More C++ versions can be tested later.
Victor
On Thu, Apr 28, 2022 at 5:54 AM wrote:
>
> > In terms of C++ version, it was proposed to tar
Recently, a issue about C++20 compatibility was reported:
"The Python library will not compile with a C++2020 compiler because
the code uses the reserved “module” keyword"
https://github.com/python/cpython/issues/83536
In fact, after a long study, Python C API is *not* affected by this
issue. Usi
Hi,
The C++ version was discussed in the 2nd link that I gave in my first message:
https://github.com/python/cpython/issues/91321
Gregory wrote "If we can conditionally test new things based on C++XX
version, accumulating modern issue regression tests seems useful.
Otherwise 11 at minimum."
Anot
Ok, let me start with the serious business: API name.
I'm not comfortable with "semi-stable". Python already has a "limited
API" and a "stable ABI". Just by its name, it's unclear what
"semi-stable" means.
Honestly, I would be more comfortable with the name: "unstable API".
It would be clear that
> Rejected Ideas
> ==
>
> It might be good to add a similar tier in the Python (not C) API,
> e.g. for ``types.CodeType``.
> However, the opt-in mechanism would need to be different (if any).
> This is outside the scope of the PEP.
For types.CodeType constructor, would it be possible t
I think that the main advantage of "unstable" over "semi-stable" is
that it's a single word :-D It avoids the really hard question (!)
about the separator between "semi" and "stable" ;-) (semistable?
semi-stable? semi_stable?).
Victor
___
Python-Dev mail
On Fri, Apr 29, 2022 at 8:12 PM Python tracker
wrote:
> ACTIVITY SUMMARY (2022-04-22 - 2022-04-29)
> 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:
> open
Hi,
I merged the best basic tests to make sure that using the Python C API in
C++ does not emit compiler warnings:
* Code: https://github.com/python/cpython/blob/main/Lib/test/_testcppext.cpp
* Test: https://github.com/python/cpython/blob/main/Lib/test/test_cppext.py
The code is only built to ch
;t modify the memory. But maybe tomorrow, the implementation
will deeply change and will need to modify the memory. In C, using "const"
(for something other than const char*) is just not convenient.
Victor
On Tue, May 3, 2022 at 9:22 AM Antoine Pitrou wrote:
> On Mon, 2 May 2022 15:2
Hi,
I updated my PR https://github.com/python/cpython/pull/31542 and I
plan to merge it soon.
It seems like most people need and like this feature.
About the feature name, nobody liked the "add_path0" name which is
misleading: "path0" is not easy to get, and the path is prepended, not
added.
I
Every day, I unsubscribe from many issues and pull requests to reduce
the number of emails to move it below my acceptable threshold. For
example, for me, 20 new discussions per day is acceptable, whereas 100
is not.
I prefer to focus on small number of things and follow them closely.
Victor
_
file importing the site module,
> maybe a different option can be added, no? Adding -P doesn't prevent
> that. But it seems like use cases are different enough to justify two
> options, no?
>
> Victor
>
>
> On Tue, Apr 26, 2022 at 11:52 PM Victor Stinner wrote:
> >
On Fri, May 6, 2022 at 2:14 PM Pablo Galindo Salgado
wrote:
> Today we need to start the release of Python 3.11 beta 1. Currently, we have
> the following blockers:
>
> * https://github.com/python/cpython/issues/91162 (was deferred blocker - but
> all deferred blockers are bumped to release bloc
Hi,
I added the -P command line option and the PYTHONSAFEPATH=1
environment variable to Python 3.11 beta 1 to not prepend an "unsafe
path" to sys.path such as the script's directory or the current
directory:
https://docs.python.org/dev/using/cmdline.html#cmdoption-P
Example:
--
$ echo 'N
Hi,
Two years ago, PEP 632 "Deprecate distutils module" was accepted: the
distutils package was deprecated in Python 3.10 and scheduled for
removal in Python 3.12. Questions.
* Is the Python ecosystem ready for the distutils removal? How many
projects are expected to be broken by this removal?
*
On Tue, May 10, 2022 at 11:28 AM Christian Heimes wrote:
> > Right now, Python still uses distutils internally for multiple use
> > cases. I propose to start with renaming the distutils package to
> > _distutils in the stdlib:
> >
> > * https://github.com/python/cpython/issues/92584
> > * https://
On Tue, May 10, 2022 at 5:33 PM Christian Heimes wrote:
> We can easily take care of test_cppext and add the build step to
> Makefile.
What matters in test_cppext is that using the Python C API in C++ does
not emit compiler warnings, so it uses -Werror. Since this test is
very new, I would prefer
On Tue, May 10, 2022 at 6:16 PM Steve Dower wrote:
> I agree. The internal tools that use it are all in our Tools directory,
> so we can move distutils there and explicitly add an import path to
> locate it. No need to keep it in the stdlib (Lib/) at all.
>
> Migrating to Makefile builds is probab
On Tue, May 10, 2022 at 7:18 PM Guido van Rossum wrote:
> Shouldn't we wean our internal tools off this obsolete version of distutils
> too, rather than just move it around?
Here is a first PR to build the test C++ extension with setuptools in
test_cppext:
https://github.com/python/cpython/pull/
According to my notes, the summary is generated by this Python script:
https://github.com/psf/bpo-tracker-cpython/blob/master/scripts/roundup-summary
But I don't know what runs this script once a week.
Victor
On Fri, May 13, 2022 at 8:56 PM Brett Cannon wrote:
>
> Can we shut this down or unsub
Hi,
I propose adding a new C API to "build an Unicode string". What do you
think? Would it be efficient with any possible Unicode string storage
and any Python implementation?
PyPy has an UnicodeBuilder type in Python, but here I only propose C
API. Later, if needed, it would be easy to add a Pyt
On Mon, May 16, 2022 at 11:40 AM wrote:
> Cython used the private _PyUnicodeWriter API (and stopped using it on Py3.11
> when it was hidden more thoroughly)
I'm not aware of any change in the the private _PyUnicodeWriter API in
Python 3.11. Is it just that Cython no longer wants to use private
A
On Mon, May 16, 2022 at 12:51 PM wrote:
>
> Victor Stinner wrote:
> > On Mon, May 16, 2022 at 11:40 AM dw-...@d-woods.co.uk wrote:
> > > Cython used the private _PyUnicodeWriter API (and stopped using it on
> > > Py3.11 when it was hidden more thoroughly)
> >
On Mon, May 16, 2022 at 2:11 PM Antoine Pitrou wrote:
> > PyUnicodeBuilder_Init(&builder);
> >
> > // Overallocation is more efficient if the final length is unknown
> > PyUnicodeBuilder_EnableOverallocation(&builder);
> > PyUnicodeBuilder_WriteStr(&builder, key);
Hi,
Please report Python issues to the GitHub project:
https://github.com/python/cpython/issues/
The OpenBSD operating system is currently not supported by Python, so
don't expect a quick feedback:
https://peps.python.org/pep-0011/
A few years ago, I tried to provide best effort support for Open
On Mon, May 30, 2022 at 1:40 AM Eric V. Smith wrote:
> python -m tokenize < file-to-parse.py
>
> See the comment at the top of tokenize.py. IIRC, it re-implements the
> tokenizer, it does not call the one used for python code.
Ah right, I would be surprised that there would be a public Python API
h, or would you
>> be willing to share the code?
>>
>> On 30/05/2022 16:23, Pablo Galindo Salgado wrote:
>>
>> There is no *public* one but there is a private one accesible from Python I
>> added for testing purposes.
>>
>> On Mon, 30 May 2022, 15:17 Vic
Hi,
On buildbots, it's common that we get at least one multiprocessing
test failure per week. While I just reported a new one, I wanted to
add a "expert-multiprocessing" label, but it didn't exist. I just
created the label :-)
https://github.com/python/cpython/labels/expert-multiprocessing
I
Hi,
Side note: it would be nice to add "typing: " prefix or mention "type
annotation" or "type check" in the title of PEPs which are about that.
Just from the PEP title, it's hard *for me* to guess that it's about
type annotations.
Examples of other PEP titles which confused me:
PEP 612 – Param
On Mon, Jun 6, 2022 at 4:35 PM Gabriele wrote:
> The austinp variant is a variant of Austin
> (https://github.com/P403n1x87/austin) for Linux that uses ptrace to
> seize and interrupt/continue threads to capture native stack traces
> using libunwind. During testing, I have discovered that there ar
Hi,
While this problem is causing you a lot of troubles, I never had to
cross compile Python, and I guess that it's the case for most people.
Changing the Python build system and distutils is stressful since it
can break Python for the majority of users, rather than leaving the
minority of users w
On Thu, Jun 16, 2022 at 4:29 PM Xavier de Gaye wrote:
> A Google search on "andoid x86_64" gives about 10,900,000 results, showing
> that cross-compiling is quite common for the case where the build system and
> the host system have the same PLATFORM_TRIPLET as when building android
> x86_64 on
On Thu, Jun 16, 2022 at 7:54 PM Christian Heimes wrote:
> What Victor means that we would like to have clear instructions how to
> reproduce the problem ourselves. Could you please provide step by step
> instructions how I could set up a build environment on a X86_64 PC with
> a standard Linux dis
Alexei is about about https://github.com/python/cpython/issues/96853
I suggest discussing the issue there.
Victor
On Thu, Oct 6, 2022 at 9:54 PM wrote:
>
> Hi Python team
>
> Is any plan to try and fix memory leaks when embedding Python in a C/C++
> application?
>
> Thanks in advance,
> Alexei
What happened to this SC decision (move to Discourse)? People started
again to write on python-dev. So what's going on?
Should I reply on python-dev? Ask to move to Discourse?
Should we *close* the python-dev mailing list?
Victor
___
Python-Dev mailing
ve logging/sampling heap profiler for Python, and it works
> great. The package is now available via pip for anyone who needs it!
>
> On Thu, Jun 27, 2019 at 4:21 PM Yonatan Zunger wrote:
>>
>> Well, then. I think I'm going to have some fun with this. :)
>>
>>
Hi,
Oh, I just wrote a similar email to python-committers, I didn't notice
that Mariatta wrote to python-dev and python-committers.
https://mail.python.org/archives/list/python-committ...@python.org/message/53K5MJAKLRGY2F34ZCYGL3WPWSJ4C5M2/
My worry is more about closing pull requests.
Le 2
A litte bit more context.
PEP 601: "Forbid return/break/continue breaking out of finally"
https://www.python.org/dev/peps/pep-0601/
Abstract
This PEP proposes to forbid return, break and continue statements
within a finally suite where they would break out of the finally.
Their use in such a loc
Hi,
Many buildbot workers failed in the last 48 hours, it's likely related
to higher activity caused by the core dev sprint currently running at
London.
Here are failures in random order. Can someone please have a look? I
suggest to add comments to issues for collaboration.
test__xxsubinterprete
Hi,
FYI Yury Selivanov just proposed PEP 603 which is now discussed at:
https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/2318
PEP-603: Adding a frozenmap type to collections
https://www.python.org/dev/peps/pep-0603/
I don't have a strong preference between python-dev o
Le lun. 23 sept. 2019 à 21:36, Vinay Sajip via Python-Dev
a écrit :
> Nathaniel Smith wrote:
> > Windows already has working symbol visibility handling, and PyAPI_FUNC is
> > what controls it. So adding symbol visibility handling to Linux/macOS is
> > just about making all the platforms consistent
Le mer. 25 sept. 2019 à 08:24, Kyle Stanley a écrit :
> Recently, Brett updated the developer log in the devguide
> (https://devguide.python.org/developers/) to fetch the names of each core
> developer and the date they were given commit privileges from the private
> python-committers repository.
Hi,
I dislike having to do that, but I had to make a last minute change in
my PEP 587 "Python Initialization Configuration" to allow to modify
the structure in the future without breaking the backward
compatibility. I added a "struct_size" field to PyPreConfig and
PyConfig:
* https://bugs.python.
Hi Nick,
Le dim. 29 sept. 2019 à 08:47, Nick Coghlan a écrit :
> I don't quite understand the purpose of this change, as there's no
> stable ABI for applications embedding CPython.
Well, I would like to prepare Python to provide a stable ABI for
embedded Python. While it's not a design goal yet
Le lun. 30 sept. 2019 à 00:33, Nick Coghlan a écrit :
> As noted above, despite what I wrote on BPO, you no longer need to persuade
> me that the version check is desirable, only that a narrow check on specific
> struct sizes is preferable to a broad check on the expected API version.
I underst
Le lun. 30 sept. 2019 à 13:45, Nick Coghlan a écrit :
> > I understand that your main motivation to use the Python version
> > number rather than sizeof(PyConfig) is the error message.
>
> No, my main motivation is to create an API that can emit a useful
> error message on *ALL* version conflicts
Hi back,
It seems like "config.struct_size = sizeof(PyConfig);" syntax is "not
really liked".
I don't see any traction to provide a stable ABI for embedded Python.
The consensus is more towards: "it doesn't work and we don't want to
bother with false promises" (nor add code for that).
Since Luka
Le lun. 30 sept. 2019 à 23:26, Antoine Pitrou a écrit :
> I think if you wanted to make the PyConfig apt at providing
> ABI-stability, you should have designed it differently.
> `PyType_FromSpec` provides a useful model (pass an arbitrary-sized
> static array of field initializers).
PyConfig is e
Hi Łukasz,
Le lun. 30 sept. 2019 à 16:32, Łukasz Langa a écrit :
> > On 30 Sep 2019, at 16:09, Nick Coghlan wrote:
> >
> > I've filed https://bugs.python.org/issue38326 as a release blocker, as
> > I don't think we should be cutting RCs when changes have been made to
> > a PEP-approved API witho
o manually initialize these
fields, except if you explicitly want to use these new fields to
benefit of new configuration options.
Victor
Le mar. 1 oct. 2019 à 00:38, Nick Coghlan a écrit :
>
>
>
> On Tue., 1 Oct. 2019, 6:47 am Victor Stinner, wrote:
>>
>> Hi back,
>>
>&
It seems like this security fix has not been merged into the 3.5 branch yet:
"[3.5] bpo-38243, xmlrpc.server: Escape the server_title (GH-16373) (GH-16441)"
https://github.com/python/cpython/pull/16516
Please review it ;-)
Victor
Le sam. 12 oct. 2019 à 14:08, Larry Hastings a écrit :
>
>
> On
Hi Inada-san,
You can query the sysconfig module to check how Python has been built.
Example:
pyvstinner@apu$ python3
Python 3.7.4 (default, Jul 9 2019, 16:32:37)
[GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sy
Hi Fabio,
Right, the PyInterpreterState structure is now opaque. You need to
include pycore_pystate.h which requires to define the
Py_BUILD_CORE_MODULE macro. That's the internal C API which "should
not be used", but it's ok to use it for very specific use cases, like
debuggers.
Maybe we should p
Would you mind to open an issue at bugs.python.org? You can put me
("vstinner") in the nosy list.
Victor
Le mer. 16 oct. 2019 à 17:07, Fabio Zadrozny a écrit :
>
>
> On Wed, Oct 16, 2019 at 11:14 AM Victor Stinner wrote:
>>
>> Hi Fabio,
>>
>> Rig
Hi,
Our bundled copy of libffi has been removed from Python 3.7 by this
change which should explain the rationale:
https://bugs.python.org/issue27979
Not all Python changes need a PEP. For Windows builds, we provide
prebuilt binaries of our dependencies:
https://github.com/python/cpython-source-d
Hi,
I wrote a PR to fix the following urllib security vulnerability:
"urlparse of urllib returns wrong hostname"
https://bugs.python.org/issue36338
https://github.com/python/cpython/pull/16780
While writing my fix, I found another issue about "[" and "]"
characters in the user:password section o
Hi,
Right now, there are 14 open issues with "test_asyncio" in the title.
Many test_asyncio tests have race conditions. I'm trying to fix them
one by one, but it takes time, and then new tests are added with new
race condition :-( For example, the following new test is failing
randomly on Windows:
Hi,
I just posted a new PEP for comments, please reply there, rather than by email:
https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539
PEP 608: Coordinated Python release
https://www.python.org/dev/peps/pep-0608/
Abstract:
Block a Python release until a compatible version
I replied at
https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539/9
I would prefer to not split the discussion. I understood that
discuss.python.org is now preferred to discuss PEPs. And I don't want
to discuss here where PEPs should be discussed :-)
Victor
Le ven. 25 oct. 2
Le jeu. 31 oct. 2019 à 11:41, Serhiy Storchaka a écrit :
> I propose to deprecate the falling back to __trunc__ for converting to
> int and remove it in future.
As Nick already said, I'm working on PEP 608 "Coordinated Python
release" which discuss such change:
https://www.python.org/dev/peps/pep
I wrote PEP 606 "Python Compatibility Version" which tries to address
a similar problem, but with a different approach:
https://www.python.org/dev/peps/pep-0606/
It mentions PEP 497 by the way ;-)
It has been discussed at:
https://mail.python.org/archives/list/python-id...@python.org/thread/SETZ6
Hi,
Are you ok to modify internal C functions to pass explicitly tstate?
--
I started to modify internal C functions to pass explicitly "tstate"
when calling C functions: the Python thread state (PyThreadState).
Example of C code (after my changes):
if (_Py_EnterRecursiveCall(tstate, "
Le mer. 13 nov. 2019 à 14:28, Larry Hastings a écrit :
> I did exactly that in the Gilectomy prototype. Pulling it out of TLS was too
> slow,
What do you mean? Getting tstate from a TLS was a performance
bottleneck by itself? Reading a TLS variable seems to be quite
efficient.
Mark Shannon wro
Petr, Eric: sure, my question is only about the internal C functions.
I have no plan to change the existing C API.
Le mer. 13 nov. 2019 à 14:52, Eric V. Smith a écrit :
> The last time we discussed this, there was pushback due to performance
> concerns. I don't recall if that was actually measure
Le jeu. 14 nov. 2019 à 04:55, Larry Hastings a écrit :
> I'm pretty sure you understand the sentence "Pulling it out of TLS was too
> slow". At the time CPython used the POSIX APIs for accessing thread local
> storage, and I didn't know about and therefore did not try this "__thread"
> GCC ext
Le sam. 16 nov. 2019 à 20:55, Neil Schemenauer
a écrit :
> If you use threadstate often,
> passing it explicitly (which likely uses a CPU register) could be a
> win. If you use it rarely, that CPU register would be better
> utilized for passing function arguments you actually use.
Currently, I
Hi,
Le mar. 19 nov. 2019 à 01:42, Pablo Galindo Salgado
a écrit :
> What do people feel about exposing Tools/parser/unparse.py in the standard
> library?
I like the idea. I compared Lib/os.py to the unparse output and now I
have many questions :-)
(*) unparse loses all formatting and comments.
Hi,
Le mar. 19 nov. 2019 à 18:33, Sümer Cip a écrit :
> First of all, I would like to thank for such a useful tool for debugging
> memory issues. I am pretty proud as a Python lover that we have such a tool:
> tracemalloc:)
As the module author: you're welcome ;-)
> AFAIU, tracemalloc holds
Le mar. 19 nov. 2019 à 22:12, Pablo Galindo Salgado
a écrit :
> > Float infinity is replaced with 1e309. Again, maybe someone wants
> to render this differently? It sounds like an arbitrary choice (which
> "works" as expected).
>
> That is not true. float('inf') is rendered as float('inf´):
>
> >
I'm in favor of adding a public C API to get and set the frame
evaluation function. API excluded from the limited API.
I wrote https://github.com/python/cpython/pull/17340 to add such API
to Python 3.8.1. For me, it's a Python 3.8.0 regression.
Victor
_
I modified "make install" to install internal header files, so it's
possible to use the internal C API in debuggers and profilers. For
example, to be able to inspect Python internals without having to call
functions (which might modify the Python internal state). I made this
change to be able to mo
It has been discussed a few months ago. There is the "if six.PY3: ..."
issue and similar issues which should be solved first. Basic example:
$ python3
Python 3.7.5 (default, Oct 17 2019, 12:16:48)
>>> import sys
>>> sys.version_info = (4,0)
>>> import six
Traceback (most recent call last):
File
Hi,
Le lun. 2 déc. 2019 à 08:18, Larry Hastings a écrit :
> My random Googling turned up a new hash function tonight: "HighwayHash".
> It's a keyed hash function like the SipHash we now use for hashing strings /
> bytes / etc for our lovely dicts.
>
> Key points:
>
> Apache 2 license
> Can use
Le mer. 4 déc. 2019 à 06:41, Inada Naoki a écrit :
> Currently, u-prefix is very widely used. It shouldn't be removed anytime
> soon.
> And I agree that we shouldn't raise DeprecationWarning for now.
>
> But how about 5, 10, and 20 years later? No one knows it.
> Let's stop discussing it. It c
You may want to have a look at the deferred PEP 501 -- General purpose
string interpolation:
https://www.python.org/dev/peps/pep-0501/
It was proposed while PEP 498 -- Literal String Interpolation
(f-string) was being discussed, which was accepted:
https://www.python.org/dev/peps/pep-0498/
PEP 50
Le mer. 4 déc. 2019 à 01:45, Charalampos Stratakis
a écrit :
> Also noting here that the reference leaks builds are triggered once a day so
> many times it's not possible to find the commit that triggered a leak through
> the web ui of buildbot. In this case it's good to also check the previous
INADA-san:
> We need to avoid major breakage.
> But we accept small breakages on every minor release.
> And u-prefix is major for now.
IMHO we need a metric to measure the risk of an incompatible change:
estimate the percentage of broken Python applications. For example,
run the test suite of the
Hi,
I'm working on cleaning up the C API, long rationale:
https://pythoncapi.readthedocs.io/
Macros are causing multiple issues:
* They often leak "implementation details" and so are incompatible
with a stable ABI
* They have multiple pitfalls:
https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.h
Le mer. 4 déc. 2019 à 14:49, Thomas Wouters a écrit :
>> (...)
>> It's very different if an incompatible change break 1% or 90% of
>> Python projects.
>
> Unfortunately there is a distinctive bias if you select popular projects, or
> even packages from PyPI. There is a very large body of work tha
Please try to get an email client which is able to reply in a thread,
rather than creating a new thread each time you send an email.
You might want to try HyperKitty:
https://mail.python.org/archives/list/python-dev@python.org/
Victor
Le jeu. 5 déc. 2019 à 10:50, Anders Munch a écrit :
>
> >> I
Le jeu. 5 déc. 2019 à 12:14, Thomas Wouters a écrit :
> It should, but it doesn't always :) If you forget how your data is flawed,
> the 'smarter' decision can easily be wrong, instead. I do think it's a good
> idea to reject ideas that would break a certain number of PyPI packages, say,
> but
to work on the CI idea to provide a feedback on broken projects.
> We want to thank Victor Stinner and Miro Hrončok for their contributions and
> authorship of these PEPs.
You're welcome ;-)
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
__
Hello,
Le mar. 26 nov. 2019 à 20:40, Brett Cannon a écrit :
> I have turned Travis off as a required check on the 3.7, 3.8, and master
> branches until someone is able to get a fix in.
That makes me sad :-( Is there an issue at bugs.python.org to track
it? What's the status? Right now, I see Tr
2001 - 2100 of 3215 matches
Mail list logo
