Hi,
Le mer. 27 nov. 2019 à 19:40, Brett Cannon a écrit :
> What do people think of the idea of requiring all deprecations specifying a
> version that the feature will be removed in (which under our annual release
> cadence would be at least the third release from the start of the
> deprecation
Le ven. 6 déc. 2019 à 16:00, Guido van Rossum a écrit :
> Let's try to avoid having PEP discussions in the peps tracker, period. That
> repo's tracker is only meant to handle markup and grammar.
I recall that some PEPs have been discussed in length in GitHub PRs.
But I'm fine with keeping the di
In that case, would you mind to make Travis CI mandatory again?
Victor
Le ven. 6 déc. 2019 à 19:10, Brett Cannon a écrit :
>
> Victor Stinner wrote:
> > Hello,
> > Le mar. 26 nov. 2019 à 20:40, Brett Cannon br...@python.org a écrit :
> > > I have turned Travis off
FYI the Fedora package always re-generate the configure script as part
of the package build ;-)
https://src.fedoraproject.org/rpms/python3/blob/master/f/python3.spec#_639
"""
%build
# Regenerate the configure script and pyconfig.h.in
autoconf
autoheader
(...)
"""
It's part of Fedora packaging
Can you please open an issue at https://bugs.python.org/ and then post
the link in this thread?
Thanks in advance,
Victor
Le mar. 10 déc. 2019 à 14:18, Christian Tismer a écrit :
>
> Hi Łukasz,
>
> tonite I found a critical bug that affects all heaptype extension
> classes with a custom (not PyT
What is the issue? Can someone please open a bug report at
https://bugs.python.org/ so I can try to investigate?
Victor
Le ven. 13 déc. 2019 à 02:05, Brett Cannon a écrit :
>
> This is failing again, so I had to switch off Travis from being a requirement
> (again).
>
> I'm not not going to flip
failed to download packages on the
Linux jobs on the Azure Pipelines.
In short, having multiple CIs is a good thing :-)
Victor
Le ven. 13 déc. 2019 à 02:42, Kyle Stanley a écrit :
>
> Victor Stinner wrote:
> > What is the issue? Can someone please open a bug report at
> https://bu
That looks quite interesting. It looks like compact dict optimization
applied to set. I had the same idea :-)
If it reduces the memory footprint, keep insertion order and has low
performance overhead, I would be an interesting idea!
Victor
Le lun. 16 déc. 2019 à 07:56, Inada Naoki a écrit :
>
>
Hi,
Le mer. 18 déc. 2019 à 16:43, Julien Danjou a écrit :
> The only way to retrieve the current exception is via sys.excinfo or
> PyErr_GetExcInfo in C. However, the issue is that they don't take a
> PyThreadState as argument, but use _PyThreadState_GET() to retrieve the
> thread state.
If we a
Le mer. 8 janv. 2020 à 07:02, Kyle Stanley a écrit :
> A more generalized Python code search across GitHub of "orderedset" returns
> ~500k results: https://github.com/search?l=Python&q=orderedset&type=Code .
Sadly this search seems to count how my projects put their virtual
environment on GitHub
Hi,
I started to modify Python internals to pass explicitly the Python
thread state ("tstate") to internal C a functions:
https://vstinner.github.io/cpython-pass-tstate.html
Until subinterpreters will be fully implemented, it's unclear if
getting the current Python thread state using _PyThreadSta
Hi,
I dislike python-config for multiple reasons
You may get the wrong information if you pick the wrong python-config script :-(
IMHO we should add a new module (problem: how should it be called?
pyconfig?) which could be used using "python3 -m xxx ...". There is a
similar discussion between "p
Le mer. 8 janv. 2020 à 22:15, Nick Coghlan a écrit :
> The vectorcall convention places a significant emphasis on speed, so
> being able to do a single PyThreadState_Get() call on the initial
> transition from Python to C, and then pass the thread state explicitly
> after that would make a lot of
Le jeu. 9 janv. 2020 à 13:35, Mark Shannon a écrit :
> Passing the thread state explicitly creates a new class of errors that
> was not there before.
> What happens if the tstate argument is NULL,
You will likely get a crash.
> or points to a different thread?
No idea what will happen. If it's
Le jeu. 9 janv. 2020 à 12:11, Xavier de Gaye a écrit :
> The shell script python-config has been introduced by bpo issue 16235 named
> "Add python-config.sh for use during cross compilation" in order "to behave
> exactly the same as python-config.py except it doesn't depend on a Python
> interp
Le jeu. 9 janv. 2020 à 19:33, Steve Dower a écrit :
> Requiring an _active_ Python thread (~GIL held) to only run on a single
> OS thread is fine, but tying it permanently to a single OS thread makes
> things very painful. (Of course, this isn't the only thing that makes it
> painful, but if we're
Le jeu. 9 janv. 2020 à 17:19, Xavier de Gaye a écrit :
> A cross-compilation means that there is probably no build framework on the
> target platform and therefore the build configuration of the
> cross-compilation of Python is not very useful there.
Ok, so the shell script python-config is use
Le ven. 10 janv. 2020 à 20:44, Jim J. Jewett a écrit :
> Is work this summarized somewhere like a PEP?
This work is related to:
PEP 554 -- Multiple Interpreters in the Stdlib
https://www.python.org/dev/peps/pep-0554/
Victor
___
Python-Dev mailing list
Hi,
I proposed https://bugs.python.org/issue39352 to remove the formatter
module. It's deprecated since Python 3.4. The main reason why it's
still around is the PEP 4 rule:
"In order to facilitate writing code that works in both Python 2 & 3
simultaneously, any module that exists in both Python 3
and combine it with PYTHONDEVMODE=1.
Warnings filters can be used to ignore warnings in third party code,
see the documentation:
https://docs.python.org/dev/library/warnings.html#the-warnings-filter
-- Victor Stinner and Miro Hrončok for Fedora
___
Pyth
Le jeu. 23 janv. 2020 à 20:45, Brett Cannon a écrit :
> Two pieces of feedback on this. One, nose is a bad example because that
> project has been telling people for years to switch to nose2 so the fact that
> people have still not switched something that should mostly be a direct swap
> after
Le ven. 24 janv. 2020 à 08:37, Miro Hrončok a écrit :
> No, the motivation to pospone the changes to 3.10 are projects that alrady
> support both 2 and 3 at the same time, with or without compatibility libraries
> like six. Before they had anough time to make the necessary actions to abandon
> Pyt
You're right that it's not only about list.count().
IMO it's a good optimization to skip __eq__() when id(x) == id(y). But
it can be surprising, so I just would like to document it somewhere.
For example, in __eq__() method documentation:
https://docs.python.org/dev/reference/datamodel.html#object
Le ven. 24 janv. 2020 à 03:37, Guido van Rossum a écrit :
> I think this started with a valuable optimization for `x in `. I don't
> know if that was ever carefully documented, but I remember that it was
> discussed a few times (and IIRC Raymond was adamant that this should be so
> optimized --
The change is that Python 2.7 is no longer supported (since 2020-01-01).
Victor
Le ven. 24 janv. 2020 à 09:19, Chris Angelico a écrit :
>
> On Fri, Jan 24, 2020 at 7:05 PM Victor Stinner wrote:
> > We kept a compatibility layer with Python 2 on purpose, PEP 4 says:
> >
mited resources. Even if we propose pull requests, it still
takes time to review it, prepare a new release, etc.
Victor
Le ven. 24 janv. 2020 à 09:42, Chris Angelico a écrit :
> On Fri, Jan 24, 2020 at 7:40 PM Victor Stinner wrote:
> >
> > The change is that Python 2.7 is no long
Le ven. 24 janv. 2020 à 19:28, Brett Cannon a écrit :
> (...) otherwise I could be reading most of that email as if you're suggesting
> we bring back the print statement or something. ;)
By the way, about adding back print statement... nah, I'm just kidding :-D
Victor
__
Le ven. 24 janv. 2020 à 19:35, Brett Cannon a écrit :
> I'm also okay with a one-time delay in removals that are problematic for code
> trying to get off of Python 2.7 this year and might not quite cut it before
> 2021 hits. I'm sure some people will be caught off-guard once 3.9b1 comes out
> a
See pyfound.blogspot.com/2019/12/python-2-sunset.html for the details.
January or April doesn't matter much for this thread, since Python
3.9.0 final is scheduled for October.
Victor
Le lun. 27 janv. 2020 à 23:13, Barry Scott a écrit :
>
>
>
> > On 24 Jan 2020, at 08:40, V
You may open a ticket at
https://github.com/python/bugs.python.org/issues but I'm not sure who
is in charge of bugs.python.org, nor how to merge two accounts.
Victor
Le mar. 28 janv. 2020 à 17:21, Ivan Pozdeev via Python-Dev
a écrit :
>
> Who should I contact on subj? BPO UI doesn't have any con
Hi,
I would like to confirm that there is no user of the Python
"COUNT_ALLOCS" special build, because I plan to remove it from Python
3.9. If you use it, please raise your hand and explain why other debug
tools don't fit your specific use case.
--
I'm always annoyed by "#ifdef COUNT_ALLOCS" code
Hi,
Is it ok to add a static inline function to the limited API? Can it
cause ABI issue? Or is it safer to add a regular function? For
example, is it safe to add the following function to the limited API?
static inline PyObject *
_PyObject_CallOneArg(PyObject *func, PyObject *arg)
{
...
r
You can find the rationale for this change in two issues:
* https://bugs.python.org/issue27987
* https://bugs.python.org/issue36618
First, it was a warning in clang ubsan (Undefined Behavior Sanitizer).
Then ctypes started to crash when Python was compiled with clang. It
means that compiling Pyth
Le sam. 1 févr. 2020 à 12:34, Steve Dower a écrit :
> I think we're at the point where it's probably okay to disable Azure
> Pipelines as a required check and replace it with the GitHub Actions checks.
More and more often, I'm waiting for Azure Pipelines to complete: it's
currently the slowest "C
Le jeu. 23 janv. 2020 à 16:20, Victor Stinner a écrit :
>
> Hi,
>
> Python 3.9 introduces many small incompatible changes which broke tons
> of Python projects, including popular projects, some of them being
> unmaintained but still widely used (like nose, last release in 2015).
&
Elad created the issue:
"distutils.spawn should use subprocess (hang in parallel builds on QNX)"
https://bugs.python.org/issue39763
Victor
Le mer. 26 févr. 2020 à 20:22, Elad Lahav a écrit :
>
> Done.
>
> Thanks,
> --Elad
> ___
> Python-Dev mailing li
Le mar. 3 mars 2020 à 20:30, Abdur-Rahmaan Janhangeer
a écrit :
> Just for learning purposes, why was this improvement not included at the
> beginning? (I missed the original thread)
It's explained in the second paragraph of the PEP:
https://www.python.org/dev/peps/pep-0614/#motivation
Victor
-
You should check for
DeprecationWarning in your code" section to "What's New In Python 3.9"
document, to strongly advice users to check for deprecation warnings
in their code:
https://docs.python.org/dev/whatsnew/3.9.html#you-should-check-for-deprecationwarning-in-your-code
Victor
Le ma
Hi,
I plan to merge my PR 17340 at the end of week to not miss Python 3.9
feature freeze deadline, unless someone speaks up and find a good
reason to not merge this PR. The PR adds a public C API
PyInterpreterState_SetEvalFrameFunc() and now pass tstate to the frame
evaluation function.
Please di
Hi,
> Changes on this scale merit a PEP and proper discussion, rather than
> being added piecemeal without proper review.
Last November, I asked explicitly on python-dev if we should "Pass the
Python thread state to internal C functions":
https://mail.python.org/archives/list/python-dev@python.or
Mark opened https://bugs.python.org/issue39978 "Vectorcall
implementation should conform to PEP 590" where he wrote that passing
tstate explicitly slows down PyObject_Vectorcall().
Victor
Le lun. 16 mars 2020 à 15:16, Mark Shannon a écrit :
>
> Hi,
>
> There seems to be a proliferation of `PyThr
ython implementation and how it evolves in the last two years.
Victor
Le lun. 16 mars 2020 à 16:04, Victor Stinner a écrit :
>
> Hi,
>
> > Changes on this scale merit a PEP and proper discussion, rather than
> > being added piecemeal without proper review.
>
> Last November
Le mar. 17 mars 2020 à 15:47, Mark Shannon a écrit :
> > There is no PEP but scatted documents. I wrote a short article to
> > elaborate the context of this work:
> > https://vstinner.github.io/cpython-pass-tstate.html
> >
> > One motivation is to ease the implementation of subinterpreters (PEP
>
Le mar. 17 mars 2020 à 15:49, Mark Shannon a écrit :
> > * https://bugs.python.org/issue10915
> > * https://bugs.python.org/issue15751
> >
> > It's unclear to me if fixing this issue would require to add a lock,
> > nor if it would make PyGILState_GetThisThreadState() or
> > _PyThreadState_GET() s
Le jeu. 19 mars 2020 à 02:17, Kyle Stanley a écrit :
> Agreed; a PEP (even if it's just informational) would go a long way in
> helping to clear up some misunderstandings.
I am still moving blindly in the darkness of CPython internals and so
I don't feel comfortable to write a PEP which would me
Hi Dennis,
Thanks for writing a proper PEP. It easier to review a specification
than an implementation.
Le ven. 20 mars 2020 à 20:00, Dennis Sweeney
a écrit :
> Abstract
>
>
> This is a proposal to add two new methods, ``cutprefix`` and
> ``cutsuffix``, to the APIs of Python's various
Well, if CPython is modified to implement tagged pointers and supports
storing a short strings (a few latin1 characters) as a pointer, it may
become harder to keep the same behavior for "x is y" where x and y are
strings.
Victor
Le sam. 21 mars 2020 à 17:23, Eric V. Smith a écrit :
>
> On 3/21/2
ars 2020 à 17:45, Eric V. Smith a écrit :
>
> On 3/21/2020 12:39 PM, Victor Stinner wrote:
> > Well, if CPython is modified to implement tagged pointers and supports
> > storing a short strings (a few latin1 characters) as a pointer, it may
> > become harder to keep the sa
Le dim. 22 mars 2020 à 01:45, Dennis Sweeney
a écrit :
> For accepting multiple prefixes, I can't tell if there's a consensus about
> whether
> ``s = s.cutprefix("a", "b", "c")`` should be the same as
>
> for prefix in ["a", "b", "c"]:
> s = s.cutprefix(prefix)
>
> or
>
> for prefix in ["a
Le sam. 21 mars 2020 à 04:14, Stephen J. Turnbull
a écrit :
> But ... this sounds to me like work that should be done on a branch.
>
> I'm sure you considered that, but I also expect others will feel the
> same way. Perhaps this is a good opportunity to document why it's not
> being done on a bra
Le dim. 22 mars 2020 à 06:07, Gregory P. Smith a écrit :
> Nice PEP! That this discussion wound up in the NP-complete "naming things"
> territory as the main topic right from the start/prefix/beginning speaks
> highly of it. :)
Maybe we should have a rule to disallow bikeshedding until the
foun
Dennis: please add references to past discussions in python-ideas and
python-dev. Link to the first email of each thread in these lists.
Victor
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.o
slicing makes the most sense
> (and, notably, slice itself returns `str` unless explicitly overridden,
> the default is for it to return `str` anyway...).
>
> Either way, it would be nice to see the rationale included in the PEP
> somewhere.
>
> Best,
> Paul
>
> On 3/22/2
Hi,
It seems like you should be to modify frame->f_lasti in a trace function
FYI in a frame object, the line number is computed using
frame->f_lasti and f->f_code->co_lnotab: PyFrame_GetLineNumber().
See: https://github.com/python/cpython/blob/master/Objects/lnotab_notes.txt
Good luck ;-)
Vict
Does it work with subinterepreters? Especially when a native thread
has two Python thread states of two different interpreters.
Victor
Le mar. 24 mars 2020 à 16:36, Mark Shannon a écrit :
>
> Hi,
>
> As an experiment, I thought I would try moving the thread state (what
> you get from _PyThreadSt
Hi Dennis,
Thanks for the updated PEP, it looks way better! I love the ability to
pass a tuple of strings ;-)
--
The behavior of tuple containing an empty string is a little bit surprising.
cutsuffix("Hello World", ("", " World")) returns "Hello World",
whereas cutsuffix("Hello World", (" World
Hi Mark,
Le mar. 24 mars 2020 à 21:05, Mark Shannon a écrit :
> A native thread can only have one Python thread at a time, and must
> switch using the PyThreadState_Swap() API.
Right.
> So, I think the answer is yes.
Nice.
> Do you have a specific example or testcase?
I don't know well the C
Le mar. 24 mars 2020 à 20:06, Paul Sokolovsky a écrit :
> === config.something ===
> # If you'd like to remove some prefix from your lines, set it here
> REMOVE_PREFIX = ""
> ==
>
> === src.py ===
> ...
> line = line.cutprefix(config.REMOVE_PREFIX)
> ...
> ==
Just use:
if config.REMOVE_P
Le mer. 25 mars 2020 à 00:29, Dennis Sweeney
a écrit :
> Lastly, since the issue of multiple prefixes/suffixes is more controversial
> and seems that it would not affect how the single-affix cases would work, I
> can remove that from this PEP and allow someone else with a stronger opinion
> abo
Thanks for the pointers to emails.
Ethan Furman: "This is why replace() still only takes a single
substring to match and this isn't supported: (...)"
Hum ok, it makes sense. I agree that we can start with only accepting
str (reject tuple), and maybe reconsider the idea of accepting a tuple
of str
Hi,
I understand that you are looking for PyEval_SetTrace(NULL, NULL) to
unregister a trace function set previously.
Maybe the documentation should be enhanced to explain that. Do you
want to propose a PR to enhance the doc?
https://docs.python.org/dev/c-api/init.html?highlight=pyeval_settrace#c
What do you think of adding a Version History section which lists most
important changes since your proposed the first version of the PEP? I
recall:
* Version 3: don't accept tuple
* Version 2: Rename cutprefix/cutsuffix to removeprefix/removesuffix,
accept tuple
* Version 1: initial version
For
My intent is to help people like me to follow the discussion on the
PEP. There are more than 100 messages, it's hard to follow PEP
updates.
Victor
Le dim. 29 mars 2020 à 14:55, Rob Cliffe via Python-Dev
a écrit :
>
>
>
> On 28/03/2020 17:02, Victor Stinner wrote:
> > What
IMHO it's too late to touch the Python 2.7 documentation.
Victor
Le dim. 29 mars 2020 à 16:01, Sumana Harihareswara a écrit
:
>
> On 3/27/20 12:49 PM, Sumana Harihareswara wrote:
> > Benjamin: now that PyCon 2020 has been cancelled, are you considering
> > releasing 2.7.18 slightly earlier?
>
>
Hi,
The Python Steering Council accepts PEP 585 "Type Hinting Generics In
Standard Collections":
https://www.python.org/dev/peps/pep-0585/
Congrats Łukasz Langa for your tenacity! (PEP written one year ago.)
Thanks also to everyone who was involved in the discussion to help to
get a better PEP ;
I suggest you to wait one more week to let other people comment the
PEP. After this delay, if you consider that the PEP is ready for
pronouncement, you can submit it to the Steering Council, right.
Victor
Le mer. 1 avr. 2020 à 21:56, Dennis Sweeney
a écrit :
>
> Hello all,
>
> It seems that most
Hi,
It's great to see that you finally managed to come up with a PEP, this
work becomes concrete: congrats!
I started to read the PEP, and it's really well written! I heard that
LL(1) parsers have limits, but this PEP explains very well that the
current Python grammar was already "hacked" to work
vious section."
Victor
Le ven. 3 avr. 2020 à 02:58, Greg Ewing a écrit :
>
> On 3/04/20 10:33 am, Victor Stinner wrote:
> > I also like the fact that PEG is deterministic, whereas
> > LL(1) parsers are not.
>
> Where do you get that LL(1) parsers are not deterministic?
Hi Skip,
I wrote the feature (both tracemalloc and query tracemalloc when a
buffer overflow is detected), so I should be able to help you ;-)
Le dim. 5 avr. 2020 à 00:27, Skip Montanaro a écrit :
> Looking at the tracemalloc module docs and trying various command line args
> (-X tracemalloc=5)
Le dim. 5 avr. 2020 à 04:02, Skip Montanaro a écrit :
> The command is
>
> % PYTHONTRACEMALLOC=5 ./python ./Tools/scripts/run_tests.py -R
> 5:50:reflog.txt test_rattlesnake
> (...)
> FWIW, the register branch of my CPython fork:
>
> https://github.com/smontanaro/cpython/tree/register
gdb tracebac
Le dim. 5 avr. 2020 à 23:07, Skip Montanaro a écrit :
> I'm trying it the simplest way I can think of. Registers are exactly
> like local variables, so SETLOCAL Py_XDECREFs whatever is already
> there before overwriting it with a new value. At the end of
> _PyEval_EvalFrameDefault if the code obje
HPy. The transition from Python 2 to Python 3 showed that migrations
are very slow and never fully complete.
The PEP also rely on the assumption that `Most C extensions don't rely
directly on CPython internals`_ and so will remain compatible with the
new opaque C API.
The concept of HPy is not
Le ven. 10 avr. 2020 à 22:00, Antoine Pitrou a écrit :
> > Examples of issues to make structures opaque:
> >
> > * ``PyGC_Head``: https://bugs.python.org/issue40241
> > * ``PyObject``: https://bugs.python.org/issue39573
> > * ``PyTypeObject``: https://bugs.python.org/issue40170
>
> How do you keep
Le ven. 10 avr. 2020 à 22:00, Antoine Pitrou a écrit :
> How do you keep fast type checking such as PyTuple_Check() if extension
> code doesn't have access e.g. to tp_flags?
>
> I notice you did:
> """
> Add fast inlined version _PyType_HasFeature() and _PyType_IS_GC()
> for object.c and typeobjec
Le ven. 10 avr. 2020 à 22:00, Antoine Pitrou a écrit :
> > Debug runtime and remove debug checks in release mode
> > .
> >
> > If the C extensions are no longer tied to CPython internals, it becomes
> > possible to switch to a Python runtime buil
Barry Scott created https://bugs.python.org/issue40260 and
https://github.com/python/cpython/pull/19488.
Victor
Le dim. 12 avr. 2020 à 22:11, Barry Scott a écrit :
>
>
> On 11 Apr 2020, at 16:28, Barry Scott wrote:
>
> modulefinder.py does not open source files in "rb" which
> prevents compile(
Hi Ronald,
Le mar. 14 avr. 2020 à 18:25, Ronald Oussoren a écrit :
> Making “PyObject” opaque will also affect the stable ABI because even types
> defined using the PyTypeSpec API embed a “PyObject” value in the structure
> defining the instance layout. It is easy enough to change this in a way
Le mer. 15 avr. 2020 à 05:02, Raymond Hettinger
a écrit :
> I would like to make that functionality available to the JSON module (or just
> about anything else that accepts a custom dict) by adding the magic methods
> for mappings so that this works:
>
> catalog = json.load(f, object_hook=S
Le mer. 15 avr. 2020 à 23:38, Glenn Linderman a écrit :
> Do the child objects truly need to be wrapped, or just accessed?
>
> Thanks for your comments though, they inspired a thought.
>
> The problem with the glom syntax versus the dotted syntax is that the
> minimal syntax is bulky.
>
> obj.abc.
Hi Eric,
Le ven. 17 avr. 2020 à 20:56, Eric Snow a écrit :
> With the 3.9 feature freeze coming up I'm considering options for PEP
> 554. I'm hopeful to have a pronouncement from Antoine in the near
> future. If that comes in time for 3.9, we will have the
> implementation ready to go. It is a
Le ven. 17 avr. 2020 à 20:56, Eric Snow a écrit :
> keep in mind that
> subinterpreters currently have various other limitations (aside from
> sharing the GIL):
>
> * nothing about them has been optimized (e.g. interpreter startup,
> data sharing, data passing)
> * extension modules with process-g
Hi,
The Python Steering Council accepts the PEP 616 "String methods to
remove prefixes and suffixes":
https://www.python.org/dev/peps/pep-0616/
Congrats Dennis Sweeney!
We just have one last request: we expect the documentation to explain
well the difference between removeprefix()/removesuffix()
Congrats Paul! This one wasn't easy!
When Paul got promoted, I asked him if he could write a PEP about the
local timezone. Well, here we are ;-)
Paul: can I now also get nanosecond resolution? :-D
https://bugs.python.org/issue15443
Oh, and leap seconds?
https://bugs.python.org/issue23574
I comm
Hi,
Le sam. 18 avr. 2020 à 19:16, Antoine Pitrou a écrit :
> Mostly, I hope that by making the
> subinterpreters functionality available to pure Python programmers
> (while it was formally an advanced and arcane part of the C API), we
> will spur of bunch of interesting third-party experimentatio
Hi Nathaniel,
Thanks for your very interesting analysis :-)
Le ven. 17 avr. 2020 à 23:12, Nathaniel Smith a écrit :
> - The asyncio designers (esp. Guido) did a very extensive analysis of
> these libraries' design choices, spoke to the maintainers about what
> they'd learned from hard experienc
Le mar. 21 avr. 2020 à 00:50, Nathaniel Smith a écrit :
> Why do you believe that subinterpreters will have reduced resource
> usage? I assume you're comparing them to subprocesses here.
> Subinterpreters are "shared-nothing"; all code, data, etc. has to be
> duplicated, except for static C code .
__future__ imports only have effects on the parser and compiler.
PEP 554 is mostly a Python module, currently named "_xxsubinterpreters".
Victor
Le mar. 21 avr. 2020 à 15:37, Edwin Zimmerman
a écrit :
>
> On Tuesday, April 21, 2020 9:20 AM Victor Stinner
> [mailto:vstin..
Copy of Brett Cannon's message:
https://discuss.python.org/t/collecting-questions-for-a-steering-council-q-a/4010
---
As part of PyCon US 2020 (*), we are planning to record a Q&A with the
Steering Council. We are using this topic to solicit questions from
the community. We plan to leave this open
Hi,
A pattern that I used multiple times is to compute an object attribute
only once and cache the result into the object. Dummy example:
---
class X:
def __init__(self, name):
self.name = name
self._cached_upper = None
def _get(self):
if self._cached_upper is None
Oh, I didn't know this Python 3.8 new feature
(@functools.cached_property). It does exactly what I needed, cool!
Victor
Le mar. 28 avr. 2020 à 21:18, Brett Cannon a écrit :
>
> Victor Stinner wrote:
> > Hi,
> > A pattern that I used multiple times is to compute an object
Hi,
Since Python 3 "str" type already means Unicode, I understand that
Python 3 made this PEP outdated. Since Python 2 reached it's end of
life, it seems perfectly safe to reject this PEP now.
Victor
Le lun. 4 mai 2020 à 15:26, Henk-Jaap Wagenaar
a écrit :
>
> The following deferred PEP seems t
, Guido van Rossum a écrit :
>
> Agreed.
>
> On Mon, May 4, 2020 at 07:34 Victor Stinner wrote:
>>
>> Hi,
>>
>> Since Python 3 "str" type already means Unicode, I understand that
>> Python 3 made this PEP outdated. Since Python 2 reached it'
Hi,
I wrote a "per-interpreter GIL" proof-of-concept: each interpreter
gets its own GIL. I chose to benchmark a factorial function in pure
Python to simulate a CPU-bound workload. I wrote the simplest possible
function just to be able to run a benchmark, to check if the PEP 554
would be relevant.
Hi Nathaniel,
Le mer. 6 mai 2020 à 04:00, Nathaniel Smith a écrit :
> As far as I understand it, the subinterpreter folks have given up on
> optimized passing of objects, and are only hoping to do optimized
> (zero-copy) passing of raw memory buffers.
I think that you misunderstood the PEP 554.
Le mer. 6 mai 2020 à 22:10, Serhiy Storchaka a écrit :
> I am wondering how much 3.9 will be slower than 3.8 in single-thread
> single-interpreter mode after getting rid of all process-wide singletons
> and caches (Py_None, Py_True, Py_NonImplemented. small integers,
> strings, tuples, _Py_IDENTIF
Hi,
Le mer. 13 mai 2020 à 02:04, Giampaolo Rodola' a écrit :
> I would like to discuss a proposal regarding one aspect which AFAIK is
> currently missing from cPython's test suite: the ability to detect memory
> leaks of functions implemented in the C extension modules.
test.regrtest can be us
C extensions "should" use PyMem_Malloc/PyMem_Free to benefit of PEP
445 hooks like debug hooks and tracemalloc.
* Debug hooks (enabled by -X dev) helps to debug buffer overflow:
https://docs.python.org/dev/c-api/memory.html#c.PyMem_SetupDebugHooks
* tracemalloc: https://docs.python.org/dev/library
Le mer. 20 mai 2020 à 02:39, Terry Reedy a écrit :
> First, with 2.x really past us, is removing remaining long deprecated
> features, plus some others advocated for removal. I think these are
> best done by the first alpha so that early testers are rewarded with an
> early opportunity to change
Hi,
In Python 3.9, I *removed* dozens of functions from the *public* C
API, or moved them to the "internal" C API:
https://docs.python.org/dev/whatsnew/3.9.html#id3
For a few internal C API, I replaced PyAPI_FUNC() with extern to
ensure that they cannot be used outside CPython code base: Python 3
Le mer. 3 juin 2020 à 19:17, Mark Shannon a écrit :
> > I also *added* a bunch of *new* "getter" or "setter" functions to the
> > public C API for my project of hiding implementation details, like
> > making structures opaque:
> > https://docs.python.org/dev/whatsnew/3.9.html#id1
>
> Adding "sette
2101 - 2200 of 3215 matches
Mail list logo
