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

[Ezio Melotti]

Changes by Ezio Melotti :


--
components: +IO
nosy: +benjamin.peterson, ezio.melotti, pitrou, stutzbach
stage:  -> test needed
versions: +Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12936] armv5tejl: random segfaults in getaddrinfo()

[Stefan Krah]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12936] armv5tejl: random segfaults in getaddrinfo()

[Stefan Krah]

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
#1  0x40035a14 in __h_errno_location () from /lib/libpthread.so.0
#2  0x40a788dc in __libc_res_nsearch () from /lib/libresolv.so.2
#3  0x40a66e9c in _nss_dns_gethostbyname3_r () from /lib/libnss_dns.so.2
#4  0x40a670ac in _nss_dns_gethostbyname2_r () from /lib/libnss_dns.so.2
#5  0x40180480 in gaih_inet () from /lib/libc.so.6
#6  0x40181da8 in getaddrinfo () from /lib/libc.so.6
#7  0x406084a4 in socket_getaddrinfo (self=0x405d7bcc, args=0x4089a8b4, 
kwargs=0x0)
at /home/user/mercurial-1.9.2/cpython/Modules/socketmodule.c:4787
#8  0x001ea384 in PyCFunction_Call (func=0x405da1f4, arg=0x4089a8b4, kw=0x0)
at Objects/methodobject.c:84
#9  0x000a3634 in call_function (pp_stack=0xbeab7d1c, oparg=4)
at Python/ceval.c:4000
#10 0x0009cab8 in PyEval_EvalFrameEx (f=0x407457b4, throwflag=0)
at Python/ceval.c:2625
#11 0x000a0bfc in PyEval_EvalCodeEx (_co=0x405d6ab8, globals=0x40591a34, 
locals=0x0, args=0x408884dc, argcount=2, kws=0x408884e4, kwcount=0, 
defs=0x40512a20, defcount=2, kwdefs=0x0, closure=0x0)
at Python/ceval.c:3375
#12 0x000a3cfc in fast_function (func=0x405e30e4, pp_stack=0xbeab8068, n=2, 
na=2, nk=0) at Python/ceval.c:4098
#13 0x000a3838 in call_function (pp_stack=0xbeab8068, oparg=2)
---Type  to continue, or q  to quit---
at Python/ceval.c:4021
#14 0x0009cab8 in PyEval_EvalFrameEx (f=0x40888374, throwflag=0)
at Python/ceval.c:2625
#15 0x000a0bfc in PyEval_EvalCodeEx (_co=0x4089d5d8, globals=0x4088d854, 
locals=0x0, args=0x404e2ac8, argcount=2, kws=0x405b43c8, kwcount=2, 
defs=0x4098fbd0, defcount=6, kwdefs=0x0, closure=0x0)
at Python/ceval.c:3375
#16 0x001c3060 in function_call (func=0x40a2dea4, arg=0x404e2ab4, 
kw=0x409a98f4) at Objects/funcobject.c:629
#17 0x0017f1a0 in PyObject_Call (func=0x40a2dea4, arg=0x404e2ab4, 
kw=0x409a98f4) at Objects/abstract.c:2149
#18 0x001a1a9c in method_call (func=0x40a2dea4, arg=0x404e2ab4, kw=0x409a98f4)
at Objects/classobject.c:318
#19 0x0017f1a0 in PyObject_Call (func=0x4050b9d4, arg=0x404e2574, 
kw=0x409a98f4) at Objects/abstract.c:2149
#20 0x0004a6c0 in slot_tp_init (self=0x405ae504, args=0x404e2574, 
kwds=0x409a98f4) at Objects/typeobject.c:5431
#21 0x00037650 in type_call (type=0x40a31034, args=0x404e2574, kwds=0x409a98f4)
at Objects/typeobject.c:691
#22 0x0017f1a0 in PyObject_Call (func=0x40a31034, arg=0x404e2574, 
kw=0x409a98f4) at Objects/abstract.c:2149
#23 0x000a46bc in do_call (func=0x40a31034, pp_stack=0xbeab84f0, na=1, nk=2)
at Python/ceval.c:4220
#24 0x000a3858 in call_function (pp_stack=0xbeab84f0, oparg=513)
at Python/ceval.c:4023
#25 0x0009cab8 in PyEval_EvalFrameEx (f=0x40558544, throwflag=0)
at Python/ceval.c:2625
#26 0x000a0bfc in PyEval_EvalCodeEx (_co=0x40479d28, globals=0x403d5034, 
locals=0x403d5034, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375
#27 0x000916f4 in PyEval_EvalCode (co=0x40479d28, globals=0x403d5034, 
locals=0x403d5034) at Python/ceval.c:770
#28 0x000e0cb4 in run_mod (mod=0x37c8f8, filename=0x405028c8 "crash.py", 
globals=0x403d5034, locals=0x403d5034, flags=0xbeab8864, arena=0x2e5178)
at Python/pythonrun.c:1793
#29 0x000e0a58 in PyRun_FileExFlags (fp=0x2ce260, 
filename=0x405028c8 "crash.py", start=257, globals=0x403d5034, 
locals=0x403d5034, closeit=1, flags=0xbeab8864) at Python/pythonrun.c:1750
#30 0x000debcc in PyRun_SimpleFileExFlags (fp=0x2ce260, 
filename=0x405028c8 "crash.py", closeit=1, flags=0xbeab8864)
at Python/pythonrun.c:1275
#31 0x000dde68 in PyRun_AnyFileExFlags (fp=0x2ce260, 
filename=0x405028c8 "crash.py", closeit=1, flags=0xbeab8864)
at Python/pythonrun.c:1046
#32 0x000ff984 in run_file (fp=0x2ce260, filename=0x401fe028, p_cf=0xbeab8864)
at Modules/main.c:299
#33 0x00100780 in Py_Main (argc=2, argv=0x401fc028) at Modules/main.c:693
#34 0x0001a914 in main (argc=2, argv=0xbeab8994) at ./Modules/python.c:59

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1813] Codec lookup failing under turkish locale

