Mark Dickinson added the comment:
Mark, what was the use case you found?
It's essentially an IdentityDict, though I've found other more specific
transforms useful.
I was writing a tool to find reference cycles between Python objects (we have a
customer application that's working in a
Charles-François Natali added the comment:
Hum...
Correct me if I'm wrong, but destroying the thread state of daemon threads
while they're running is really a bad idea in fact: for example, if
warnings are now emitted for unclosed file objects, this means that the
file object, and all associated
Christian Heimes added the comment:
I still like the idea, too. It's more elegant, easier to maintain and gives a
speedup, too.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19230
___
Charles-François Natali added the comment:
Here's a patch.
--
Added file: http://bugs.python.org/file33113/makefile_ast_h.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19965
___
Changes by Vajrasky Kok sky@speaklikeaking.com:
Added file:
http://bugs.python.org/file33115/fix_typo_agin_and_immediatly_python33.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19970
___
New submission from Vajrasky Kok:
ethan@amiau:~/Documents/code/python/cpython3.4$ grep -R immediatly *
Doc/library/asyncio-protocol.rst::meth:`Transport.close` can be called
immediatly after
Lib/test/test_signal.py:# unblock the pending signal calls
immediatly the signal handler
STINNER Victor added the comment:
It's actually fairly easy to write a short crasher launching a deamon
thread reading from e.g. /dev/zero in loop, with the main thread exiting
right in the middle.
I'm unable to write such crasher, can you please give an example? Are you able
to crash Python
STINNER Victor added the comment:
Updated patch for Serhiy's remark (replace ValueError with OverflowError).
--
Added file: http://bugs.python.org/file33116/bytes_fromformat_c-2.patch
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
LGTM.
--
assignee: - neologix
stage: - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19965
___
Serhiy Storchaka added the comment:
LGTM.
--
assignee: - haypo
stage: - commit review
type: - behavior
versions: +Python 2.7, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19969
New submission from Vajrasky Kok:
I was reading the documentation about asyncio. Here is the introduction
paragraph:
Doc/library/asyncio.rst
===
This module provides infrastructure for writing single-threaded concurrent
code using coroutines, multiplexing I/O access over
STINNER Victor added the comment:
I agree to drop references to the Tulip name. Thanks for your patch.
changeset: 87927:10378199e37b
tag: tip
user:Victor Stinner victor.stin...@gmail.com
date:Fri Dec 13 10:57:04 2013 +0100
files: Doc/library/asyncio-sync.rst
Serhiy Storchaka added the comment:
The disadvantage of 'H' is that it never raises OverflowError.
The simplest solution is just revert a part of the patch for issue15989.
--
assignee: - serhiy.storchaka
versions: -Python 3.2, Python 3.3, Python 3.5
Roundup Robot added the comment:
New changeset 08c95dd68cfc by Serhiy Storchaka in branch '3.3':
Issue #17919: select.poll.poll() again works with poll.POLLNVAL on AIX.
http://hg.python.org/cpython/rev/08c95dd68cfc
New changeset e78743e03c8f by Serhiy Storchaka in branch 'default':
Issue
STINNER Victor added the comment:
The disadvantage of 'H' is that it never raises OverflowError.
The correct fix is to write a new parser just for this function.
See for example uint_converter() in Modules/zlibmodule.c. I would prefer to add
such new parser to Python/getargs.c directly, but
New submission from Stefan Krah:
Hi Alexandre, the following leaks appear after 64c6d52793be. I'm
not sure yet if they're caused or just exposed by the changeset.
Code:
==
import sys
import pickle
sys.exit(0)
==
==8118== 864 (192 direct, 672 indirect) bytes in 3
Roundup Robot added the comment:
New changeset 5d078b0bae75 by Victor Stinner in branch 'default':
Issue #19787: PyThread_set_key_value() now always set the value
http://hg.python.org/cpython/rev/5d078b0bae75
--
___
Python tracker
Roundup Robot added the comment:
New changeset 5d078b0bae75 by Victor Stinner in branch 'default':
Issue #19787: PyThread_set_key_value() now always set the value
http://hg.python.org/cpython/rev/5d078b0bae75
--
nosy: +python-dev
___
Python tracker
Roundup Robot added the comment:
New changeset 5d078b0bae75 by Victor Stinner in branch 'default':
Issue #19787: PyThread_set_key_value() now always set the value
http://hg.python.org/cpython/rev/5d078b0bae75
--
nosy: +python-dev
___
Python tracker
Claudiu.Popa added the comment:
Hello!
Here's a patch. Currently it lacks doc updates, but if the solution is okay,
then I could provide them.
--
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file33118/inspect_getdoc.patch
STINNER Victor added the comment:
The simplest solution is just revert a part of the patch for issue15989.
The revert reintroduced the integer overflow:
self-ufds[i].events = (short)PyLong_AsLong(value);
--
___
Python tracker
STINNER Victor added the comment:
See also issue #15751.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10915
___
___
Python-bugs-list mailing
STINNER Victor added the comment:
FYI I fixed a weird behaviour of the PyThread_set_key_value() function. The
change has indirectly on impact on test.support.run_in_subinterp():
The impact was a bug. I reverted my changeset and pushed a new changeset which
leaves
STINNER Victor added the comment:
I'm closing this issue as invalid for the same reason than I closed the issue
#19846:
http://bugs.python.org/issue19846#msg205675
--
resolution: - invalid
status: open - closed
___
Python tracker
Claudiu.Popa added the comment:
Serhiy, what's the status for this? Should this be targeted for 3.5?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19385
___
Stefan Krah added the comment:
This patch fixes the leak, but needs review (I do not know the _pickle module
very well).
--
keywords: +patch
Added file: http://bugs.python.org/file33119/issue19972.patch
___
Python tracker rep...@bugs.python.org
Changes by Stefan Krah stefan-use...@bytereef.org:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19972
___
___
Serhiy Storchaka added the comment:
Here is a patch which uses special converter.
--
versions: +Python 3.3
Added file: http://bugs.python.org/file33120/poll_events_mask_overflow.patch
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
According to the example in the PEP 3121, issue19972.patch is not needed.
In practice, I don't see in PyImport_Cleanup() where tp_clear is called. This
function calls:
_PyModule_Clear(mod);
Py_DECREF(mod);
--
nosy: +haypo
STINNER Victor added the comment:
With poll_events_mask_overflow.patch, the following hack can maybe be removed?
/* The 0x is a workaround for AIX. 'revents'
is a 16-bit short, and IBM assigned POLLNVAL
to be 0x8000, so the conversion to int
STINNER Victor added the comment:
+if (uval USHRT_MAX) {
+PyErr_SetString(PyExc_OverflowError,
+Python int too large for C unsigned int);
The message should be C unsigned short.
The unit tests don't check that USHRT_MAX value is accepted.
--
Sworddragon added the comment:
The fact that write() uses sys.getfilesystemencoding() is either
a defect or a bad design (I leave the decision to you).
I have good news for you. write() does not cal sys.getfilesystemencoding(),
because the encoding is set at the time the file is opened.
Stefan Krah added the comment:
See #11826 for more details where the freefunc is called. Perhaps the.
docs or the PEP need an update.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19972
Serhiy Storchaka added the comment:
Regarding the first issue, I don't believe that the result will be as
readable (but I agree with you that it will be better).
Yes, perhaps performance of the dbm.dumb module is not worst this cost. Are you
have any benchmarking results?
The patch LGTM.
Changes by STINNER Victor victor.stin...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19787
___
Stefan Krah added the comment:
The docs say:
inquiry m_clear
A clear function to call during GC clearing of the module object, or NULL
if not needed.
freefunc m_free
A function to call during deallocation of the module object, or NULL if not
needed.
So I assume that GC clearing is
New submission from Larry Hastings:
Does it make sense to finally deprecate pyio, so we can eventually delete it?
--
messages: 206060
nosy: larry
priority: normal
severity: normal
status: open
title: Deprecate pyio
versions: Python 3.5
___
Python
STINNER Victor added the comment:
I like the _pyio module! It's useful to test some new features.
For example, I'm using it to identify where a file is destroyed without being
closed (get where the object was created):
https://bitbucket.org/haypo/misc/src/tip/python/res_warn.py
I didn't find
Changes by Larry Hastings la...@hastings.org:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19973
___
___
Python-bugs-list
Roundup Robot added the comment:
New changeset 68e0dbc492de by Victor Stinner in branch '3.3':
Issue #19969: PyBytes_FromFormatV() now raises an OverflowError if %c
http://hg.python.org/cpython/rev/68e0dbc492de
New changeset 969e38b2f336 by Victor Stinner in branch 'default':
(Merge 3.3) Issue
Antoine Pitrou added the comment:
Larry, I think Brett won't like you.
(have you read PEP 399?)
--
nosy: +brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19973
___
Larry Hastings added the comment:
I hadn't! I guess we're signed up to maintain two implementations of a bunch
of things for eternity, then.
--
resolution: - wont fix
stage: - committed/rejected
status: open - closed
type: - enhancement
___
New submission from Antony Mayi:
tarfile.py compared to GNU tar doesn't overwrite existing symlink with
directory of same name if such directory exists in the extracted tarball.
--
components: Library (Lib)
messages: 206066
nosy: antonymayi
priority: normal
severity: normal
status:
Larry Hastings added the comment:
The fact that write() - open() relies on sys.getfilesystemencoding()
(respectively locale.getpreferredencoding()) at default as encoding is
either a defect or a bad design (I leave the decision to you).
Or am I overlooking something?
First, you should
Antoine Pitrou added the comment:
Yeah, it sounds logical for m_free to do the clearing too (same as tp_dealloc
vs. tp_clear).
Note that the PEP 3121 scheme turns out to be problematic for proper resource
management: https://mail.python.org/pipermail/python-dev/2013-August/127862.html
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +lars.gustaebel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19974
___
___
Sworddragon added the comment:
Instead, open() determines the default encoding by calling the same function
that's used to initialize Py_FileSystemDefaultEncoding: get_locale_encoding()
in Python/pythonrun.c. Which on POSIX systems calls the POSIX function
nl_langinfo().
open() will use
Claudiu.Popa added the comment:
Here's a benchmark:
- with current patch:
# ./python -S -m timeit -n 1 -s 'import dbm.dumb as dbm;
d=dbm.open(x.dat, c);d.close()' 'try:' ' len(d)' 'except OSError:' ' pass'
1 loops, best of 3: 1.78 usec per loop
- using
try:
return
Stefan Behnel added the comment:
I agree that this is an improvement, but isn't it a bit late for removing a
public field from a public header file in 3.4, without any preceding
deprecation?
--
nosy: +scoder
___
Python tracker
Nick Coghlan added the comment:
There's an alternative to trying to force a different encoding for the
standard streams when the OS claims ASCII as the OS encoding: we can
default to surrogateescape as the error handler, on the assumption that
whatever the *real* OS encoding is, it definitely
Nick Coghlan added the comment:
Unfortunately Stefan has a point - what's the migration path for C API
users that were relying on that struct field?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14432
Reuben Garrett added the comment:
On Sat, Dec 7, 2013 at 1:35 PM, Gregory P. Smith rep...@bugs.python.orgwrote:
I fixed this in 3.3 and 3.4 several weeks ago.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19901
Reuben Garrett added the comment:
On Sat, Dec 7, 2013 at 1:35 PM, Gregory P. Smith rep...@bugs.python.org
wrote:
I fixed this in 3.3 and 3.4 several weeks ago.
Sorry for the duplicate message a few moments ago … fat-fingered my send
button.
So, has the fix just not reached the Portage tree
STINNER Victor added the comment:
I agree that this is an improvement, but isn't it a bit late for removing a
public field from a public header file in 3.4, without any preceding
deprecation?
The header is not public, it is private. The structure in not
documented (in Doc/c-api/*.rst).
STINNER Victor added the comment:
2013/12/13 Victor Stinner victor.stin...@gmail.com:
The header is not public, it is private.
Hum, I'm not clear. frameobject.h is not included in Python.h, so the
classic #include Python.h doesn't give you access to PyFrameObject
structure. You have to add a
Roundup Robot added the comment:
New changeset 278dd7eb2f2b by Victor Stinner in branch 'default':
Issue #14432: Document the removal of the PyFrameObject.f_tstate field
http://hg.python.org/cpython/rev/278dd7eb2f2b
--
___
Python tracker
Stefan Behnel added the comment:
what's the migration path for C API users that were relying on that struct
field?
Depends on how you use it, I guess. In many cases (at least for Cython and
likely some other low-level tools), it could be as simple as
#if PY_VERSION_HEX 0x030400B2
//
Antoine Pitrou added the comment:
All
definitions in this header are also surrounded by #ifndef
Py_LIMITED_API ... #endif, so the fields are not part of the stable
API.
Stable ABI, not API.
That said, I agree the field should have been private anyway.
--
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: -eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18986
___
___
Python-bugs-list
STINNER Victor added the comment:
Depends on how you use it, I guess. In many cases (at least for Cython and
likely some other low-level tools), it could be as simple as
#if PY_VERSION_HEX 0x030400B2
// set f_tstate here
#endif
Why would you set f_tstate field? Frame constructor
Brett Cannon added the comment:
Two things. One, no one has shown a startup improvement using the official
startup benchmarks (either normal or nosite). That needs to be established to
show an actual benefit.
Second, PEP 399 requires the pure Python version stick around, else you need to
STINNER Victor added the comment:
Second, PEP 399 requires the pure Python version stick around, else you need
to request an exception to drop keyword.py from python-dev.
I don't understand the purpose of providing a Python implementation of the
keyword module. If you look at the current
Brett Cannon added the comment:
Only if we keep the C version around do we have to care about two versions. =)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19973
___
Brett Cannon added the comment:
You're right, the regeneration might be specific to CPython (although maybe it
should work from Grammar/Grammar instead?), but that's just creating the Python
file which we check into the stdlib, so any VM can use it, they just can't
recreate it (which is fine
STINNER Victor added the comment:
It was easy to fix the issue on Python 3.3 (there are already unit tests on
PyBytes_FromFormatV).
I prefer to leave Python 2.7 with it's current behaviour because applications
running on Python 2.7 may be old and might be rely on the integer overflow.
Stefan Behnel added the comment:
frameobject.h is not included in Python.h, so the
classic #include Python.h doesn't give you access to PyFrameObject
structure. You have to add a second #include frameobject.h.
Ah, right. I keep misremembering that, because in order to do anything
Larry Hastings added the comment:
We tried a pure python implementation of io once. Didn't go so well. :p
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19973
___
STINNER Victor added the comment:
We tried a pure python implementation of io once. Didn't go so well. :p
It is _pyio.
Note: _pyio is not 100% *pure* Python, it relies on FileIO which is implemented
in C. I always found this surprising. One day I will maybe rewrite it using
os.read() and
Antoine Pitrou added the comment:
Note: _pyio is not 100% *pure* Python, it relies on FileIO which is
implemented in C. I always found this surprising. One day I will maybe
rewrite it using os.read() and os.write() :-)
Then you need to rewrite os.read() and os.write() in pure Python!
Brett Cannon added the comment:
Key point is it didn't go so well **for us**; works fine for PyPy.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19973
___
New submission from Claudiu.Popa:
The attached patch removes three unused imports in webbrowser module.
--
components: Library (Lib)
files: webbrowser_unused_imports.patch
keywords: patch
messages: 206091
nosy: Claudiu.Popa, georg.brandl
priority: normal
severity: normal
status: open
Amaury Forgeot d'Arc added the comment:
PyPy also has a C-translated version of the io module.
It's a bit faster I think, but more importantly it has correct behavior with
signals and other asynchronous errors.
_pyio.py can be stopped in the middle of any function, and is not completely
New submission from Stefan Krah:
I was just reading the _pickle sources and it appears that AC does not
generate a second arg for METH_NOARGS functions:
#define _PICKLE_PICKLERMEMOPROXY_CLEAR_METHODDEF\
{clear, (PyCFunction)_pickle_PicklerMemoProxy_clear, METH_NOARGS,
Arfrever Frehtes Taifersar Arahesis added the comment:
IMHO it is a bug fix, not a new feature, and could be applied in 3.3 and 3.4.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19385
STINNER Victor added the comment:
I prefer to omit the unused parameter, even if NULL *is* passed to the function.
If you prefer to add the unused parameter, what do you propose to avoid
compiler warnings if unused parameters are checked?
--
nosy: +haypo
Larry Hastings added the comment:
Stefan is right. I'll fix Clinic.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19976
___
___
Brett Cannon added the comment:
Then if Jython and IronPython are not using _pyio we can probably remove the
file.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19973
___
Sworddragon added the comment:
By the way I have found a valid use case for LANG=C. udev and Upstart are not
setting LANG which will result in the ascii encoding for invoked Python
scripts. This could be a problem since these applications are commonly dealing
with non-ascii filesystems.
Antoine Pitrou added the comment:
Then if Jython and IronPython are not using _pyio we can probably remove the
file.
_pyio can be useful for prototyping. Whether or not other
implementations use it is quite irrelevant IMO.
--
___
Python tracker
Larry Hastings added the comment:
Yes, but it's a small utility. If it costs nothing to maintain _pyio then
okay. But if we're spending measurable time on it but it's only a nice-to-have
then we should drop it.
(Full disclosure: I have no idea how much work goes into maintaining _pyio.)
STINNER Victor added the comment:
By the way, Java behaves as Python: with LANG=C, Java uses ASCII:
http://stackoverflow.com/questions/13415975/cant-read-utf-8-filenames-when-launched-as-an-upstart-service
udev and Upstart are not setting LANG
So it's an issue in udev and Upstart. See for
Stefan Krah added the comment:
STINNER Victor rep...@bugs.python.org wrote:
If you prefer to add the unused parameter, what do you propose to avoid
compiler warnings if unused parameters are checked?
This works quite portably in _decimal (I don't get warnings from gcc, icc,
suncc, Visual
Larry Hastings added the comment:
A quick google suggests:
http://sourcefrog.net/weblog/software/languages/C/unused.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19976
___
Larry Hastings added the comment:
To do it properly with Clang requires a pragma:
http://stackoverflow.com/questions/3417837/what-is-the-best-way-to-supress-unused-variable-x-warning/18724213#18724213
What a mess.
--
___
Python tracker
STINNER Victor added the comment:
We could call the macro PY_UNUSED or something.
I would prefer Py_UNUSED name. This sounds like a nice addition to
Include/pymacros.h.
In C++, you can omit the parameter name, so the macro should take the parameter
name: Py_UNUSED(name). Example:
int
Sworddragon added the comment:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1235483
After opening many hundred tickets I would say: With luck this ticket will get
a response within the next year. But in the worst case it will be simply
refused.
I found examples using LANG=$LANG
Stefan Krah added the comment:
Stefan Krah rep...@bugs.python.org wrote:
The macro I posted really works on all obscure buildbot platforms.
N.B. clang also defines __GNUC__, as does the intel compiler.
--
___
Python tracker rep...@bugs.python.org
Stefan Krah added the comment:
Larry Hastings rep...@bugs.python.org wrote:
To do it properly with Clang requires a pragma:
Hmm. I just tested and clang warns with -Wall -W, but does not warn if
__attribute__((unused)) is present.
The macro I posted really works on all obscure buildbot
Toshio Kuratomi added the comment:
It's not a bug for upstart, systemd, sysvinit, cron, etc to use LANG=C. The
POSIX locale is the only locale guaranteed to exist on a system. Therefore
these low level services should be using LANG=C. Embedded systems, thin
clients, and other low memory or
Stefan Krah added the comment:
STINNER Victor rep...@bugs.python.org wrote:
I would prefer Py_UNUSED name. This sounds like a nice addition to
Include/pymacros.h.
Yes, Py_UNUSED is nicer.
--
___
Python tracker rep...@bugs.python.org
New submission from STINNER Victor:
When LANG=C is used to get the english language (which is a mistake, LC_CTYPE=C
should be used instead) or when Python is started with an empty environment (no
environment variable), Python gets the POSIX locale (aka C locale) for the
LC_CTYPE (encoding)
STINNER Victor added the comment:
I created the issue #19977 as a follow up of this one: Use surrogateescape
error handler for sys.stdout on UNIX for the C locale.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19847
STINNER Victor added the comment:
I created the issue #19977 as a follow up of this one: Use surrogateescape
error handler for sys.stdout on UNIX for the C locale.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19846
STINNER Victor added the comment:
Oh, in fact, sys.stdin is also modified by the patch (as I expected).
--
title: Use surrogateescape error handler for sys.stdout on UNIX for the C
locale - Use surrogateescape error handler for sys.stdin and sys.stdout on
UNIX for the C locale
Brett Cannon added the comment:
Created http://bugs.python.org/issue19978 to track using runpy.run_path in 3.5.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19946
New submission from Brett Cannon:
Once the 'target' parameter for runpy.run_path lands then multiprocessing.spawn
should be updated to use it.
--
components: Library (Lib)
messages: 206117
nosy: brett.cannon, jnoller, ncoghlan, sbt
priority: normal
severity: normal
stage: test needed
STINNER Victor added the comment:
I propose to modify the error handler, the encoding cannot be modified. See my
following message explaining why it's not possible to change the encoding:
http://bugs.python.org/issue19846#msg205675
--
___
Python
Roundup Robot added the comment:
New changeset cea42629ddf5 by Brett Cannon in branch 'default':
Issue #19946: Raise ImportError when the main module cannot be found
http://hg.python.org/cpython/rev/cea42629ddf5
--
nosy: +python-dev
___
Python
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19977
___
___
Olivier Grisel added the comment:
Why has this issue been closed? Won't the spawn and forkserver mode work in
Python 3.4 for Python program started by a Python script (which is probably the
majority of programs written in Python under unix)?
Is there any reason not to use the
1 - 100 of 161 matches
Mail list logo
