[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: > pitrou's patch changes PyFile_FromFd() behaviour for a text file > opened with buffering=0: > /* As a convenience, when buffering == 0 on a text file, we > open the underlying binary stream in unbuffered mode and > wrap it with a text stream in li

[issue4759] bytearray.translate() should support None first argument

Antoine Pitrou added the comment: Looks like there's a problem: >>> bytearray().translate(None, None) Traceback (most recent call last): File "", line 1, in TypeError: Type NoneType doesn't support the buffer API >>> bytearray().translate(None, None) Erreur de segmentation Also, the patch s

[issue4759] bytearray.translate() should support None first argument

Georg Brandl added the comment: You're right (but the segfault isn't introduced by the patch). Fixed segfault in 3.0 and 2.6 in r67975 and r67977. Applied path in 3k and trunk in r67974 and r67976. -- assignee: pitrou -> georg.brandl resolution: -> accepted status: open -> closed ___

[issue4489] shutil.rmtree is vulnerable to a symlink attack

Mart Sõmermaa added the comment: A shameless copy of the Perl fix for the bug http://bugs.debian.org/286922 looks like the evident solution. Somebody has to examine the fix though, I'm afraid I'm not currently able to do it. ___ Python tracker

[issue4731] suggest change to "Failed to find the necessary bits to build these modules" message

Georg Brandl added the comment: Done in r67978. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed ___ Python tracker ___ ___

[issue4705] python3.0 -u: unbuffered stdout

STINNER Victor added the comment: > > Why changing PyFile_FromFd() and not io.open() directly? > > I must admit I'm a bit lazy, and changing io.open() means changing > a fundamental public API, as Guido said on python-dev, so > more discussion and some parts of the patches delayed to 3.1. You

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: enumerate can be added to the list of builtin types which isn't initialised correctly, as can the callable+sentinel iterator return from the 2-argument version of iter() and the default sequence iterator returned by iter() when given a type with both __len__ and _

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: Copied from python-dev post: Perhaps the path of least resistance is to change PyObject_Hash to be yet another place where PyType_Ready will be called implicitly if it hasn't been called already? That approach would get us back to the Python 2.x status quo where

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: Le dimanche 28 décembre 2008 à 12:19 +, STINNER Victor a écrit : > STINNER Victor added the comment: > > > > Why changing PyFile_FromFd() and not io.open() directly? > > > > I must admit I'm a bit lazy, and changing io.open() means changing > > a fundamen

[issue4444] unittest - use contexts to assert exceptions

Antoine Pitrou added the comment: I've committed an improved patch, with tests and doc, in r67979 and r67981. Thanks! -- resolution: -> fixed status: open -> closed ___ Python tracker _

[issue4489] shutil.rmtree is vulnerable to a symlink attack

Antoine Pitrou added the comment: The Perl patch is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=36;filename=etch_03_fix_file_path;att=1;bug=286922 It is a recursive implementation of rmtree. What it does is 1) get the inode of the path 2) unlink it altogether if not a dir 3) otherwis

[issue4489] shutil.rmtree is vulnerable to a symlink attack

Antoine Pitrou added the comment: Mmmh, the problem with Perl's approach is that it changes the current working directory (calls to chdir()), which is process-specific and not thread-specific. Currently, no function in shutil changes the current working directory, which is a nice behaviour and s

[issue4761] create Python wrappers for openat() and others

New submission from Antoine Pitrou : Very recent POSIX versions have introduced a set of functions named openat(), unlinkat(), etc. (*) which allow to access files relatively to a directory pointed to by a file descriptor (rather than the process-wide current working directory). They are necessar

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: It seems the "name" field of the TextIOWrapper object isn't set in create_stdio() (the "char *name" parameter isn't used). Otherwise, the patch looks good. ___ Python tracker __

[issue1034053] unittest.py patch: add skipped test functionality

Antoine Pitrou added the comment: Pupeno's patch looks good to me. Additional candy would be a decorator to flag skipped tests (e.g. @skipped_test or @skipped_test("A message")), but we can do that later. -- stage: -> patch review type: -> feature request versions: +Python 2.7, Python

