[issue15822] Python 3.3 creates lib2to3 grammar in wrong order
Tomi Pieviläinen added the comment: Platform: RHEL 6.3 x86_64. 0. (remove old python 3 install, though this doesn't change anything) 1. Unpack 3.3rc1 source, cd Python-3.3.0rc1/ 2. ./configure; make 3. sudo make install 4. ls -ltc --full-time /usr/local/lib/python3.3/lib2to3/ This shows that Grammar.txt is just a tiny bit newer than the pickle. To produce the SandboxViolation: 1. curl -O https://raw.github.com/pypa/virtualenv/master/virtualenv.py 2. python3.3 virtualenv.py my_new_env or alternatively use distribute to install anything with the easy_install command. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15822] Python 3.3 creates lib2to3 grammar in wrong order
Arfrever Frehtes Taifersar Arahesis added the comment: This issue can be easily reproduced on filesystems with nanosecond precision (e.g. ext4). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15822] Python 3.3 creates lib2to3 grammar in wrong order
Tomi Pieviläinen added the comment: Ah, sorry, forgot to add that info. I also am running ext4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15822] Python 3.3 creates lib2to3 grammar in wrong order
Arfrever Frehtes Taifersar Arahesis added the comment: `make install DESTDIR=/some/temporary/path` can be used to avoid affecting installed version of Python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15676] mmap: add empty file check prior to offset check
Changes by Berker Peksag berker.pek...@gmail.com: -- versions: -Python 3.1, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15676 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
New submission from Mark Tolonen:
I built a C extension using SWIG for both Python 3.2 and Python 3.3. The
Python file supplying class proxies uses imp.load_module and fails with the
following traceback on 3.3.0rc1, but works on 3.2.3:
Traceback (most recent call last):
File stdin, line 1, in module
File .\Widget.py, line 26, in module
_Widget = swig_import_helper()
File .\Widget.py, line 22, in swig_import_helper
_mod = imp.load_module('_Widget', fp, pathname, description)
File D:\dev\python33\lib\imp.py, line 171, in load_module
raise ImportError(msg, name=name)
ImportError: Don't know how to import _Widget (type code 3
It looks like imp.py is new in Python 3.3, and imp.load_module no longer
supports the C_EXTENSION type. It looks like a regression.
To reproduce, I was able to run the following lines with the .pyd file in the
current directory:
import imp
fp, pathname, description = imp.find_module('_Widget')
imp.load_module('_Widget', fp, pathname, description)
Nit: Also note the missing final ')' in the ImportError message.
--
components: Library (Lib)
messages: 169506
nosy: metolone
priority: normal
severity: normal
status: open
title: imp.load_module doesn't support C_EXTENSION type
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15828
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15340] OSError with import random when /dev/urandom doesn't exist (regression from 2.6)
The Written Word added the comment: Actually, this regression appeared after the Hash Randomization patches prior to 2.6.8, 2.7.3, 3.1.4 and 3.2.3. Also, it not only breaks `from os import urandom`, but also prevents installation of many third-party packages that use setuptools or distribute, where the interpreter bails out with: OSError: No such file or directory /dev/urandom inside setup.py on all Tru64 machines, and HPUX 11.00 and 11.11 (at least). As best I can tell it's failing either because dev_urandom_noraise aborts the interpreter if /dev/urandom is missing, or later an uncaught PyExc_OSError in dev_urandom_python triggers for the same reason. In either case there's no NotImplemented exception raised for the fallback code be used :( -- nosy: +bugs-pyt...@vendor.thewrittenword.com versions: +Python 2.6, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Stefan Krah added the comment: Dag Sverre Seljebotn rep...@bugs.python.org wrote: It is perfectly possible for an object to export memory in a read-only way that may still change. Another object may have a writeable view: x = obj.readonly_view y = obj.writable_view obj.move_to_next_image() # changes memory under x, y PEP-3118 always means different things to different people. :) Your distinction between constant, readonly, writable is one way to interpret things. But looking at the use in the Python source tree, readonly does mean immutable. Unfortunately the PEP doesn't specify readonly: Is it the same as mount a partition readonly, readonly CD or O_RDONLY? Also, existing practice was that in response to a PyBUF_FULL_RO request the exporter was free to hand out a writable buffer! This is now documented and subverts reliable tagging for consumers: http://docs.python.org/dev/c-api/buffer.html#readonly-format If any of this is a major inconvenience to NumPy or other users of the buffer API, perhaps you could open a separate issue. (FWIW, not sure how relevant this is; in NumPy, == does In [1]: np.array([1,2,3]) == np.array([1,3,3]) Out[1]: array([ True, False, True], dtype=bool) Since afa3dedfee18 we compare memoryviews and any exporter in the same manner as NumPy, except that the return value is a single boolean. So I think the new comparison is equivalent to all(a == b) in NumPy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15822] Python 3.3 creates lib2to3 grammar in wrong order
Ned Deily added the comment: Thanks for the details. Moving to ext4, I was still not seeing the problem as Grammar.txt and the pickle file have the same nanosecond ctime but that may be due to running in a vm environment or other factors. Manually touching Grammar.txt, not surprisingly, does cause the reported behavior so that's sufficient for testing purposes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Stefan Krah added the comment: Dag Sverre Seljebotn rep...@bugs.python.org wrote: OK, I can understand the desire to make memoryviews be bytes-like objects (though to my mind, bytes is frozen in a very different way...) We have two desires that sometimes conflict: People who want to use memoryview as a *buffer* legitimately want it to behave like bytes. People who want to have an arrayview want it to behave like NumPy or PIL arrays. The new implementation preserves fast paths for bytes and otherwise behaves pretty much like a very restricted version of NumPy's ndarray (with support for suboffsets), except that not all planned multi-dimensional features have been implemented yet. If so, and it is deemed worth it, my suggestion is to add a new PyBUF_CONST flag to the buffer acquisition in that case Note that memory_hash() raises an error if the exporter *itself* is not hashable, so it only hashes immutable objects by design. But the PyBUF_CONST flag might be worth considering (in another issue). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15701] AttributeError from HTTPError when using digest auth
Berker Peksag added the comment: Python 2.6 is now in security-fix-only mode. -- components: +Library (Lib) nosy: +berker.peksag versions: +Python 2.7 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15701 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15825] Typo in OrderedDict docs
Mike Hoy added the comment: I added two patches one for 2.7 and one for 3.3. Please advise if this is the correct way to handle this. -- keywords: +patch nosy: +mikehoy Added file: http://bugs.python.org/file27068/typo-ordered-dict2.7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15825] Typo in OrderedDict docs
Changes by Mike Hoy mho...@gmail.com: Added file: http://bugs.python.org/file27069/typo-ordered-dict3.3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
New submission from Mike Hoy: From the Docs mailing list: Hi I found a bug in python docs which can be accessed at links: http://docs.python.org/library/threading.html#lock-objects http://docs.python.org/py3k/library/threading.html#lock-objects Bug is in second paragraph describing threading.Lock. I found that statement: If an attempt is made to release an unlocked lock, a RuntimeError will be raised. Which is not true, name of exception is wrong it should be (and it relay is) ThreadError (from threading module) Could someone fix it? -- Br, Slawomir Kuszczynski -- messages: 169513 nosy: mikehoy priority: normal severity: normal status: open title: Threading Lock - Wrong Exception Name versions: Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Mike Hoy added the comment: Working on a patch now unless there are objections to the OP. -- nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Martin v. Löwis added the comment:
Am 31.08.12 06:14, schrieb Stefan Behnel:
To add on Dag's comments, this essentially means that any caching of
the hash value is dangerous
Stefan Krah is right here: the proper test (which is already
implemented) is whether the underlying object is hashable; this
is a sufficient test.
Caching of the hash is always correct, or else the hash function
is incorrect: a hash of an object must not change. If it would
change, you couldn't find the key anymore in a dictionary.
unless it can be assured that the
underlying buffer definitely has not changed in the meantime. There
is no way for users to explicitly tell a memoryview to rehash itself,
so putting it into one dict, then modifying the content, then putting
it into another is a perfectly reasonable use case for users,
No, it's not:
d = {}
o = some_object
m = memoryview(o)
d[m] = -1
o.modify() # so that hash(m) changes
print(d[m]) # keyerror, even though m in d.keys()
As far as I can see it, any obvious fix for this creates a whole
bath tub full of worms: updating views transitively, adding new APIs,
supporting new buffer parameters, ...
So above (in this thread): the easiest fix is to just drop hashing
support for memoryview objects. This can be extended in steps:
- support hashing if the underlying object is bytes
- support hashing if the shape is 1D B, and the underlying object
is hashable
- support hashing if the exporter has somehow promised to not modify
the memory
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15814
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Andrew Svetlov added the comment: The problem is: threading.Lock raises ThreadingError (which is subclass of RuntimeError for 3.3 but not for 3.2), but threading.Condition raises RuntimeError for the same reason. RLock behavior is even worse: it raises ThreadingError if C accelerator is available in _thread and RuntimeError otherwise. I think RuntimeError should be replaced by ThreadingError for _RLock and Condition implementations as well as docs need to be updated. Also I think this patch should be applied to 3.4 only, it is enchacement, not bugfix. About fixing docs for 2.7-3.3: I see nothing wrong if current inconsistency will be documented, perhaps as *warning* or *note* block. -- components: +Library (Lib) nosy: +asvetlov type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13992] Segfault in PyTrash_destroy_chain
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Mike Hoy added the comment: I think RuntimeError should be replaced by ThreadingError for _RLock and Condition implementations as well as docs need to be updated. Also I think this patch should be applied to 3.4 only, it is enchacement, not bugfix. About fixing docs for 2.7-3.3: I see nothing wrong if current inconsistency will be documented, perhaps as *warning* or *note* block. I should warn that ThreadError or `ThreadError` has no link. I've tried to find a place in the docs I could link to but haven't yet. `ValueError` does have a link. -- type: enhancement - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Mike Hoy added the comment: I think RuntimeError should be replaced by ThreadingError for _RLock and Condition implementations as well as docs need to be updated. Also I think this patch should be applied to 3.4 only, it is enchacement, not bugfix. About fixing docs for 2.7-3.3: I see nothing wrong if current inconsistency will be documented, perhaps as *warning* or *note* block. I should warn that ThreadError or `ThreadError` has no link. I've tried to find a place in the docs I could link to but haven't yet. `ValueError` does have a link. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- stage: committed/rejected - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- Removed message: http://bugs.python.org/msg169518 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Andrew Svetlov added the comment: ValueError can be referenced by :exc:`ValueError`. For ThreadError you can add section for describing this exception type like: .. exception:: ThreadError Raised when lock object cannot be acquired or released. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15340] OSError with import random when /dev/urandom doesn't exist (regression from 2.6)
The Written Word added the comment: The root of the problem preventing me from running some 3rd party setup.py scripts correctly is the mismatch between (recently) raising an OSError in Python/random.c, but catching only NotImplementedError in Lib/random.py. For backwards compatibility (previous releases all raised and caught NotImplementedError), here is a patch that stops Python bailing out with OSError: No such file or directory /dev/urandom for me. Tested with Python-2.6.8, Python-2.7.3 and Python-3.2.3, on HPUX 11.00, HPUX 11.11 and Tru 64 5.1. Arguably, as long as 3rd party code doesn't rely on the NotImplementedError exception, changing random.py to catch OSErrors would work equally well. This patch does not stop dev_urandom_noraise() from halting the interpreter on machines with no /dev/urandom, but that seems intentional to me so I didn't try to fix it. -- components: +Interpreter Core -Library (Lib) keywords: +patch Added file: http://bugs.python.org/file27070/hash-randomization-not-implemented.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15340] OSError with import random when /dev/urandom doesn't exist (regression from 2.6)
Antoine Pitrou added the comment: Looks like a critical regression to me. -- nosy: +barry, benjamin.peterson, georg.brandl, pitrou priority: normal - release blocker versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15825] Typo in OrderedDict docs
Roundup Robot added the comment: New changeset 69952b5599b5 by Andrew Svetlov in branch '2.7': Issue #15825: fix typo in OrderedDict docs. http://hg.python.org/cpython/rev/69952b5599b5 New changeset 8877d25119ef by Andrew Svetlov in branch '3.2': Issue #15825: fix typo in OrderedDict docs. http://hg.python.org/cpython/rev/8877d25119ef New changeset ef80ce83eab1 by Andrew Svetlov in branch 'default': Issue #15825: fix typo in OrderedDict docs. http://hg.python.org/cpython/rev/ef80ce83eab1 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15825] Typo in OrderedDict docs
Andrew Svetlov added the comment: Thanks. -- nosy: +asvetlov resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +brett.cannon, ncoghlan priority: normal - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Mike Hoy added the comment: I discussed this in IRC and got the following information from Ezio: Taggnostr the doc fix can go in 2.7/3.3, the code fix in 3.4 Plan is to put the definition for ThreadError in threading.rst for both 2.7 and 3.3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Andrew Svetlov added the comment: Sounds good. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Mike Hoy added the comment: 3.3 patch -- keywords: +patch Added file: http://bugs.python.org/file27071/15829-thread-errror3.3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
Mike Hoy added the comment: 2.7 patch. -- Added file: http://bugs.python.org/file27072/15829-thread-errror2.7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Nick Coghlan added the comment:
An even easier reproducer:
import imp
[93559 refs]
details = imp.find_module(_elementtree)
[93572 refs]
mod = imp.load_module('_elementtree', *details)
Traceback (most recent call last):
File stdin, line 1, in module
File /home/ncoghlan/devel/py3k/Lib/imp.py, line 171, in load_module
raise ImportError(msg, name=name)
ImportError: Don't know how to import _elementtree (type code 3
[93572 refs]
--
keywords: +3.3regression
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15828
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Nick Coghlan added the comment: Patch adds test case and fix (there was simply a missing entry for C_EXTENSION/load_dynamic in the load_module if-elif chain). Also moves an imp module test from test_import to test_imp (it's the test I used as a guide to check I wasn't missing anything obvious when writing the new one). -- keywords: +patch Added file: http://bugs.python.org/file27073/issue15828_handle_extension_modules.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Changes by Nick Coghlan ncogh...@gmail.com: -- nosy: +georg.brandl stage: - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Nick Coghlan added the comment: Tweaked patch to also fix the typo in the error message -- Added file: http://bugs.python.org/file27074/issue15828_handle_extension_modules.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Changes by Nick Coghlan ncogh...@gmail.com: Removed file: http://bugs.python.org/file27073/issue15828_handle_extension_modules.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Nick Coghlan added the comment: I'm heading to bed, so whoever reviews this one, please feel free to add a NEWS entry and check it in :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15829] Threading Lock - Wrong Exception Name
R. David Murray added the comment: Please see Issue 14502. The docs probably do need clarification, but it must be done carefully. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Brett Cannon added the comment: LGTM -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Trent Nelson added the comment: Well, that escalated quickly :-) I think I should clarify my use case that resulted in raising this bug. 1. Create a fresh hg clone, say, ~/hg/cpython-3.2. 2. Make it readonly: `zfs set readonly=on tank/home/cpython/hg/cpython-3.2` 3. cd /tmp/cpython-3.2-build 4. /home/cpython/hg/cpython-3.2/configure --srcdir=/home/cpython/hg/cpython-3.2/configure So, my patches address that use case. The thing I like about the approach above is that I can set the source directory to readonly immediately -- I don't have to do an intermediate ./configure in that directory in order to generate a Makefile so I can `make touch`. (Side note: I'm almost certain `make touch` wouldn't work for my use case.) Richard: what was your use case? What steps did you take that resulted in getting typeslots.inc and _sysconfigdata.py written to? although I just tried an out-of-tree build with 'default' using the exact steps above and got the same error with _sysconfigdata.py. Martin: I think I understand your arguments, and I (think) I agree with them. Especially your last point with regards to always running ASDLGEN. I think I'm +1 on reverting and trying the '-' approach originally used by Neil. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14502] Document better what happens on releasing an unacquired lock
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Martin v. Löwis added the comment: Am 31.08.12 15:19, schrieb Trent Nelson: I think I should clarify my use case that resulted in raising this bug. 1. Create a fresh hg clone, say, ~/hg/cpython-3.2. 2. Make it readonly The use case is really uncontended, and long-standing. People want to build from CD-ROM sources, from sources mounted via NFS, from sources owned by some other user - there are really many reasons why you want to build in a separate directory, and why you then do not want the original source be clobbered. Richard: what was your use case? I guess pretty much the same (though perhaps not ZFS). What steps did you take that resulted in getting typeslots.inc and _sysconfigdata.py written to? Touch Include/typeslots.h (before making the checkout readonly) to see this problem. On a hg checkout, it really depends on the order in which Mercurial creates the files to either run or not run into one of these issues. You were lucky that the timestamps happened to be in an order were in an order that caused typeslots.inc to be newer than its sources. AFAIK, hg uses alphapbetical order when updating files, so this may have helped. I think I'm +1 on reverting and trying the '-' approach originally used by Neil. Please don't. I think Victor dropped the - because it would mask errors from running pgen. pgen might fail, but pgen.stamp is still generated. Then, on a subsequent run, pgen would not run again. Of course, pgen.stamp is a later addition (by me), so this wasn't originally a problem. I think the regular case should be that the time stamps are in the right order in the source tree, so none of the generators should run. But if they happen to be in the wrong order (either because of Mercurial, or because one of the sources was actually modified), then the generators should run and output into the build directory. Since the committed patch is already a step in that direction, I think it now needs to be completed. It's mandatory (IMO) that the generated files are actually used; that the generators are not run if not needed is optional and can be fixed later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15830] make -s no longer silences output from setup.py
New submission from Brett Cannon: Sometime in the last month (probably) I change has been made in either configure(.ac), Makefile.pre.in, or setup.py that is causing the -s option passed to make to not also make its way into setup.py when extensions are built. -- components: Build keywords: 3.2regression messages: 169536 nosy: brett.cannon priority: normal severity: normal status: open title: make -s no longer silences output from setup.py versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15830 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Nick Coghlan added the comment: Since I'm still up, I guess I'll check it in, then :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13992] Segfault in PyTrash_destroy_chain
Manu Cupcic added the comment: I am testing this patch right now. Will report back. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Nick Coghlan added the comment: Over to Georg to cherry pick this one into rc2 -- assignee: - georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Roundup Robot added the comment: New changeset 9ba57938f54d by Nick Coghlan in branch 'default': Issue #15828: Restore support for C extension modules in imp.load_module() http://hg.python.org/cpython/rev/9ba57938f54d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Richard Oudkerk added the comment: Richard: what was your use case? Building on the main host and a VM without having to commit and synchronize temporary changes. (The VM has read-only access to the host's repositories). What steps did you take that resulted in getting typeslots.inc and _sysconfigdata.py written to? As Martin says it is probably just the timestamps which caused typeslots.inc to be rebuilt. In 3.3 _sysconfigdata.py is rebuilt whenever the python binary is. I suspect a bigger issue is the fact that *.pyc files cannot be written to $(srcdir)/Lib/__pycache__. This means that to complete the build, $(PYTHON_FOR_BUILD) should probably include the -B flag to prevent it from trying to write *.pyc files to a read-only location. But that still leaves you with a python which only works with the -B flag. Maybe library files could be linked/copied to some writable directory early in sys.path. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Martin v. Löwis added the comment: Am 31.08.12 16:40, schrieb Richard Oudkerk: I suspect a bigger issue is the fact that *.pyc files cannot be written to $(srcdir)/Lib/__pycache__. This means that to complete the build, $(PYTHON_FOR_BUILD) should probably include the -B flag to prevent it from trying to write *.pyc files to a read-only location. Why is that? python will work just fine if it can't write pyc files. But that still leaves you with a python which only works with the -B flag. Maybe library files could be linked/copied to some writable directory early in sys.path. Just for running setup.py? I don't see the need for that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15828] imp.load_module doesn't support C_EXTENSION type
Roundup Robot added the comment: New changeset d54f047312a8 by Brett Cannon in branch 'default': Issue #15828: Don't try to close a file if imp.find_module() doesn't http://hg.python.org/cpython/rev/d54f047312a8 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Richard Oudkerk added the comment: Why is that? python will work just fine if it can't write pyc files. When I hacked around the _sysconfigdata.py issue, running the created python produced Fatal Python error: Py_Initialize: Unable to get the locale encoding Traceback (most recent call last): File /mnt/hgfs/Repos/cpython-dirty/Lib/encodings/__init__.py, line 31, in module File frozen importlib._bootstrap, line 1562, in _find_and_load File frozen importlib._bootstrap, line 1529, in _find_and_load_unlocked File frozen importlib._bootstrap, line 590, in _check_name_wrapper File frozen importlib._bootstrap, line 1027, in load_module File frozen importlib._bootstrap, line 1008, in load_module File frozen importlib._bootstrap, line 566, in module_for_loader_wrapper File frozen importlib._bootstrap, line 858, in _load_module File frozen importlib._bootstrap, line 994, in get_code File frozen importlib._bootstrap, line 1055, in _cache_bytecode File frozen importlib._bootstrap, line 1078, in set_data File frozen importlib._bootstrap, line 128, in _write_atomic OSError: [Errno 5] Input/output error: '/mnt/hgfs/Repos/cpython-dirty/Lib/__pycache__/codecs.cpython-33.pyc.3076609376' Aborted I took this to be a failure to write the bytecompiled file. (A regression?) Running ./python -B does work correctly for me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Richard Oudkerk added the comment: It looks like the code which writes the byte-compiled codes checks for and ignores PermissionError (EACCES, EPERM) and FileExistsError (EEXIST). However, for me it is EIO which is raised. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Martin v. Löwis added the comment: Am 31.08.12 17:32, schrieb Richard Oudkerk: File frozen importlib._bootstrap, line 128, in _write_atomic OSError: [Errno 5] Input/output error: '/mnt/hgfs/Repos/cpython-dirty/Lib/__pycache__/codecs.cpython-33.pyc.3076609376' Aborted I took this to be a failure to write the bytecompiled file. (A regression?) Sounds like a regression to me. However, errno 5 is EIO. Normally, you should get PermissionError(errno=13, EACCES). I could understand EROFS as well. This sounds like a bug in the VM software, which really should report EROFS if the volume is read-only, not EIO. You might want to check whether this really is a regression; in any case, I consider Python's reaction reasonable and then your setup as just not supported. However, I could also accept that a work-around is added for treating EIO also as an ignorable error. In any case, this is a separate issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
New submission from Chris Jerdonek: From d...@python.org: In a number of places we find documentation with optional leading arguments where the meta-notation (square brackets) are in the wrong place. For example, for range, the standard doc heading says range([start], stop [, step]) # The comma after start should be inside the square bracket, not outside. The same error occurs with docs for print, and for slice, for random.randrange and for random.seed, etc, etc. This seems a consistent bug whenever a function or method takes an optional first argument, and it looks like it might have been put there by some tool that generates the docs. I use Python 3 - perhaps there was once a time when one had to supply the comma if one omitted the first argument? In Python 3 it gives errors if one follows the documentation carefully and uses the comma. (or see http://mail.python.org/pipermail/docs/2012-August/010051.html ) -- assignee: docs@python components: Documentation messages: 169547 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: comma after leading optional argument is after bracket in docs type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Changes by Ezio Melotti ezio.melo...@gmail.com: -- keywords: +easy nosy: +ezio.melotti stage: - needs patch versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15832] argparse: typechecks default value too early
New submission from Riccardo Murri:
The `argparse` module (tested with 2.7, but other versions might be
affected) checks the `default` value of an option too early: if the
default value raises an exception, then command-line parsing stops.
Consider for example the following code:
### begin sample #
import os
import argparse
def existing_filename(path):
if not os.access(path, os.F_OK | os.R_OK):
raise argparse.ArgumentTypeError(File '%s' does not exist or cannot be
read. % path)
return path
parser = argparse.ArgumentParser(description='Process a file.')
parser.add_argument('file', type=existing_filename,
default='/some/weird/default',
help='A file to process.')
args = parser.parse_args()
print (Will process file '%s' ... % args.file)
### end sample #
The intention here is that the default value should be used *if and
only if* the script users do not provide their own file to process.
It may happen that the default is invalid, but that should be reported
as an error only if the default is used, i.e., users did not provide
any file name to the script.
What happens instead is that the argparse errors out in any case, even
when `--help` is requested or when a valid file name is passed, as the
following two examples show:
rmurri@xenia:/tmp$ ./argparse-processes-defaults-too-early.py --help
Traceback (most recent call last):
File ./argparse-processes-defaults-too-early.py, line 18, in module
args = parser.parse_args()
File /usr/lib/python2.7/argparse.py, line 1688, in parse_args
args, argv = self.parse_known_args(args, namespace)
File /usr/lib/python2.7/argparse.py, line 1710, in parse_known_args
default = self._get_value(action, default)
File /usr/lib/python2.7/argparse.py, line 2239, in _get_value
raise ArgumentError(action, msg)
argparse.ArgumentError: argument file: File '/some/weird/default' does not
exist or cannot be read.
rmurri@xenia:/tmp$ ./argparse-processes-defaults-too-early.py /tmp/xxx.py
Traceback (most recent call last):
File ./argparse-processes-defaults-too-early.py, line 18, in module
args = parser.parse_args()
File /usr/lib/python2.7/argparse.py, line 1688, in parse_args
args, argv = self.parse_known_args(args, namespace)
File /usr/lib/python2.7/argparse.py, line 1710, in parse_known_args
default = self._get_value(action, default)
File /usr/lib/python2.7/argparse.py, line 2239, in _get_value
raise ArgumentError(action, msg)
argparse.ArgumentError: argument file: File '/some/weird/default' does not
exist or cannot be read.
Thanks!
--
components: Library (Lib)
messages: 169548
nosy: riccardomurri
priority: normal
severity: normal
status: open
title: argparse: typechecks default value too early
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15832
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Chris Jerdonek added the comment: Do we know that this is easy? It might be a Sphinx issue, in which case it might not be as trivial as fixing typos. I ask because the reST file looks correct (for range() for example): .. function:: range([start,] stop[, step]) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Ezio Melotti added the comment: I thought that was just a matter of finding the wrong commas and fixing them, but if they are correct in the source, then the situation might be a bit more complicated. Does this happen only with unusual signatures like range([start], stop [, step])? FWIW this could be replaced with: range(stop) range(start, stop [, step]) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15832] argparse: typechecks default value too early
R. David Murray added the comment: It is possible this could be considered a feature rather than a bug :) Let's see what Steven thinks. -- nosy: +bethard, r.david.murray versions: +Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15832 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Eric Snow added the comment: Doesn't EIO cover pathologies which we don't want to silence? I could see adding EROFS though. -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Chris Jerdonek added the comment:
This is what my search for ,] gave me (though the OP's print and random.seed
do not show up in this list):
library/curses.rst
380:.. function:: newwin([nlines, ncols,] begin_y, begin_x)
659:.. method:: window.addch([y, x,] ch[, attr])
673:.. method:: window.addnstr([y, x,] str, n[, attr])
679:.. method:: window.addstr([y, x,] str[, attr])
766:.. method:: window.chgat([y, x, ] [num,] attr)
815:.. method:: window.derwin([nlines, ncols,] begin_y, begin_x)
909:.. method:: window.hline([y, x,] ch, n)
943:.. method:: window.insch([y, x,] ch[, attr])
964:.. method:: window.insnstr([y, x,] str, n [, attr])
1156:.. method:: window.subpad([nlines, ncols,] begin_y, begin_x)
1162:.. method:: window.subwin([nlines, ncols,] begin_y, begin_x)
1219:.. method:: window.vline([y, x,] ch, n)
library/functions.rst
1064:.. function:: range([start,] stop[, step])
1129:.. function:: slice([start,] stop[, step])
library/itertools.rst
55::func:`islice` seq, [start,] stop [, step] elements from
seq[start:stop:step] ``islice('ABCDEFG', 2, None) -- C D E F
G``
404:.. function:: islice(iterable, [start,] stop [, step])
library/random.rst
96:.. function:: randrange([start,] stop[, step])
library/syslog.rst
20:.. function:: syslog([priority,] message)
library/tkinter.tix.rst
507:.. method:: tixCommand.tix_configure([cnf,] **kw)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15831
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15826] Increased test coverage of test_glob.py
Ezio Melotti added the comment: I think it would be easier to subclass GlobTests and override norm and glob there (assuming that doesn't create problems with some of the tests). -- nosy: +ezio.melotti stage: - patch review versions: +Python 3.2, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Andrew Svetlov added the comment: Yes, it looks like Sphinx problem. About having tho signatures for single function/method. Does Sphinx support it for *.. function::*? Pointing to anchor for first signature with adding second one somewhere in paragraph text doesn't look good. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15815] Add numerator to ZeroDivisionError messages
Ezio Melotti added the comment: I'm not sure this is really useful. Once I know that I divided by zero and I know where the division is, I don't really care what the numerator is. Knowing the exact type of the denominator (0, 0.0, 0j) doesn't sound too useful as well -- unless you somehow manage to get the wrong type and a 0-value at the same time. On a side note, I don't like ZeroDivisionError: integer division or modulo of 3 by 0 too much, but I would prefer ZeroDivisionError: integer division (or modulo) by zero over ZeroDivisionError: integer division or modulo by zero IIRC the reason why both division and modulo are included in the message is because the error is created in a piece of code that is shared by both operations. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15815 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Andrew Svetlov added the comment: No, methods for *curses* are also corrupted. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Ezio Melotti added the comment: Does Sphinx support it for *.. function::*? I'm pretty sure it does for methods, so I don't see why it shouldn't work for functions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Martin v. Löwis added the comment: Am 31.08.12 18:18, schrieb Eric Snow: Doesn't EIO cover pathologies which we don't want to silence? I could see adding EROFS though. [This should *really* be its own issue] Sure, EIO indicates normally something pathological, such as a broken cable to the disk. I'm not sure it needs to be reported, though, at least not when coming out of open(): we are trying to write to the cache, and that failed really bad. However, this is not bad for Python: if we don't have a cache file, we can still continue executing. If we get EIO in the middle of writing, this would be worse. So as a work-around, I could propose to map OSError(EIO) coming out of open into PermissionError(EIO) (inside _bootstrap). But as I said: I'd also be fine with declaring this VM software unsupported. If this work-around is added, we should record the exact software for which it is a work-around, so we can remove it in the future. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15701] AttributeError from HTTPError when using digest auth
Senthil Kumaran added the comment: Okay, this is funny. first info is invoking addinfourl of urllib, which would return headers. But in urllib2, the headers are self.hdrs I would side with the documentation that info is advertised method for HTTPError object. In 2.7, I guess just docs could be improved. This problem would be the present in 3.x. -- assignee: - orsenthil nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15701 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Ezio Melotti added the comment: This is what my search for ,] gave me It would be fine with me to use a double signature for these. Georg, do you have any opinion? (The double signature might be easier to understand, but the original issue should probably be fixed in Sphinx, even if we decide to stop using this kind of signature.) -- nosy: +eric.araujo, georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Ezio Melotti added the comment: No, methods for *curses* are also corrupted. I meant the double signature support. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Chris Jerdonek added the comment: It would be fine with me to use a double signature for these. Just an FYI that more than two signatures would be needed for cases like this: 766:.. method:: window.chgat([y, x, ] [num,] attr) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15833] most failures to write byte-compiled file no longer suppressed
New submission from Richard Oudkerk: As discussed in http://bugs.python.org/issue15819 trying to run python built outside a read-only source directory fails for me because OSError(EIO, ...) is raised when importlib tries to write the byte compiled file. (I built python in a Linux VM using VMware Player which only had read-only access to the source directory.) Currently importlib only ignores PermissionError (EACCES, EPERM) and FileExistsError (EEXIST): http://hg.python.org/cpython/file/d54f047312a8/Lib/importlib/_bootstrap.py#l1080 Under Python 3.2 all failures are ignored: http://hg.python.org/cpython/file/69952b5599b5/Python/import.c#l905 so this seems to be a regression. -- components: Interpreter Core keywords: 3.3regression messages: 169564 nosy: brett.cannon, sbt priority: normal severity: normal status: open title: most failures to write byte-compiled file no longer suppressed type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Ezio Melotti added the comment: 766:.. method:: window.chgat([y, x, ] [num,] attr) What's this even supposed to mean? See also #14783. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Chris Jerdonek added the comment: What's this even supposed to mean? I started wondering the same thing after I posted. :) I guess my point/question is: are there any cases where more than two signatures would be needed to account for all of the possibilities? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14783] Update int() docstring from manual
Éric Araujo added the comment: +1! This notation helps clearing up how int, str and other constructors work. -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Ezio Melotti added the comment: I think/hope that all the APIs we have in the stdlib are sane enough to have no more than 2-3 signatures (I'm not counting optional args (at the end) here). If that's not the case we should still be able to add as many signature as we need (I don't know if Sphinx has some limit about it though). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15819] Unable to build Python out-of-tree when source tree is readonly.
Richard Oudkerk added the comment: I have opened a new issue: http://bugs.python.org/issue15833 It is a regression because in Python 3.2 all failures to open the file for writing were supressed. But as I said: I'd also be fine with declaring this VM software unsupported. If this work-around is added, we should record the exact software for which it is a work-around, so we can remove it in the future. It is VMware Player 4.0.0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15832] argparse: typechecks default value too early
Changes by Steven Bethard steven.beth...@gmail.com: -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15832 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15832] argparse: typechecks default value too early
Steven Bethard added the comment: It's a bug, but it's already been reported in Issue 12776. There's a patch there, but someone needs to commit it. -- superseder: - argparse: type conversion function should be called only once ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15832 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15830] make -s no longer silences output from setup.py
Ned Deily added the comment: Issue15591 perhaps? -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15830 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15810] assertSequenceEqual should be fired when comparing sequence subclasses
Gregory P. Smith added the comment: When we added this functionality to assertEqual we were *intentionally* conservative on when it would auto-promote to nicer equality comparison functions. It needs to behave exactly as == would in all situations. (1,2,3) == [1,2,3] False We must maintain that behavior in assertEqual. Tests should use assertSequenceEqual when they want to compare sequences regardless of type because they are testing for something less than strict equality. -- nosy: +gregory.p.smith resolution: - rejected stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14783] Update int() docstring from manual
Ezio Melotti added the comment: Here's a patch for the signature. -- assignee: - ezio.melotti keywords: +patch stage: needs patch - commit review Added file: http://bugs.python.org/file27075/issue14783.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15821] PyMemoryView_FromBuffer() behavior change (possible regression)
Stefan Krah added the comment: Alexander, your test case is brilliant and could eventually go into _testbuffer.c, but I'd prefer a simpler test case for now. :) Here's a patch that restores the info.obj cleanup facility. I intentionally did not add copying the format in order to keep the diff small (in case this can go into rc2). Crashing on stack addresses for format is not a regression. Apparently PyMemoryView_FromBuffer() is used for low level tinkering and automatic cleanup, so I now think that it's better not to break backwards compatibility, i.e. leave the value of info.obj untouched. Otherwise people using the cleanup facility will have reference leaks. However, I don't like the interface at all: Passing a pointer to a struct and then relying on the fact that *some* values are copied (shape, strides and suboffsets) but not others (format, buf) is counterintuitive. With the ManagedBuffer, we could now write a new function that returns a memoryview with much nicer cleanup facilities. But that doesn't help here since we're stuck with this function for 3.3.0. What do you think? Should this go into 3.3.0? The changes to memoryobject.c are minimal, the rest are tests and docs. -- assignee: docs@python - skrah components: +Interpreter Core -Documentation stage: - patch review title: Improve docs for PyMemoryView_FromBuffer() - PyMemoryView_FromBuffer() behavior change (possible regression) type: enhancement - behavior Added file: http://bugs.python.org/file27076/issue15821.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15821 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15821] PyMemoryView_FromBuffer() behavior change (possible regression)
Alexander Belopolsky added the comment: On Fri, Aug 31, 2012 at 2:34 PM, Stefan Krah rep...@bugs.python.org wrote: With the ManagedBuffer, we could now write a new function that returns a memoryview with much nicer cleanup facilities. But that doesn't help here since we're stuck with this function for 3.3.0. What do you think? Should this go into 3.3.0? I am still getting up to speed with all the changes that went in since 3.2. I'll review your patch over the weekend. Meanwhile, I think the goal should be that after PyMemoryview_FromBuffer(info) is called, it should be OK to discard info by calling PyBuffer_Release() and if info is not allocated on the stack, Py_DECREF(info). I think we are almost there achieving that goal with possible exception of dynamically or stack-allocated fmt strings. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15821 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15821] PyMemoryView_FromBuffer() behavior change (possible regression)
Stefan Krah added the comment: Alexander Belopolsky rep...@bugs.python.org wrote: I am still getting up to speed with all the changes that went in since 3.2. I'll review your patch over the weekend. Meanwhile, I think the goal should be that after PyMemoryview_FromBuffer(info) is called, it should be OK to discard info by calling PyBuffer_Release() Now I'm puzzled: I thought your goal was to preserve the implicit cleanup from 3.2, i.e. PyBuffer_Release() is called when the managed buffer is deallocated. Without the patch it's OK to call PyBuffer_Release(info) after PyMemoryview_FromBuffer(info). With the patch you can't call PyBuffer_Release(info), since it's done automatically already. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15821 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15756] subprocess.poll() does not handle errno.ECHILD No child processes
Changes by Berker Peksag berker.pek...@gmail.com: -- versions: -Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15756 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14783] Make int() and str() docstrings correct
Terry J. Reedy added the comment: The large issue is documenting complex signatures that do not really fit in any of the standard one-line patterns. I was initially puzzled by Raymond describing the 3.3 line as 'confusing', but putting on 'newbie glasses' I see now that correctly parsing int([number | string[, base]]) requires knowing that '[, option]' binds tighter than '|'. Since ',' normally has the lowest binding priority, someone who does not know the signature already (ie, a target audience member) could parse it as int([ (number | string) [, base]]) rather than as intended: int([number | (string[, base]) ]) So I agree that the two stacked lines in the doc patch are clearer. However, this issue is about the docstring. Leave it incorrect? Change it to the hard-to-parse one liner? Change it to a two-line signature also? I noticed this issue while working on IDLE tooltips, using int as a test case. They currently use only the first line of the docstring, but I have decided that they should get more when needed for C functions. (For Python functions, tooltips use inspect for the actual signature and the first docstring line only for a description.) The first line of the str docstring is also incorrect in that the optional parameters are only valid for first arguments that are strings. str(string[, encoding[, errors]]) - str It needs either a '|' construction like int or another line: str(object) I prefer the latter. I revised the title to add str.__doc__ to the issue. While we are at it, how about range(stop) range(start, stop, [step]) instead of the current doc and docstring signature range([start,] stop[, step]) ? The current docstring is inaccurate and confusing to some. (How can there be an optional first arg and required second ? -- Answer: there can't.) The technically accurate signature is range(start_or_stop[, stop[, step]]) but that has been rejected as confusing. The bytes and bytearrays docstrings have 5 signature lines!. (The manual gives just one which does not quite cover all cases.) So (a) there is precedent for multiple signatures in docstrings and (b) tooltips already need to grab multiple signature lines. So I think int and str (and maybe range) should use a couple of clear lines. If the new inspect.signature function were to give signatures for C functions, there would be no problem for tooltips, but it does not. (Can signature objects even handle multiple (or type-dependent) signatures?) -- nosy: +georg.brandl title: Update int() docstring from manual - Make int() and str() docstrings correct ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15535] Fix pickling of named tuples in 2.7.3 (BUG)
Thomas Miedema added the comment: Added a better testcase. -- title: Fix pickling of named tuples in 2.7.3 - Fix pickling of named tuples in 2.7.3 (BUG) Added file: http://bugs.python.org/file27077/namedtuple_pickle_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15535 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15535] Fix pickling of named tuples in 2.7.3 (BUG)
Changes by Thomas Miedema thomasmied...@gmail.com: Removed file: http://bugs.python.org/file26662/namedtuple_pickle_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15535 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Nicholas Cole added the comment: I'm reopening this bug because I've noticed that in Python3.3rc1, although trying to print curses.ACS_HLINE and other such characters no long cause an Exception, only blank characters are printed to the screen. Tested with both Terminal.App and xterm running under XQuartz. Here is some minimal test code, that will print a line on Python2.x but a blank screen on Python3.3rc1. -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14223 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Nicholas Cole added the comment: import curses def test_screen(screen): screen.addch(5,5, curses.ACS_HLINE) screen.addch(5,6, curses.ACS_HLINE) screen.refresh() curses.napms(2000) curses.wrapper(test_screen) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14223 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15756] subprocess.poll() does not handle errno.ECHILD No child processes
Gregory P. Smith added the comment: thanks! I'll take care of getting this fix in. -- assignee: - gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15756 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15821] PyMemoryView_FromBuffer() behavior change (possible regression)
Alexander Belopolsky added the comment: On Fri, Aug 31, 2012 at 3:12 PM, Stefan Krah rep...@bugs.python.org wrote: Now I'm puzzled: I thought your goal was to preserve the implicit cleanup from 3.2, i.e. PyBuffer_Release() is called when the managed buffer is deallocated. The issue that I raised in msg169472 above was that PyMemoryView_FromBuffer() would not copy .obj from Py_buffer structure to the memoryview. A related issue is that it looks like PyObject_GetBuffer() often does not fill .obj either. I would expect that PyObject_GetBuffer() would always store a new reference in .obj to assure that the .buf pointer remains valid until PyBuffer_Release() is called explicitly. (I am ignoring the issue of mutable objects such as lists for the moment.) PyMemoryView_FromBuffer() in turn should store an additional reference in its own private copy of Py_buffer structure. After PyMemoryView_FromBuffer() returns a well-behaved program should call PyBuffer_Release() releasing the first reference and the second reference should be released in memoryview destructor. Am I missing something? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15821 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15821] PyMemoryView_FromBuffer() behavior change (possible regression)
Alexander Belopolsky added the comment:
Here is what I think the test case should look like (untested):
static PyObject *
memoryview_from_buffer_cleanup(PyObject *self, PyObject *noargs)
{
PyObject *b, *view = NULL;
Py_buffer info;
Py_ssize_t shape[3] = {2, 2, 3};
Py_ssize_t strides[3] = {6, 3, 1};
const char *cp = abcdefghijkl;
b = PyBytes_FromString(cp);
if (b == NULL)
return NULL;
if (PyObject_GetBuffer(b, info, PyBUF_FULL_RO) 0)
goto done;
/* reshape */
info.ndim = 3;
info.shape = shape;
info.strides = strides;
view = PyMemoryView_FromBuffer(info);
/* release resources allocated for Py_buffer struct
before it goes out of scope */
PyBuffer_Release(info);
done:
Py_DECREF(b);
return view;
}
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15821
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15830] make -s no longer silences output from setup.py
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +doko ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15830 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15833] most failures to write byte-compiled file no longer suppressed
Antoine Pitrou added the comment: Raising EIO in a read-only dir sounds weird. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8912] `make patchcheck` should check the whitespace of .c/.h files
Chris Jerdonek added the comment: The following commit from today is related to this issue: 815b88454e3e Remove trailing whitespace in order to silence warnings on HP-UX. -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15775] Add StopParser() to expat
Changes by Berker Peksag berker.pek...@gmail.com: -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
