[issue8828] Atomic function to rename a file

Charles-François Natali added the comment: > According to the following article, a fsync is also needed on the > directory after a rename. I don't understand if is it always needed for > an atomic rename, or if we only need it for the "atomic write" pattern. It's not needed if you just want a

[issue12975] spam

Changes by Ezio Melotti : -- stage: -> committed/rejected title: Invitation to connect on LinkedIn -> spam ___ Python tracker ___ ___

[issue12975] Invitation to connect on LinkedIn

Changes by Ezio Melotti : -- Removed message: http://bugs.python.org/msg144010 ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue12975] Invitation to connect on LinkedIn

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file23150/unnamed ___ Python tracker ___ ___ Python-bugs-list mailin

[issue12975] Invitation to connect on LinkedIn

Changes by Charles-François Natali : -- resolution: -> invalid status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mai

[issue12971] os.isdir() should contain skiplinks=False in arguments

Changes by Alexey Smirnov : -- nosy: +alexey-smirnov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue12970] os.walk() consider some symlinks as dirs instead of non-dirs

Changes by Alexey Smirnov : -- nosy: +alexey-smirnov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()

Charles-François Natali added the comment: > Do you mean that signal.pthread_kill() should be removed? This function is > very useful and solve some issues that cannot be solved differently. At the > same time, I don't think that it's possible to workaround the crashes. At > least, I don't se

[issue12857] Expose called function on frame object

Eric Snow added the comment: Finally had a chance to get back to this. Here's a new patch in response to Nick's review. My only concern is the new _PyEval_EvalFunctionCode function. It is basically the existing PyEval_EvalCodeEx function with an extra parameter. I've turned PyEval_EvalCod

[issue1621] Do not assume signed integer overflow behavior

Changes by Alex Gaynor : -- nosy: +alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/m

[issue12946] PyModule_GetDict() claims it can never fail, but it can

Stefan Behnel added the comment: I gave two reasons why this function can fail, and one turns out to be assumed-to-be-dead code. So, no, there are two issues now, one with the documentation, one with the code. -- ___ Python tracker

[issue12881] ctypes: segfault with large structure field names

Meador Inge added the comment: > Note that there is at least one other place where alloca() is > used with potentially large values: Ouch! I found three more crashers (including the one you found) by grepping for 'alloca' in ctypes: >>> from ctypes import * >>> T = type('x' * 2 ** 25, (Struct

[issue12956] builds fail when installing to --prefix with space in path name

Ned Deily added the comment: It turns out that supporting a framework path name that contains spaces (or other special characters) is a much more pervasive change that I had originally expected. That's because the path specified by ./configure --enable-framework= also becomes the default for

[issue1947] Exception exceptions.AttributeError '_shutdown' in

Brandon Craig Rhodes added the comment: In case Google brings anyone else to this bug: this error typically indicates that a `threading.py` which is not actually the Standard Library's `threading` module has somehow wound up on an earlier path in `sys.path` and is therefore shadowing the Stan

[issue11149] [PATCH] Configure should enable -fwrapv for clang

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue1621] Do not assume signed integer overflow behavior

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue1172711] long long support for array module

Meador Inge added the comment: Updated patch with the 'Py_ssize_t' fixes. -- Added file: http://bugs.python.org/file23148/issue-1172711.patch ___ Python tracker ___ __

[issue12967] AttributeError distutils\log.py

ben added the comment: Error had been raised when installing the distribute package, but it could be raised on any other usage as sys.stdout does not have an 'error' attribute.     From: Éric Araujo To: thelen_...@yahoo.com Sent: Tuesday, 13 September 2011 8:54 PM Subject: [issue12967] Attrib

[issue1172711] long long support for array module

Meador Inge added the comment: > Okay, understood.  But the new 'long long' support provided by this patch > still allows for __int__-based duck typing, right? Yes, but ... > That's the new duck typing I meant.  I see this acceptance of things with an > __int__ method as a mistake, and my gu