[issue2153] unittest.py modernization

Antoine Pitrou added the comment: Will take a look. -- versions: +Python 2.7 -Python 2.6 ___ Python tracker ___ ___ Python-bugs-list m

[issue4034] traceback attribute error

Antoine Pitrou added the comment: One possibility would be to only allow deleting the tb_frame attribute (setting it to NULL), not setting it to an arbitrary object. -- nosy: +pitrou ___ Python tracker

[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC

Benjamin Peterson added the comment: Applied the patch in r67982. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue4728] Endianness and universal builds problems

Benjamin Peterson added the comment: I applied the patch for #4060 in r67982. I would still like to know what difference an Intel machine makes in the installers, though. -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue4750] tarfile keeps excessive dir structure in compressed files

anatoly techtonik added the comment: 7zip can decompress both, but it still creates "dist/" directory when decompressing file that is made with Python. I've noticed this bug with extra path component is actual with "tar" + "gzip" under windows. If they are executed separately and windows path w

[issue2153] unittest.py modernization

Antoine Pitrou added the comment: Committed in r67985, thanks! -- resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue4608] urllib.request.urlopen does not return an iterable object

Jakub Wilk added the comment: Regarding Senthil's patch: __next__() method seems superfluous to me (and the implementation is buggy). ___ Python tracker ___ __

[issue4705] python3.0 -u: unbuffered stdout

STINNER Victor added the comment: >> Should we also change stdin? > I don't know, but "python -h" only talks about stderr/stdout. The manpage of Python2 is clear: -u Force stdin, stdout and stderr to be totally unbuffered. stdin is also unbuffered. > It seems the "name" field of the T

[issue4489] shutil.rmtree is vulnerable to a symlink attack

Mart Sõmermaa added the comment: > Mmmh, the problem with Perl's approach is that it changes the current > working directory (calls to chdir()), which is process-specific and not > thread-specific. Currently, no function in shutil changes the current > working directory, which is a nice behaviou

[issue4762] PyFile_FromFd() doesn't set the file name

New submission from STINNER Victor : PyFile_FromFd() never changes the name of new created file object: $ ./python -c "import sys; print(sys.stdout.buffer.name, sys.stdout.name)" 0 0 Expected result: . --- Binary mode: - with buffering == 0, the file object is a FileIO. Changing the name

[issue4705] python3.0 -u: unbuffered stdout

STINNER Victor added the comment: Attached: quick and dirty test to check if the standard input is buffered or not. My short test program works with python2.5 and py3k trunk without the -u command line option. So changing sys.stdin buffer is not really important. About the wrong name, I open

[issue4762] PyFile_FromFd() doesn't set the file name

STINNER Victor added the comment: In my last patch to fix the issue #4705, I replaced PyFile_FromFd() by custom code which set correctly the file name. PyFile_FromFd() is also used in: - _Py_DisplaySourceLine(): name is not used, only PyFile_GetLine(file) - call_find_module() (imp.find_modu

[issue4762] PyFile_FromFd() doesn't set the file name

STINNER Victor added the comment: > In my last patch to fix the issue #4705, I replaced PyFile_FromFd() > by custom code which set correctly the file name. The standard I/O: sys.stdin, sys.stdout and sys.stderr. ___ Python tracker

[issue4762] PyFile_FromFd() doesn't set the file name

Changes by STINNER Victor : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue4701] range objects becomes hashable after attribute access

Eric Smith added the comment: > Perhaps the path of least resistance is to change PyObject_Hash to be > yet another place where PyType_Ready will be called implicitly if it > hasn't been called already? I think that's the best thing to do. It would bring PyObject_Hash in line with PyObject_Form

[issue1034053] unittest.py patch: add skipped test functionality

Remy Blank added the comment: There's still a typo in the docstring of TestResult.addSkipped() (tuble -> tuple). ___ Python tracker ___ ___

[issue4489] shutil.rmtree is vulnerable to a symlink attack

Antoine Pitrou added the comment: > Using chdir() makes sense and it doesn't look like a too big problem to me: It's a problem if another thread in the process is making file operations using relative paths at the same time. Since shutil functions have until now been safe against this possibil