[Stefan Krah]

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 versions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1172711] long long support for array module

[Mark Dickinson]

Changes by Mark Dickinson :


--
versions: +Python 3.3 -Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1172711] long long support for array module

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7201] double Endian problem and more on arm

[Mark Dickinson]

Mark Dickinson  added the comment:

> I don't think it is practical to support both ABIs.

I suspect you're right.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jesús Cea Avión]

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 supported in Python 3...

In python 2.7 I get this: "TypeError: coercing to Unicode: need string or 
buffer, int found".

--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jesús Cea Avión]

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 descriptor is given, it is closed when the
returned I/O object is closed, unless closefd is set to False.)
"""

So, file descriptors are allowed.

The interpreter shutdowns because your are closing STDIN. This is correct, in 
my opinion.

Closing this bug as "invalid". If you think this is an error, feel free to 
argue.

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12936] armv5tejl: random segfaults in getaddrinfo()

[STINNER Victor]

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.cgi?id=12453

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12915] Add inspect.locate and inspect.resolve

[Éric Araujo]

É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 copy-paste the same robust code for 
backports.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Éric Araujo]

Éric Araujo  added the comment:

FTR, I tried checking sys.ps1 instead of argv but it’s the same problem.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12785] list_distinfo_file is wrong

[Éric Araujo]

É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.python.org/file23139/fix-list_distinfo_files.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12785] list_distinfo_file is wrong

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file22948/fix-list_distinfo_files.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12785] list_distinfo_file is wrong

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file23065/fix-list_distinfo_files-2.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12967] AttributeError distutils\log.py

[Éric Araujo]

Éric Araujo  added the comment:

When will it raise an AttributeError?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

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 will most likely be passed to open as 
a string.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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 
dirs. If not, any symlink is the non-dir.

Patch included.

Also, please fix documentation about this nuance.

--
assignee: docs@python
components: Documentation, Library (Lib)
files: z.patch
keywords: patch
messages: 143965
nosy: docs@python, mmarkk
priority: normal
severity: normal
status: open
title: os.wlak() consider some symlinks as dirs instead of non-dirs
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23140/z.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[sbt]

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.

I have tested the patch on Linux (by adding forking_disable() to
test_multiprocessing), and it seems to work.  However, the patch does
not modify test_multiprocessing, and I am not sure of the best way to
do so.  (See below.)

There are some issues with named semaphores.  When forking is
disabled, the name of the semaphore must be left unlinked so that
child processes can use sem_open() on the name.  The patch therefore
delays unlinking the name (only when forking is disabled) until the
original SemLock object is garbage collected or the process which
created it exits.

But if a process is killed without exiting cleanly then the name may
be left unlinked.  This happens, for instance, if I run
test_multiprocessing and then keep hitting ^C until all the processes
exit.  On Linux this leaves files with names like

  /dev/shm/sem.mp-fa012c80-4019-2

which represent leaked semaphores.  These won't be destroyed until the
computer reboots or the semaphores are manually removed (by using
sem_unlink() or by unlinking the entry from the file system).

If some form of this patch is accepted, then the problem of leaked
semaphores needs to be addressed, otherwise the buildbots are likely
run out of named semaphores.  But I am not sure how best to do this in
a platform agnostic way.  (Maybe a forked process could collect names
of all semaphores created, via a pipe.  Then it could try to
sem_unlink() all those names when all write-ends of the pipe are
closed.)

--
keywords: +patch
nosy: +sbt
Added file: http://bugs.python.org/file23141/mp_fork_exec.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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.stat(path).st_mode
else:
mode = os.lstat(path).st_mode

if stat.S_ISDIR(mode):
dirs.append(path)
else:
nondir.append(path)
-
It will be much cleaner than current (or patched with my patch) implementation

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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 isdir() with this new parameter instead of own logick in os.walk().

--
components: Library (Lib)
messages: 143968
nosy: mmarkk
priority: normal
severity: normal
status: open
title: os.isdir() should contain skiplinks=False in arguments
type: feature request
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12968] vvccc留查！！！

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[sbt]

Changes by sbt :


Removed file: http://bugs.python.org/file23141/mp_fork_exec.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[sbt]

sbt  added the comment:

Small fix to patch.

--
Added file: http://bugs.python.org/file23142/mp_fork_exec.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alan McIntyre]

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() could be removed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alan McIntyre]

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 Linux x86_64.

If there is something about the patch that still needs to be addressed before 
it can be committed, let me know and I'll see what I can do.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1757072] Zipfile robustness

[Alan McIntyre]

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 kept open for a while, even if just to 
collect common "bending of the rules" cases that people would like to see 
supported.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12397] re match object methods have no docstrings

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12936] armv5tejl: random segfaults in getaddrinfo()

[Stefan Krah]

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 debian-arm
when sched_setaffinity() is called *and* the program is linked to
pthread:


$ gcc -Wall -W -O0 -g -o crash crash.c
$ ./crash
$
$ gcc -Wall -W -O0 -g -o crash crash.c -pthread
$ ./crash
Segmentation fault (core dumped)

# comment out: sched_setaffinity(0, size, cpusetp);

$ gcc -Wall -W -O0 -g -o crash crash.c -pthread
$ ./crash
$ 


On Ubuntu all three cases run fine. Perhaps this is a bug in
sched_setaffinity()?

--
Added file: http://bugs.python.org/file23143/crash.c

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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_SERVER, and then I got to see your bug!  I 
tried various combinations of keys (realm or not, user or not), changed the 
markup (: or = as delimiter, spaces or not) but could not easily find the root 
of the bug.

Can you publish a .pypirc file that works with 2.7 and not with 3.2?  That 
would be a good starting point.

--
keywords: +patch
Added file: http://bugs.python.org/file23144/test-11473-py32.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

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 the 
information that it's a file (which we don't, currently), or if you use the 
special feature that you can embed variable parts with {}.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12972] Color prompt + readline

[Damian]

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 # provides history via up/down

prompt = '\x1b[32m>>> \x1b[0m' # green '>>> ' prompt

while True:
  raw_input(prompt)



This provides a green prompt and up/down cycles through prior input. This works 
well as long as the input is shorter than the prompt string length (in this 
case 13 characters). However, if the input is longer than the prompt then 
up/down thinks that the first thirteen rendered characters now belong to the 
prompt. For instance...

atagar@fenrir:~/Desktop/arm$ python tmp.py 
>>> http://docs.python.org/library/readline

Press up, then down to get back to a blank prompt. You'll have...
>>> http://do

This is probably due to a len() check on the raw_input argument...
>>> len('>>> http://do')
13
>>> len('\x1b[32m>>> \x1b[0m')
13

I'm at a bit of a loss for investigating this further - help would be 
appreciated! -Damian

--
messages: 143977
nosy: atagar1
priority: normal
severity: normal
status: open
title: Color prompt + readline
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stefan Krah]

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 attaching the non-crashing version.

--
title: armv5tejl: random segfaults in getaddrinfo() -> armv5tejl segfaults: 
sched_setaffinity() vs. pthread_setaffinity_np()
Added file: http://bugs.python.org/file23145/pthread_nocrash.c

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Charles-François Natali]

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 thread.
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.
Furthermore, even though we're linked with pthread, this should normally 
succeed - or at least not crash - when called from the main thread - and it 
does on my Debian squeeze box.
So I'd suggest closing this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1172711] long long support for array module

[Meador Inge]

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 think we should open a new issue to track the '__index__' vs. 
'__int__' stuff.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 threading.get_ident() to easily get the thread identifier. In Python < 
3.3, you can use threading.current_thread().ident.

It's not documented, but if you pass a random integer, signal.pthread_kill() 
does crash.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12785] list_distinfo_file is wrong

[Jeremy Kloth]

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 so on) are incorporated.

--
nosy: +jkloth

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1172711] long long support for array module

[Mark Dickinson]

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, 3])

That's the new duck typing I meant.  I see this acceptance of things with an 
__int__ method as a mistake, and my gut reaction earlier was that it seems 
wrong to propagate that mistake into the new long long functionality, even 
though it's already present in other places in the array module.

On second thoughts though, it would be a peculiar inconsistency to be able to 
pass Decimal objects to array('L', ...) but not to array('Q', ...).  So 
probably better to accept this behaviour for now, and open another issue for 
the __int__ / __index__ discussion, as you suggest.

BTW, the patch and tests look good to me, and all tests pass here (OS X !0.6, 
64-bit) (Well, not quite true, but I fail to see how these changes could be 
responsible for the test_socket and test_packaging failures I'm seeing :-).  I 
get compile-time warnings from the 'int' declarations that should be 
'Py_ssize_t', but I understand that's taken care of already...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stefan Krah]

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_gettid), size, cpusetp) crashes, too.
This seems to be a violation of the man page, which states:

"The value returned from a call to gettid(2) can be passed in
 the argument pid."

Unless one uses a somewhat warped interpretation that linking
against pthread constitutes "using the POSIX threads API". That
would be the only loophole that would allow the crash.

> 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.

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.

> So I'd suggest closing this issue.

I don't care strongly about using pthread_getaffinity_np(), but at least I'd
like to skip the scheduling sections on arm-linux if they don't work reliably.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12973] int_pow() implementation is incorrect

[Adam]

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 find out the details:
http://llvm.org/bugs/show_bug.cgi?id=10923

--
messages: 143985
nosy: a...@netbsd.org
priority: normal
severity: normal
status: open
title: int_pow() implementation is incorrect
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12973] int_pow() implementation is incorrect

[Stefan Krah]

Stefan Krah  added the comment:

I think this is related to issue #11149. Can you try compiling with
-fwrapv?

--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12720] Expose linux extended filesystem attributes

[Arfrever Frehtes Taifersar Arahesis]

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(), setxattr() and other functions.
Modules/posixmodule.c includes attr/xattr.h from attr package, but 
libpython3.3.so isn't linked against libattr.so and is linked against libc.so, 
so functions from glibc are used at run time.

I suggest to use sys/xattr.h:
- sys/xattr.h instead of attr/xattr.h in Modules/posixmodule.c, configure, 
configure.in and pyconfig.h.in
- HAVE_SYS_XATTR_H instead of HAVE_ATTR_XATTR_H in Modules/posixmodule.c and 
pyconfig.h.in

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Charles-François Natali]

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 passing an 
invalid thread ID, which IMHO, should be avoided at all cost
- to be safe, we would need to have a different API depending on whether Python 
is built with threads or not (i.e. sched_setaffinity() without threads, and 
pthread_setaffinity_np())
- pthread_setaffinity_np() is really non-portable (it's guarded by __USE_GNU in 
my system's header)
- sched_setaffinity() seems to work fine on most systems even when linked with 
pthread

> I don't care strongly about using pthread_getaffinity_np(), but at least I'd
> like to skip the scheduling sections on arm-linux if they don't work reliably.

Sounds reasonable.
I guess you could use os.uname() or platform.machine().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12720] Expose linux extended filesystem attributes

[Roundup Robot]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12973] int_pow() implementation is incorrect

[Stefan Krah]

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
stage:  -> committed/rejected
status: open -> closed
superseder:  -> [PATCH] Configure should enable -fwrapv for clang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stefan Krah]

Changes by Stefan Krah :


--
nosy: +a...@netbsd.org, skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stefan Krah]

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
-9223372036854775808
>>> 2**64
0
>>> 


The patch is fine and I'm going to commit it tomorrow if there are no
objections.

--
priority: high -> critical

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 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 see how: pthread_kill(tid, 0) is supposed to check if tid exists, but it 
does crash...

> to be safe, we would need to have a different API depending
> on whether Python is built with threads or not
> (i.e. sched_setaffinity() without threads,
> and pthread_setaffinity_np())

We cannot use the same name for two different C function. One expects a process 
identifier, whereas the other expects a thread identifier! If Python is 
compiled without thread, the thread will not exist (as some modules and many 
other functions).

> pthread_setaffinity_np() is really non-portable
> (it's guarded by __USE_GNU in my system's header)

We can check it in configure. We already use some functions which are GNU 
extensions, like makedev(). Oh, os.makedev() availability is just not 
documented :-)

> sched_setaffinity() seems to work fine on most systems
> even when linked with pthread

Again, it looks like a libc/kernel bug. I don't think that Python can work 
around such issue.

> I don't care strongly about using pthread_getaffinity_np()

I don't really care of pthread_getaffinity_np() :-) To add a new function, we 
need a usecase and it should be requested. This issue is about a crash using 
sched_setaffinity(), not about pthread_getaffinity_np.

I don't know or need (), but the difference between sched_setaffinity and 
pthread_getaffinity_np is the same between sigprocmask() and pthread_sigmask(). 
I chose to expose only the later because the behaviour of sigprocmask is 
undefined in a process using threads. sched_setaffinity manual contains the 
sentence "If you are using the POSIX threads API, then use 
pthread_setaffinity_np(3) instead of sched_setaffinity()".

See also Portable Hardware Locality (hwloc):
http://www.open-mpi.org/projects/hwloc/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

STINNER Victor  added the comment:

So, can we close this issue?

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8828] Atomic function to rename a file

[STINNER Victor]

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 usages deal with newly created files, or overwriting existing 
files. A newly created file may require an fsync() of not just the file itself, 
but also of the directory in which it was created (since this is where the file 
system looks to find your file). This behavior is actually file system (and 
mount option) dependent. You can either code specifically for each file system 
and mount option combination, or just perform fsync() calls on the directories 
to ensure that your code is portable."

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12960] threading.Condition is not a class

[STINNER Victor]

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 condition 
variable allows one or more threads to wait until they are notified by another 
thread.

See Condition Objects."

It has been changed in Python 3.3 (#10968): threading.Condition is now a class, 
instead of a factory.

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 they are notified by another 
thread.

See Condition Objects."

--

See also (maybe) issue #12960.

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12960] threading.Condition is not a class

[Nikolaus Rath]

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 doc:
> 
> "threading.Condition()
> A factory function that returns a new condition variable object. A condition 
> variable allows one or more threads to wait until they are notified by 
> another thread.
> 
> See Condition Objects."

Yes, but further down it still says:

"""
class threading.Condition([lock])

