Change by Petr Viktorin :
--
keywords: +patch
pull_requests: +8600
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34626>
___
___
Py
New submission from Petr Viktorin :
The documentation of PyType_FromSpec and PyType_FromSpecWithBases is currently
not very useful. In particular, PyType_Spec and PyType_Slot are only documented
in pep-0384, not in the Python docs.
--
messages: 324975
nosy: petr.viktorin
priority
Change by Petr Viktorin :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue25083>
___
___
Pyth
Petr Viktorin added the comment:
New changeset f64c813de84011a84ca21d75a294861a9cc2dfdc by Petr Viktorin
(tzickel) in branch '2.7':
bpo-25083: Python can sometimes create incorrect .pyc files (GH-8449)
https://github.com/python/cpython/commit/f64c813de84011a84ca21d75a294861a9cc2dfdc
Petr Viktorin added the comment:
New changeset 9797b7ae4496627836c55333765e10201a9840e3 by Petr Viktorin (Berker
Peksag) in branch 'master':
bpo-26502: Implement FrameSummary.__len__() (GH-8632)
https://github.com/python/cpython/commit/9797b7ae4496627836c55333765e10201a9840e3
Change by Petr Viktorin :
--
stage: patch review -> resolved
status: pending -> closed
___
Python tracker
<https://bugs.python.org/issue6531>
___
___
Pyth
Petr Viktorin added the comment:
That's quite problematic, since then you're sharing a mutable object across
interpreters.
The user can store any attribute on module objects, including e.g. Python
functions that reference their original interpreter's global state, but become
callable
Petr Viktorin added the comment:
New changeset 7b41dbad78c6b03ca2f98800a92a1977d3946643 by Petr Viktorin (Marcel
Plch) in branch 'master':
bpo-34325: Skip zipfile test for large timestamps when filesystem don't support
them. (GH-8656)
https://github.com/python/cpython/commit
Change by Petr Viktorin :
--
nosy: +Dormouse759
___
Python tracker
<https://bugs.python.org/issue34325>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Petr Viktorin :
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue34325>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petr Viktorin added the comment:
PEP 489 (Multi-phase extension module initialization) makes it possible/easy to
unload/reimport extension modules, in the sense of destroying/recreating the
module object. The problem is that the modules needs to opt-in to supporting
this, which
Petr Viktorin added the comment:
New changeset 78c54de575fd121d91749c2316fef1949d76fb07 by Petr Viktorin (Miss
Islington (bot)) in branch '3.7':
bpo-33666: Add what's new entry for os.errno removal (GH-8497) (GH-8526)
https://github.com/python/cpython/commit
Petr Viktorin added the comment:
linux_distribution has beed deprecated for a while and has been removed in
GH-6871 (bpo-28167)
See https://pypi.org/project/distro for distro detection.
--
resolution: -> rejected
stage: patch review -> resolved
status: open -&g
Petr Viktorin added the comment:
If Debian's talloc is fine without this, maybe we can close the issue?
--
___
Python tracker
<https://bugs.python.org/issue27
Change by Petr Viktorin :
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue20177>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Petr Viktorin :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue23642>
___
___
Petr Viktorin added the comment:
The problem here is that tracing for STACKADJ prints out the top of the stack
*after* adjustment. This is OK for growing the stack, but not for shrinking it
(e.g. calling STACKADJ(-3) pops off three things at once, which can leave TOP
undefined when it's
Change by Petr Viktorin :
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue34113>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petr Viktorin added the comment:
New changeset 1d2dafa249c7fb34f3d24e7a77d1bea02907d92b by Petr Viktorin (INADA
Naoki) in branch 'master':
bpo-33666: Add what's new entry for os.errno removal (GH-#8497)
https://github.com/python/cpython/commit/1d2dafa249c7fb34f3d24e7a77d1bea02907d92b
Petr Viktorin added the comment:
Which third-party utilities support these? As I said, AFAIK `zip` on my system
does not.
I assume the loss of data is the reason we have an error now -- if that wasn't
a concern, zipfile could just silently bump the timestamp to 1980.
When the extensions
Petr Viktorin added the comment:
I'm not sure the extensions will solve this problem fully.
If an implementation that doesn't support these extensions, how does it handle
them?
For example, if Python 3.8 implements the extensions, I use py3.8 to create a
zipfile containing old timestamps
New submission from Petr Viktorin :
The ZIP format cannot handle times before 1980.
Issue6090 provided a nice error message for trying to add such files.
I'm seeing a system for reproducible builds that sets mtime to 1970 (zero UNIX
timestamp), resulting in files that Python can't package
Petr Viktorin added the comment:
> I didn't add Cython because it's not clear to me if it's useful for creating
> extension modules in a pythonesque language, or if it's also useful by it's
> own.
Cython only makes extensions for CPython, and uses CPython's runtime. But it
does
Petr Viktorin added the comment:
> Actually removing re._pattern_type, uuid._uuid_generate_time and some private
> names in the typing module broke several third-party projects.
Those have underscores; that explicitly marks them as private/use at your own
risk/will break in future ve
Petr Viktorin added the comment:
> Even if it is documented, arn't people know it by running their code on
> Python 3.7? How the document help them?
"What's new" is the right place to check if something breaks for you on Python
3.7. Let's make it useful.
> It's very
Petr Viktorin added the comment:
Nothing there strikes me to be as prevalent or as discoverable as os.errno.
--
___
Python tracker
<https://bugs.python.org/issue33
Change by Petr Viktorin <encu...@gmail.com>:
--
title: os.errno gone absent without official leave (AWOL) -> Document removal
of os.errno
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Petr Viktorin <encu...@gmail.com> added the comment:
I think this was closed prematurely.
> Projects that depend on it are incorrect and should be fixed.
That's definitely correct; no one here is arguing against it.
However, there are projects out there depending on it -- it wor
Petr Viktorin <encu...@gmail.com> added the comment:
New changeset 983c1ba94aef945386001932c5744f8ce9757fec by Petr Viktorin (Miss
Islington (bot)) in branch '3.7':
bpo-32374: Ignore Python-level exceptions in test_bad_traverse (GH-7145)
(GH-7150)
https://github.com/python/cpython/
Petr Viktorin <encu...@gmail.com> added the comment:
New changeset 08c5aca9d13b24b35faf89ebd26fc348ae1731b2 by Petr Viktorin (Marcel
Plch) in branch 'master':
bpo-32374: Ignore Python-level exceptions in test_bad_traverse (GH-7145)
https://github.com/python/cpython/
Petr Viktorin <encu...@gmail.com> added the comment:
> That's a weak test: if the script fails before calling
> spec.loader.create_module(), the test also pass. If the function raises an
> exception but don't crash, the test pass as well.
Marcel added PR 7145 for that --
Petr Viktorin <encu...@gmail.com> added the comment:
linux_distribution is removed in Python 3.8.
--
nosy: +petr.viktorin
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.
Petr Viktorin <encu...@gmail.com> added the comment:
Er, sorry, I meant in 3.8.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Petr Viktorin <encu...@gmail.com> added the comment:
Er, sorry, I meant in 3.8.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Petr Viktorin <encu...@gmail.com> added the comment:
linux_distribution is removed in Python 3.7.
Closing.
--
nosy: +petr.viktorin
resolution: -> out of date
stage: patch review -> resolved
status: open -> closed
___
Pyth
Petr Viktorin <encu...@gmail.com> added the comment:
linux_distribution is removed in Python 3.7.
Closing.
--
nosy: +petr.viktorin
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker <rep.
Petr Viktorin <encu...@gmail.com> added the comment:
> That's a weak test: if the script fails before calling
> spec.loader.create_module(), the test also pass. If the function raises an
> exception but don't crash, the test pass as well.
That's a good argument, thanks.
Marcel,
Petr Viktorin <encu...@gmail.com> added the comment:
> PTHREAD_KEY_T_IS_COMPATIBLE_WITH_INT is defined on most (pthread) platforms,
> no?
> I propose to cast pthread_key_create() result to int, but only define
> PyThread_create_key() in Pytho
Change by Petr Viktorin <encu...@gmail.com>:
--
nosy: +petr.viktorin
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33468>
___
_
Petr Viktorin <encu...@gmail.com> added the comment:
pthread is not generally compatible with int, so it can't be used with Python
2's API.
This was changed in py3 with PEP 539, which however makes it so that the old
TLS API is only available if PTHREAD_KEY_T_IS_COMPATIBLE_WI
Petr Viktorin <encu...@gmail.com> added the comment:
Thanks for closing that one.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Petr Viktorin <encu...@gmail.com> added the comment:
For the record, I opened an issue on `distro` about the vicious circle of
distro detection instead of feature detection:
https://github.com/nir0s/distro/issues/221
--
___
Python tracke
Petr Viktorin <encu...@gmail.com> added the comment:
I understand that's what distro (https://github.com/nir0s/distro) is based on
-- but a lot of complexity is required on top of that.
--
___
Python tracker <rep...@bugs.python.or
Petr Viktorin <encu...@gmail.com> added the comment:
I withdraw the patch (and I should have done that years ago). Nowadays,
hopefully Requests does the right thing.
--
resolution: -> out of date
stage: test needed -> resolved
status: op
Petr Viktorin <encu...@gmail.com> added the comment:
platform.linux_distribution is removed from Python 3.8. Thanks for everyone
involved!
If there are any complaints or other fallout you don't want to deal with, feel
free to point people to me :)
--
resolution: -> fi
Petr Viktorin <encu...@gmail.com> added the comment:
New changeset 8b94b41ab7b12f745dea744e8940631318816935 by Petr Viktorin in
branch 'master':
bpo-28167: Remove platform.linux_distribution (GH-6871)
https://github.com/python/cpython/commit/8b94b41ab7b12f745dea744e8940631318
Petr Viktorin <encu...@gmail.com> added the comment:
New changeset e4cd12d3d338e691ab0c12a2f2f90422eee04bda by Petr Viktorin
(Stéphane Wirtel) in branch '3.6':
[3.6] bpo-33503: Fix the broken pypi link in the source and the documentation
(GH-6814) (GH-6885)
https://github.com/python/c
Petr Viktorin <encu...@gmail.com> added the comment:
New changeset 51b2f6d3a3d6433b832f30d03382653f92a31cdf by Petr Viktorin (Miss
Islington (bot)) in branch '3.7':
bpo-33503: Fix the broken pypi link in the source and the documentation
(GH-6814) (GH-6872)
https://github.com/python/c
Change by Petr Viktorin <encu...@gmail.com>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33537>
___
__
Petr Viktorin <encu...@gmail.com> added the comment:
Is "package.module:namespace.attribute" worth supporting? I guess it isn't, at
least for now. So Serhyi's patch will work.
--
___
Python tracker <rep...@bugs.python.org>
&l
Change by Petr Viktorin <encu...@gmail.com>:
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Change by Petr Viktorin <encu...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Petr Viktorin <encu...@gmail.com> added the comment:
Marc-Andre, if you agree the function can be removed in 3.8.
This is tracked in https://bugs.python.org/issue28167
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pytho
Petr Viktorin <encu...@gmail.com> added the comment:
Marc-Andre, I opened a PR to remove platform.linux_distribution() in Python 3.8.
How do you feel about this?
--
nosy: +lemburg
___
Python tracker <rep...@bugs.python.org>
<https://
Change by Petr Viktorin <encu...@gmail.com>:
--
pull_requests: +6545
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28167>
___
_
Petr Viktorin <encu...@gmail.com> added the comment:
New changeset e618e96581a711f2bc4f9bbcff6069bea15f0177 by Petr Viktorin in
branch '3.6':
bpo-28167: bump platform.linux_distribution removal to 3.8 (GH-6864)
https://github.com/python/cpython/commit/e618e96581a711f2bc4f9bbcff6069bea1
Petr Viktorin <encu...@gmail.com> added the comment:
New changeset f4fdb619ddb5b00178c79c2b90adc45075b5f17d by Petr Viktorin (Miss
Islington (bot)) in branch '3.7':
bpo-28167: bump platform.linux_distribution removal to 3.8 (GH-6669) (GH-6862)
https://github.com/python/cpython/
Change by Petr Viktorin <encu...@gmail.com>:
--
pull_requests: +6538
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28167>
___
_
Petr Viktorin <encu...@gmail.com> added the comment:
Python's deprecation process takes several years, but linux_distribution is
actually nearing the end of it. It is planned to be removed.
Your improvement is great, but at this point, it is more similar to adding a
new f
Petr Viktorin <encu...@gmail.com> added the comment:
New changeset 9eb40bc38de83e6ad3fad1931bba1cd36ae88c24 by Petr Viktorin
(Matthias Bussonnier) in branch 'master':
bpo-28167: bump platform.linux_distribution removal to 3.8 (GH-6669)
https://github.com/python/cpython/
Petr Viktorin <encu...@gmail.com> added the comment:
I talked to Ned, the release manager for 3.7.
It's too late to remove this in 3.7, so I'll update the docs and make the
deprecation notice more current/useful, and link to the distro l
Petr Viktorin <encu...@gmail.com> added the comment:
Oh, and there's a long discussion on the deprecation here:
https://bugs.python.org/issue1322
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Petr Viktorin <encu...@gmail.com> added the comment:
linux_distribution is deprecated since 3.5, so I don't think it makes sense to
modify it.
(see
https://docs.python.org/3/library/platform.html#platform.linux_distribution)
Can you use a third-party package instead, e.g. distro
Petr Viktorin <encu...@gmail.com> added the comment:
Not immediately, but it is on my TODO list.
If anyone wants to tackle it in the mean time, I'd be happy to answer any
questions
--
___
Python tracker <rep...@bugs.python.or
Petr Viktorin <encu...@gmail.com> added the comment:
An option would be to use a colon to separate the module(s) from the
attribute(s). The "inspect" module CLI does this, for example:
https://docs.python.org/3/library/inspect.html#command-line-interface
$ py
Change by Petr Viktorin <encu...@gmail.com>:
--
nosy: +Dormouse759, encukou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Petr Viktorin <encu...@gmail.com>:
--
nosy: +Dormouse759
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue15727>
___
_
Petr Viktorin <encu...@gmail.com> added the comment:
Well, PEP 489 basically punts this to module authors: generally, C globals are
bad, but if you do have global state, please manage it, keeping in mind that
multiple module objects can be created from the extension.
That's required t
Petr Viktorin <encu...@gmail.com> added the comment:
This is a duplicate of https://bugs.python.org/issue31474
which was fixed in https://github.com/python/cpython/pull/3581
It should be included in the next Python 2.7.x release.
--
nosy: +e
Petr Viktorin <encu...@gmail.com> added the comment:
WIP pull request: https://github.com/python/cpython/pull/5141
(I'll not get back to this for a few days, sadly.)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Petr Viktorin <encu...@gmail.com>:
--
pull_requests: +5000
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Petr Viktorin <encu...@gmail.com> added the comment:
Gah! The more I look into locks & forks ... the more I learn, to put it mildly.
Instead of piling on workarounds, I'll try my hand at using native thread-local
storage for pthread, and avoid the locking altogether.
Hopefully tha
Petr Viktorin <encu...@gmail.com> added the comment:
I'm a bit out of my depth here. Victor, could you chime in?
The problem with Harris' patch is that, once fork() is protected by the thread
lock, acquiring that lock (by e.g. calling `PyGILState_GetThisThreadState`)
from an `atfork` h
Change by Petr Viktorin <encu...@gmail.com>:
--
nosy: +Dormouse759, encukou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Petr Viktorin <encu...@gmail.com> added the comment:
This is caused by Brailcom's Speech Dispatcher, whose config script ran
optparse on import. Apparently it was fixed in their version 0.8.6.
Some references:
https://github.com/brailcom/speechd/commit/1808ea1a6e840951ffde61e5a6476ccfc1
Petr Viktorin <encu...@gmail.com> added the comment:
Marcel, could you look into this?
--
nosy: +Dormouse759
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Petr Viktorin <encu...@gmail.com>:
After the create phase of multiphase initialization, the per-module state is
NULL and the module object is reachable by the garbage collector. Between the
create and exec phases, Python code is run and garbage collection can be
tri
Change by Petr Viktorin <encu...@gmail.com>:
--
nosy: +Dormouse759, encukou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue6531>
___
Change by Petr Viktorin <encu...@gmail.com>:
--
pull_requests: +4296
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue19976>
___
_
Change by Petr Viktorin <encu...@gmail.com>:
--
keywords: +patch
pull_requests: +4295
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Petr Viktorin <encu...@gmail.com>:
--
pull_requests: +4297
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue26179>
___
_
Petr Viktorin <encu...@gmail.com> added the comment:
Since the macro has a public name and is used in the wild outside CPython, I'll
go ahead and submit a pull request documenting it.
--
___
Python tracker <rep...@bugs.python.or
Petr Viktorin <encu...@gmail.com> added the comment:
When you destroy a subinterpreter before Py_Finalize is called, Python can't
start calling its atexit callbacks – they no longer have a subinterpreter to
run in.
Therefore I think callbacks for a particular subinterpreter should be
Change by Petr Viktorin <encu...@gmail.com>:
--
pull_requests: +4291
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31338>
___
_
Petr Viktorin <encu...@gmail.com> added the comment:
I'm not sure where the concept of "main subinterpreter" comes in, with respect
to this issue.
I thnik the issue of atexit callbacks could be solved by something like keeping
info about each callback's subinterprete
Petr Viktorin <encu...@gmail.com> added the comment:
I don't have a reason to think Py_Finalize is not *destroying* the other
subinterpreters. But it's not calling their atexit callbacks.
(Is there any reason Py_Finalize couldn't switch to the main interpreter
itself? Assuming it'
Petr Viktorin <encu...@gmail.com> added the comment:
tzickel, could you sign the CLA? It will formally allow PSF to distribute your
patch with Python. (You retain the copyright.) See the dev guide for
instructions: https://docs.python.org/devguide/pullrequest.html#cla
I can't do that f
Petr Viktorin <encu...@gmail.com> added the comment:
FWIW, Marcel is an intern in my team, tasked to learn CPython internals by
trying to improve subinterpreter support. If I don't comment on his issues it's
because we discussed privately befo
Petr Viktorin <encu...@gmail.com> added the comment:
Both tp_richcompare and PyObject_RichCompareBool have op as the last argument:
https://docs.python.org/3/c-api/object.html#c.PyObject_RichCompareBool
https://docs.python.org/3/c-api/typeobj.html?highlight=tp_richc
Petr Viktorin added the comment:
Alright, that makes sense. Thanks for the feedback!
Please give us some time for an updated proposal/implementation. I'm going on
vacation, so expect about a week.
--
___
Python tracker <rep...@bugs.python.org>
Petr Viktorin added the comment:
Again, what is the use case? That's a real question, I'm not saying it to
dismiss your ideas or points of view. It would be very much easier to think
about a concrete use case, rather than making a general system for the sake of
how easy it is implementation
Petr Viktorin added the comment:
Do we have a use case for this?
I'd rather avoid making it easy to do the wrong thing, unless it's needed.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Petr Viktorin added the comment:
The test is already skipped if the user is root. It verifies that process 1
can't be touched by non-root users.
The problem is an assumption that process with PID 1 belongs to root. That
assumption isn't true in containers: PID 1 is whatever the container
Changes by Petr Viktorin <encu...@gmail.com>:
--
nosy: +encukou
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26415>
___
__
Petr Viktorin added the comment:
This is now waiting to be added to the PEPs repo:
https://github.com/python/peps/pull/266
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Petr Viktorin added the comment:
Adding Stefan from the Cython project.
Stefan, is this something you'd want to use?
(It does require PEP 489 multi-phase initialization, so I assume it would need
extra #ifdefs in Cythonized code for Python 3.5+ or 3.7+)
--
nosy: +scoder
Petr Viktorin added the comment:
It's part of a larger effort to bring the capabilities of extension modules up
to par with Python ones. For example, it's one less surprise you'd get when you
Cythonize a module. And it's not only for stdlib modules – it's for any
extension module.
I'd
Changes by Petr Viktorin <encu...@gmail.com>:
--
nosy: +encukou, ncoghlan
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30403>
___
Petr Viktorin added the comment:
Here is a proof of concept patch from Jaroslav Škarvada. It fixes the problem
by holding the mutex used for PyThread_create_key while forking.
To make it more than PoC it needs adding _PyThread_AcquireKeyLock and
_ReleaseKeyLock (similar
Petr Viktorin added the comment:
In Fedora also want to stay close to upstream: every downstream patch is like
an open issue, something we'd like to merge given enough time and people. But,
for a problem that:
- is fixed in the latest version (3.6)
- is getting a test to not happen again
701 - 800 of 906 matches
Mail list logo