[issue12974] array module: deprecate '__int__' conversion support for array elements

New submission from Meador Inge : When reviewing the fix for issue1172711 it was discovered that the 'array' module allows for '__int__' conversions: >>> import array, struct >>> a = array.array('L', [1,2,3]) >>> class T(object): ... def __init__(self, value): ... self.value = value

[issue12930] reindent.py inserts spaces in multiline literals

Caio Romão added the comment: Third version, with slightly less code and my name added to the Misc/ACKS file. -- Added file: http://bugs.python.org/file23146/caioromao-fix-12930-v3.patch ___ Python tracker ___

[issue12930] reindent.py inserts spaces in multiline literals

Changes by Caio Romão : Removed file: http://bugs.python.org/file23118/caioromao-fix-12930-v2.patch ___ Python tracker ___ ___ Python-bugs-lis

[issue12960] threading.Condition is not a class

Nikolaus Rath added the comment: On 09/13/2011 07:41 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > >> According to >> http://docs.python.org/library/threading.html#condition-objects, >> threading.Condition is a class. > > Nope, it's a factory, and it's written in the do

[issue10968] threading.Timer should be a class so that it can be derived

STINNER Victor added the comment: @eric: The doc has to be updated: http://docs.python.org/dev/library/threading.html#threading.activeCount "threading.Condition() A factory function that returns a new condition variable object. A condition variable allows one or more threads to wait until the

[issue12960] threading.Condition is not a class

STINNER Victor added the comment: > According to http://docs.python.org/library/threading.html#condition-objects, > threading.Condition is a class. Nope, it's a factory, and it's written in the doc: "threading.Condition() A factory function that returns a new condition variable object. A cond

[issue8828] Atomic function to rename a file

STINNER Victor added the comment: According to the following article, a fsync is also needed on the directory after a rename. I don't understand if is it always needed for an atomic rename, or if we only need it for the "atomic write" pattern. http://lwn.net/Articles/457667/ "The more subtle

[issue12946] PyModule_GetDict() claims it can never fail, but it can

STINNER Victor added the comment: So, can we close this issue? -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue11149] [PATCH] Configure should enable -fwrapv for clang

STINNER Victor added the comment: "Recent clang and Python2.7 (without the patch): >>> 2**64 0" Does the test suite catch this bug? -- ___ Python tracker ___ _

[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()

STINNER Victor added the comment: > as noted by Victor, it's really easy to crash the interpreter > by passing an invalid thread ID, which IMHO, should be avoided > at all cost Do you mean that signal.pthread_kill() should be removed? This function is very useful and solve some issues that can

[issue11149] [PATCH] Configure should enable -fwrapv for clang

Stefan Krah added the comment: Recent clang and Python2.7 (without the patch): Python 2.7.2+ (2.7:e8d8eb9e05fd, Sep 14 2011, 00:35:51) [GCC 4.2.1 Compatible Clang 3.0 (trunk 139637)] on freebsd8 Type "help", "copyright", "credits" or "license" for more information. >>> 2**63 -92233720368547758

[issue11149] [PATCH] Configure should enable -fwrapv for clang

Changes by Stefan Krah : -- nosy: +a...@netbsd.org, skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue12973] int_pow() implementation is incorrect

Stefan Krah added the comment: I can reproduce your results with a recent clang. gcc has similar optimization behavior, but for gcc ./configure automatically adds -fwrapv, which prevents the incorrect results. I'm closing this as a duplicate of #11149. -- resolution: -> duplicate stag

[issue12720] Expose linux extended filesystem attributes