If the lock argument is given and not None, []
"""

Best,

   -Nikolaus

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12930] reindent.py inserts spaces in multiline literals

[Caio Romão]

Changes by Caio Romão :


Removed file: http://bugs.python.org/file23118/caioromao-fix-12930-v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12930] reindent.py inserts spaces in multiline literals

[Caio Romão]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Meador Inge]

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
... def __int__(self):
...  return self.value
...
>>> a = array.array('L', [1,2,3])
>>> struct.pack_into('L', a, 0, 9)
>>> a
array('L', [9, 2, 3])
>>> a[0] = T(100)
>>> a
array('L', [100, 2, 3])

As discussed in issue1172711, this behavior may not be desirable.  We should 
look at deprecating '__int__' and adding '__index__' as was done for the struct 
module in issue1530559.

--
components: Library (Lib)
messages: 144000
nosy: mark.dickinson, meadori, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: array module: deprecate '__int__' conversion support for array elements
type: behavior
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1172711] long long support for array module

[Meador Inge]

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 gut
> reaction earlier was that it seems wrong to propagate that mistake into the 
> new long long functionality, even though it's already
> present in other places in the array module.
>
> On second thoughts though, it would be a peculiar inconsistency to be able to 
> pass Decimal objects to array('L', ...) but not
> to array('Q', ...).  So probably better to accept this behaviour for now, and 
> open another issue for the __int__ / __index__ discussion,
> as you suggest.

... I had this inconsistency in mind.  I opened issue12974 for the
__int__/__index__ problem.

Now we just have to figure out which issue gets fixed first :-D  I am
OK with applying the fix for this issue first.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12967] AttributeError distutils\log.py

[ben]

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] AttributeError distutils\log.py

Éric Araujo  added the comment:

When will it raise an AttributeError?

--

___
Python tracker 

___

--
Added file: http://bugs.python.org/file23147/unnamed

___
Python tracker 

___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.comSent: Tuesday, 13 September 2011 8:54 PMSubject: [issue12967] AttributeError 
distutils\log.pyÉric Araujo mer...@netwok.org> added the 
comment:When will it raise an 
AttributeError?--___Python
 tracker
 rep...@bugs.python.org>http://bugs.python.org/issue12967>__
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1172711] long long support for array module

[Meador Inge]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1621] Do not assume signed integer overflow behavior

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1947] Exception exceptions.AttributeError '_shutdown' in

[Brandon Craig Rhodes]

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 Standard Library module. This upsets the Python exit logic, which 
tries to run `threading._shutdown()` if `threading` exists in `sys.modules`. I 
just helped someone on Stack Overflow with a situation like this, which in that 
case resulted from an error in how `pylint` works.

--
nosy: +brandon-rhodes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ned Deily]

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 --prefix which is referenced directly (and 
indirectly via derived variables) throughout Makefile.pre.in and currently the 
Makefile does not handle installing a standard Unix-style build on any platform 
to prefix path that includes spaces, much less a Mac framework build.  That is 
the following will fail during the install phases:

./configure --prefix="/path/with space"
make && make install

This needs to be addressed first, primarily by quote-protecting all uses of 
prefix and its derivatives in Makefile shell rules and then the uses of 
PYTHONFRAMEWORK* variables in the Makefile also need to be protected.  It 
should be fairly straightforward to find all such uses but there are many of 
them and changes would affect all platforms that use the Makefile to build and 
the many variants for each platform (i.e. --enable-shared, --enable-framework, 
etc) so proper testing would be a major effort.

While I'm sympathetic to supporting arbitrary path names, I'm not sure if it is 
worth the effort.  I'm going to leave this open for now but I don't plan to 
work on it myself in the near future.

--
assignee: ned.deily -> 
components:  -Macintosh
priority: normal -> low
title: 2.7.2 build fails with --enable-framework and space in pathname on OS X 
10.7.1 -> builds fail when installing to --prefix with space in path name

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12881] ctypes: segfault with large structure field names

[Meador Inge]

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, (Structure,), {})
>>> p = POINTER(T)
Segmentation fault (core dumped)

>>> from ctypes import *
>>> p = POINTER('x' * 2 ** 25)
Segmentation fault (core dumped)

>>> from ctypes import *
>>> NARGS = 2 ** 20
>>> proto = CFUNCTYPE(None, *(c_int,) * NARGS)
>>> def func(*args):
...return (1, "abc", None)
... 
>>> cb = proto(func)
>>> cb(*(1,) * NARGS)
Segmentation fault (core dumped)

I will fix those too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stefan Behnel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1621] Do not assume signed integer overflow behavior

[Alex Gaynor]

Changes by Alex Gaynor :


--
nosy: +alex

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12857] Expose called function on frame object

[Eric Snow]

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_EvalCodeEx() into a very light wrapper around 
_PyEval_EvalFunctionCode().  This is how I tackled the backwards 
incompatibility of my previous patch.  However, I am nervous about messing 
around with something like PyEval_EvalCodeEx().

I was toying with the idea of doing a more comprehensive refactor involving 
call_function, fast_function, and do_call, which seems like it would be a 
better fix.  However, I'm even more reticent to make that scale of changes, 
especially on something so critical, even if it seems right to me currently.

I figured the safe thing for now would be to name the new function with a 
leading underscore to mark it as private.

Here are the results from my cursory check before and after my latest patch:

BEFORE
3 tests failed:
test_distutils test_packaging test_socket
[293234 refs]
real14m40.578s
user11m43.547s
sys 0m52.096s

AFTER
3 tests failed:
test_distutils test_packaging test_socket
[293171 refs]
real14m33.785s
user11m55.437s
sys 0m53.850s

--
Added file: http://bugs.python.org/file23149/called_function_2.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Charles-François Natali]

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 see how: pthread_kill(tid, 0) is supposed to check if tid 
> exists, but it does crash...

No, I don't suggest to remove it, it is useful.
As for the crashes, with glibc pthread_t is really a pointer, so
there's no way to check its validity beforehand. Even if we did check
the thread ID against the list of Python-created threads IDs (stored
in Thread._ident), this could still crash, because the ID becomes
invalid as soon as the thread terminates (all threads are started
detached). Furthermore, this wouldn't work for non-Python created
threads.

> We cannot use the same name for two different C function. One expects a 
> process identifier, whereas the other expects a thread identifier! If Python 
> is compiled without thread, the thread will not exist (as some modules and 
> many other functions).
>

I know, that's why I said "different API": but I must admit it was
poorly worded ;-)
However, this wouldn't solve this particular problem: as long as we
expose sched_setaffinity(), it will crash as soon as someone passes
`0` or getpid() as PID.

>> pthread_setaffinity_np() is really non-portable
>> (it's guarded by __USE_GNU in my system's header)
>
> We can check it in configure. We already use some functions which are GNU 
> extensions, like makedev(). Oh, os.makedev() availability is just not 
> documented :-)

As I said, this wouldn't solve this problem. If someone deems it
necessary, we can open another issue for this feature request.

>> sched_setaffinity() seems to work fine on most systems
>> even when linked with pthread
>
> Again, it looks like a libc/kernel bug. I don't think that Python can work 
> around such issue.
>

Agreed.

> I don't know or need (), but the difference between sched_setaffinity and 
> pthread_getaffinity_np is the same between sigprocmask() and 
> pthread_sigmask(). I chose to expose only the later because the behaviour of 
> sigprocmask is undefined in a process using threads.

Exactly.
However, nothing prevents someone from using sigprocmask() in a
multithreaded process, the only difference is that it won't crash
(AFAICT).

So I suggest to:
1) skip the problematic tests on ARM when built with threads to avoid segfaults
2) if someone wants pthread_getaffinity_np(), then we can still open a
separate feature request

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexey Smirnov]

Changes by Alexey Smirnov :


--
nosy: +alexey-smirnov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexey Smirnov]

Changes by Alexey Smirnov :


--
nosy: +alexey-smirnov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12975] Invitation to connect on LinkedIn

[Charles-François Natali]

Changes by Charles-François Natali :


--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12975] Invitation to connect on LinkedIn

[Charles-François Natali]

Changes by Charles-François Natali :


Removed file: http://bugs.python.org/file23150/unnamed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12975] Invitation to connect on LinkedIn

[Ezio Melotti]

Changes by Ezio Melotti :


--
Removed message: http://bugs.python.org/msg144010

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12975] spam

[Ezio Melotti]

Changes by Ezio Melotti :


--
stage:  -> committed/rejected
title: Invitation to connect on LinkedIn -> spam

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8828] Atomic function to rename a file

[Charles-François Natali]

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 atomicity, i.e. the file is visible either 
under its old name or its new name, but not neither or both.
If is however needed if you want durability, i.e. you want to guarantee that 
the file is visible under its new name after your atomic_rename returns.

--
nosy: +neologix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com