[issue3700] test_bigmem broken

Antoine Pitrou added the comment: Here is a patch. Not only does it fix the str tests, but it also adds similar tests for bytes and bytearray objects. -- keywords: +patch stage: -> patch review versions: +Python 3.1 Added file: http://bugs.python.org/file12480/bigmemtest.patch ___

[issue4728] Endianness and universal builds problems

Ronald Oussoren added the comment: On 28 Dec, 2008, at 16:38, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > I applied the patch for #4060 in r67982. I've backported that to 2.6-maint in r67987. > > > I would still like to know what difference an Intel machine makes in

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

Ronald Oussoren added the comment: I've committed the patch with some documentation in r67988, with a backport to 2.6.x in r67989. r67990 (not backported) is a minor update of the patch, it adds explicit support code for all three variants that are configurable through the configure script. I

[issue4763] PyErr_GivenExceptionMatches documentation out of date

New submission from garcia : The documentation for PyErr_GivenExceptionMatches states that "If given is NULL, a memory access violation will occur." However, looking at the code, this is not the case: the function returns 0 (read: false). It appears, rather, that this function always succeeds

[issue4761] create Python wrappers for openat() and others

Martin v. Löwis added the comment: There is a tradition that any POSIX calls are added to the POSIX module without much discussion, provided that a) there is an autoconf test testing for their presence, and b) they expose the API as-is, i.e. without second-guessing the designers of the original

[issue4761] create Python wrappers for openat() and others

Christian Heimes added the comment: The openat() functions sound useful indeed. However I'm concerned about the file descriptor requirment for the *at() POSIX functions. In Python file descriptors can lead to resource leaks because developers are used to automatic garbage collection. os.open() i

[issue4763] PyErr_GivenExceptionMatches documentation out of date

Benjamin Peterson added the comment: Thanks for the report! Fixed in r67995. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue4761] create Python wrappers for openat() and others

Martin v. Löwis added the comment: > Developers may think that the file descriptor is closed when the integer > object gets out of scope. I'm not concerned about that. When they use os.open, they will typically understand what a file handle is, and how it relates to > I propose the addition of

[issue4617] SyntaxError when free variable name is also an exception target

Benjamin Peterson added the comment: I think being able to delete free variables is reasonable and brings more consistency as well as solving corner cases like this. -- nosy: +benjamin.peterson ___ Python tracker _

[issue1886] Permit to easily use distutils "--formats=tar, gztar, bztar" on all systems

anatoly techtonik added the comment: Roumen, could you be more specific about what are you trying to say with this 200kB piece of code? Was it the intention to post a link to man or another piece of spec? ___ Python tracker

[issue4685] IDLE will not open (2.6.1 on WinXP pro)

Amaury Forgeot d'Arc added the comment: I would like to see the complete list of messages. Looks like a broken python installation... ___ Python tracker ___ __

[issue4449] AssertionError in Doc/includes/mp_benchmarks.py

Changes by Amaury Forgeot d'Arc : -- keywords: +needs review stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-

[issue4764] open('existing_dir') -> IOError instance's attr filename is None

New submission from Jan Kaliszewski : Py2.4 and 2.5 (and probably other 2.x releases too): >>> try: f=open('existing_dir') ... except IOError, exc: print exc.filename ... None (expected result: "existing_dir") Py3.0 (and possibly 3.1 too): >>> try: f=open('existing_dir') ... except IOError as ex

[issue4732] Object allocation stress leads to segfault on RHEL

Andrew added the comment: Cannot reproduce this on RHEL 4. So far only RHEL 5.x seems to be affected. ___ Python tracker ___ ___ Python-bugs-l

[issue4765] IDLE fails to "Delete Custom Key Set" properly

New submission from Alex Fainshtein : How to reproduce: 1. Start IDLE -> "Python Shell" window opens. 2. Open Options|"Configure Idle...". 3. In "idle" dialog select "Keys" tab. 4. Click "Set as New Custom Key Set" button. 5 In "New Custom Key Set" dialog, type a name, click "Ok". 4. Click "Appl