Roundup Robot added the comment: New changeset 33f7044b5682 by Benjamin Peterson in branch 'default': Use xattr functions from sys/xattr.h instead of attr/xattr.h (closes #12720) http://hg.python.org/cpython/rev/33f7044b5682 -- resolution: -> fixed status: open -> closed _

[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()

Charles-François Natali added the comment: > If we have access (and as I understood from Victor's post we do): > pthread_getaffinity_np() also exists on FreeBSD, which would be > an advantage. Yes, but I see several drawbacks: - as noted by Victor, it's really easy to crash the interpreter by p

[issue12720] Expose linux extended filesystem attributes

Arfrever Frehtes Taifersar Arahesis added the comment: There is an inconsistency in used header and library. attr/xattr.h and libattr.so belong to attr package (http://savannah.nongnu.org/projects/attr). glibc provides sys/xattr.h and libc.so. Both libattr.so and libc.so define getxattr(), setx

[issue12973] int_pow() implementation is incorrect

Stefan Krah added the comment: I think this is related to issue #11149. Can you try compiling with -fwrapv? -- nosy: +skrah ___ Python tracker ___ __

[issue12973] int_pow() implementation is incorrect

New submission from Adam : int_pow() (from Objects/intobject.c) shows incorrect results when Python is compiled with Clang (llvm.org); long story short: int_pow() function should use 'unsigned long' type instead of 'long' or some code gets optimised out. Please, refer to this bug report to fin

[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()

Stefan Krah added the comment: Charles-François Natali wrote: > Out of curiosity, I just looked at the source code, and it just does > sched_setaffinity(thread->tid), so you can do the same with > sched_setaffinity(syscall(SYS_gettid)) for the current thread. sched_setaffinity(syscall(SYS_gett

[issue1172711] long long support for array module

Mark Dickinson added the comment: > Mark, just to clarify a bit, the behavior is already there in the array module Okay, understood. But the new 'long long' support provided by this patch still allows for __int__-based duck typing, right? >>> array('Q', [1, 2, Decimal(3.2)]) array('Q', [1, 2

[issue12785] list_distinfo_file is wrong

Jeremy Kloth added the comment: The attached patch seems to work as-is. That is, just testing for `self.path` as the prefix. On Windows, at least, the paths in RECORD are always absolute. Further changes will be necessary, of course, once changes for alternative paths (--prefix, --home, and

[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()

STINNER Victor added the comment: > However, I don't think we should/could add this to the posix module: > it expects a pthread_t instead of a PID, to which we don't have access. We already have such function: http://docs.python.org/dev/library/signal.html#signal.pthread_kill I added threadin

[issue1172711] long long support for array module

Meador Inge added the comment: > Yes, please let's not add any new __int__-based duck typing here; Mark, just to clarify a bit, the behavior is already there in the array module (by way of 'PyLong_AsLong'). The fact that it is there was picked up on a code review for this issue. Anyway, I t

[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()

Charles-François Natali added the comment: > I think I got it: pthread_setaffinity_np() does not crash. Nice. Out of curiosity, I just looked at the source code, and it just does sched_setaffinity(thread->tid), so you can do the same with sched_setaffinity(syscall(SYS_gettid)) for the current

[issue12936] armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()

Stefan Krah added the comment: I think I got it: pthread_setaffinity_np() does not crash. `man sched_setaffinity` is slightly ambiguous, but there is this remark: (If you are using the POSIX threads API, then use pthread_setaffinity_np(3) instead of sched_setaffinity().) I'm attachin

[issue12972] Color prompt + readline

New submission from Damian : Hi, when using terminal coloring codes (for instance '\x1b[32mhello world\x1b[0m' for a green 'hello world') the raw_input function and readline module behave well except under a very specific use case... import readline #

[issue12301] Use :role:`sys.thing` instead of ``sys.thing`` throughout

Georg Brandl added the comment: Basically, :class:`!Foo` has no advantage over ``Foo``. The no-linking syntax is really only there for completeness, but I would prefer the plainer and easier to read (in source) ``Foo``. For files, :file: really only has an advantage if you do something with t

[issue11473] upload command no longer accepts repository by section name

Éric Araujo added the comment: This is a strange bug. I added a test using -r server2, using the already-existing PYPIRC_LONG_PASSWORD string as .pypirc contents. The test passes. To make sure changing one test would not affect another one, I created a new .pypirc file, PYPIRC_CUSTOM_SERVE

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah added the comment: I wonder whether it is http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453. The demo script from there crashes both on debian-arm and Ubuntu Lucid, but this specific segfault only occurs on debian arm. Attached is a minimal C test case that only crashes on d

[issue12397] re match object methods have no docstrings

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue1757072] Zipfile robustness

Alan McIntyre added the comment: So far I haven't had the opportunity to sit down and write up a "lenient zipfile handling" patch; my apologies to those that could really use one. If somebody does propose a patch, I'll be glad to test and review it. I suppose I would like to see the issue ke

[issue1739648] zipfile.testzip() using progressive file reads

Alan McIntyre added the comment: I re-checked testzip-patch3.diff since some time has passed since I last commented on it, and it still seems to work ok (the small test_zipfile.py block failed to apply, but that's easy enough to do manually). Passes full test run, test_zipfile64.py, etc., on

[issue12301] Use :role:`sys.thing` instead of ``sys.thing`` throughout

Éric Araujo added the comment: Alright, I’ll propose piecemeal patches. Georg, two questions: 1) In the tutorial, should classes with no target use ``MyClass`` or :class:`!MyClass`? 2) Should file extensions use ``.py`` or :file:`.py`? We currently have both. -- _

[issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr

Alan McIntyre added the comment: I also can't see any file operations that might occur between the two .tell() calls, and a full test pass (including test_zipfile64) on the py3k development branch doesn't turn up any problems on Linux (2.6.38, x86_64) for me, so I agree the second .tell() cou

[issue8713] multiprocessing needs option to eschew fork() under Linux

sbt added the comment: Small fix to patch. -- Added file: http://bugs.python.org/file23142/mp_fork_exec.patch ___ Python tracker ___ _

[issue8713] multiprocessing needs option to eschew fork() under Linux

Changes by sbt : Removed file: http://bugs.python.org/file23141/mp_fork_exec.patch ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue12968] vvccc留查！！！

Changes by Benjamin Peterson : -- resolution: -> invalid status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue12970] os.walk() consider some symlinks as dirs instead of non-dirs

Changes by Марк Коренберг : -- title: os.wlak() consider some symlinks as dirs instead of non-dirs -> os.walk() consider some symlinks as dirs instead of non-dirs ___ Python tracker ___

[issue12971] os.isdir() should contain skiplinks=False in arguments

New submission from Марк Коренберг : When skiplinks is False (by default), it should as in current implementation, i.e. using stat(). if skiplinks is True, isidr() should use lstat() and same logick. If one will be implemented, os.walk() should be patched (see issue12970) to use this new isd

[issue12970] os.wlak() consider some symlinks as dirs instead of non-dirs

Марк Коренберг added the comment: Also, there is some mis-optimisation for followlinks=False: stat() and then lstat() will be called. Instead of one lstat(). Code may be rewritten as (but I don't know about cross-platform issues): - if followlinks: mode = os

[issue8713] multiprocessing needs option to eschew fork() under Linux

sbt added the comment: Here is a patch which adds the following functions: forking_disable() forking_enable() forking_is_enabled() set_semaphore_prefix() get_semaphore_prefix() To create child processes using fork+exec on Unix, call forking_disable() at the beginning of the program.

[issue12970] os.wlak() consider some symlinks as dirs instead of non-dirs

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

[issue12970] os.wlak() consider some symlinks as dirs instead of non-dirs

New submission from Марк Коренберг : Consider code: for (root, dirs, nondirs) in os.walk(path, followlinks=False): print (nondirs) This code will not print symlinks that refer to some dir. I think it is the bug. In other words: If followlinks is True, we should consider some symlinks as d

[issue12969] Command 'open(0, "wb").close()' cause crash of Python interpreter [interactive mode]

Ezio Melotti added the comment: fd support is intentional, see Modules/_io/_iomodule.c:318 OTOH closing sys.stdin doesn't exit Python, so I'm not sure why closing fd 0 should. I was also thinking about possible security implications of this, but if someone tries to pass '0' as filename, it w

[issue12967] AttributeError distutils\log.py

Éric Araujo added the comment: When will it raise an AttributeError? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue12785] list_distinfo_file is wrong

Changes by Éric Araujo : Removed file: http://bugs.python.org/file23065/fix-list_distinfo_files-2.diff ___ Python tracker ___ ___ Python-bugs-

[issue12785] list_distinfo_file is wrong

Changes by Éric Araujo : Removed file: http://bugs.python.org/file22948/fix-list_distinfo_files.diff ___ Python tracker ___ ___ Python-bugs-li

[issue12785] list_distinfo_file is wrong

Éric Araujo added the comment: I have added tests to make sure the return value (depending on the local parameter) is correct. Please test when you have a free slot. If it fails, the usual line after the XXX comment should be deleted and the test re-run. -- Added file: http://bugs.p

[issue5845] rlcompleter should be enabled automatically

Éric Araujo added the comment: FTR, I tried checking sys.ps1 instead of argv but it’s the same problem. -- ___ Python tracker ___ ___

[issue12915] Add inspect.locate and inspect.resolve

Éric Araujo added the comment: In addition, error handling/reporting is not trivial to get right. We’ve had to fix the code in distutils2 and it’s still not quite right (#12703). I opened this report because I’d like to see all stdlib modules use the same functions and I’d prefer people to c

[issue12936] armv5tejl: random segfaults in getaddrinfo()

STINNER Victor added the comment: > The failure was introduced by issue #12655 Wow, great job! crash.py looks like a libc and/or kernel bug. Can you try the glibc 2.14 (released the 2011-05-31)? You should first check if it is not a duplicate of http://sources.redhat.com/bugzilla/show_bug.cg

[issue12969] Command 'open(0, "wb").close()' cause crash of Python interpreter [interactive mode]

Jesús Cea Avión added the comment: In "help(open)" I see this: """ file is either a text or byte string giving the name (and the path if the file isn't in the current working directory) of the file to be opened or an integer file descriptor of the file to be wrapped. (If a file

[issue12969] Command 'open(0, "wb").close()' cause crash of Python interpreter [interactive mode]

Jesús Cea Avión added the comment: Under Python 3, open(integer) tries to open a file descriptor. So, "f=open(0,...); f.close()" closes stdin, rightly shutting down the interpreter. It is not a crash, it is a shutdown. Tested under Linux. The point is if opening a file descriptor is actually

[issue7201] double Endian problem and more on arm

Mark Dickinson added the comment: > I don't think it is practical to support both ABIs. I suspect you're right. -- ___ Python tracker ___ ___

[issue1172711] long long support for array module

Mark Dickinson added the comment: Yes, please let's not add any new __int__-based duck typing here; IMO, we should be moving away from such uses of __int__. I'd be fine with __index__ based duck-typing. -- ___ Python tracker

[issue1172711] long long support for array module

Changes by Mark Dickinson : -- versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue1813] Codec lookup failing under turkish locale

Stefan Krah added the comment: https://bugzilla.redhat.com/show_bug.cgi?id=726536 claims that the glibc issue (which is relevant for skipping the test case) is fixed in glibc-2.14.90-8. I suspect the only way of running the test case reliably is whitelisting a couple of known good glibc version

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah added the comment: And here's a full backtrace of crash.py: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x400225f0 (LWP 633)] 0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2 (gdb) bt #0 0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2 #

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Stefan Krah added the comment: The failure was introduced by issue #12655. I attach a minimal script to reproduce the segfault. -- nosy: +benjamin.peterson Added file: http://bugs.python.org/file23138/crash.py ___ Python tracker

[issue12969] Command 'open(0, "wb").close()' cause crash of Python interpreter [interactive mode]

Changes by Ezio Melotti : -- components: +IO nosy: +benjamin.peterson, ezio.melotti, pitrou, stutzbach stage: -> test needed versions: +Python 3.3 ___ Python tracker ___ ___