[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

[Mark Dickinson]

Mark Dickinson  added the comment:

It might be instructive to look at how NumPy itself manages sharing of ndarray 
data and ownership of the corresponding structs.  I meant to find time to look 
at this over the break.

--

___
Python tracker 

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

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

[Mark Dickinson]

Mark Dickinson  added the comment:

BTW, I agree that it looks as though significant changes might be needed.  I 
wonder whether it would make sense to exclude the Py_buffer struct fro m the 
Stable ABI PEP for now.

--

___
Python tracker 

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

[issue10760] tarfile doesn't handle sysfs well

[Lars Gustäbel]

Changes by Lars Gustäbel :


--
assignee:  -> lars.gustaebel
components: +Library (Lib) -None
nosy: +lars.gustaebel

___
Python tracker 

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

[issue10761] tarfile.extractall fails to overwrite symlinks

[Lars Gustäbel]

Changes by Lars Gustäbel :


--
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

___
Python tracker 

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

[issue10516] Add list.clear() and list.copy()

[Georg Brandl]

Changes by Georg Brandl :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue10821] gethostbyname(gethostname()) is wrong when IP is changed

[Petr Sklenář]

New submission from Petr Sklenář :

version:
tried python 2.6 on rhel55
tried python-2.7-8 on fedora14

Steps to Reproduce:
1. install machine, have a fixed hostname up to mac address
1.1.1.1 = machine.something.com

2. wait a week or longer when your local dhcp server changes your IP but not
hostname
1.1.1.159 = machine.something.com

[r...@machine.something.com ~]# host machine.something.com
machine.something.com has address 1.1.1.159

ifconfig shows the same

3.   gethostbyname(gethostname()) shows wrong IP, the original one

Actual results:
[r...@machine.something.com ~]# python
Python 2.4.3 (#1, Jun 11 2009, 14:09:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from socket import gethostname
>>> from socket import gethostbyname
>>> gethostname()
'machine.something.com'
>>> gethostbyname(gethostname())
'1.1.1.1'
>>>

Expected results:
gethostbyname(gethostname()) will return your actual IP, 1.1.1.159

Other:
1.1.1.1 = machine.something.com is added in /etc/hosts in the time of OS 
installation , then its not changed

--
components: IO
messages: 125298
nosy: psklenar
priority: normal
severity: normal
status: open
title: gethostbyname(gethostname()) is wrong when IP is changed
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

[issue5945] PyMapping_Check returns 1 for lists

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Right, calling PyMapping_Check() was never particularly reliable, and
> extension modules depending on it probably always had subtle bugs. 

> Perhaps it would be nice if we provided a C API to at least some of
> the ABC package.

In the meantime, would it be reasonable to add the moral equivalent of 
`hasattr(type(op), 'items')` to PyMapping_Check()?

--

___
Python tracker 

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

[issue10821] gethostbyname(gethostname()) is wrong when IP is changed

[Georg Brandl]

Georg Brandl  added the comment:

This is not a Python issue.  gethostbyname() and gethostname() are just a 
wrapper for the OS's functions of the same name; you'd get the same result when 
coding the example in C.

--
nosy: +georg.brandl
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

[issue10819] ValueError on repr(closed_socket_file)

[STINNER Victor]

STINNER Victor  added the comment:

Fixed by r87730.

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

[issue10785] parser: store the filename as an unicode object

[STINNER Victor]

STINNER Victor  added the comment:

err_clear() should set err->filename to NULL.

--
versions:  -Python 3.2

___
Python tracker 

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

[issue10822] test_getgroups failure under Solaris

[Antoine Pitrou]

New submission from Antoine Pitrou :

Under OpenSolaris, I get the following failure:

$ pfexec ./python -m test test_posix
[1/1] test_posix
test test_posix failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/cc/Lib/test/test_posix.py", line 402, in 
test_getgroups
set(posix.getgroups()))
AssertionError: Items in the first set but not the second:
0

--
components: Tests
messages: 125303
nosy: jcea, laca, pitrou, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: test_getgroups failure under Solaris
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue9344] please add posix.getgrouplist()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I can't say anything about the functionality, but the patch looks good to me 
(works under Linux and Solaris - the latter missing getgrouplist()).

--
nosy: +pitrou
stage: needs patch -> commit review

___
Python tracker 

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

[issue9535] Pending signals are inherited by child processes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Yes I'd do it in PyOS_AfterFork.  Simpler patch based on gdb's
> attached.

Private functions shouldn't use the PyXX_CamelCase() convention :)
Otherwise, looks good.

--

___
Python tracker 

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

[issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> that race condition, if thats what this is, is likely not OS X
> specific.  the child process could complete or close its fds before we
> reach that code on any OS.  We either need to guard these
> io.open(p2c*...) lines against EBADF OSError's or we should create the
> io wrappers before _execute_child() is called.

Creating them before _execute_child() is the obvious and simple solution
(if my diagnosis is correct). Is there any downside to doing so?

--

___
Python tracker 

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

[issue8992] convertsimple() doesn't need to call converterr() if an exception was already raised

[STINNER Victor]

STINNER Victor  added the comment:

Fixed by r87732

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

[issue8992] convertsimple() doesn't need to call converterr() if an exception was already raised

[STINNER Victor]

STINNER Victor  added the comment:

(and by r87731)

--

___
Python tracker 

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

[issue8719] buildbot: segfault on FreeBSD (signal 11)

[STINNER Victor]

STINNER Victor  added the comment:

> That may be what you meant, but "installed on this host" made me think
> I could do something external on the buildbot which I don't 
> think would work given that the module has to be called from within
> the tests themselves?

If you install faulthandler on "x86 FreeBSD 7.2 3.x" buildbot, I can create a 
special branch to add specific code.

Or I can add:

try:
import faulthandler
except ImportError:
pass
else:
faulthandler.enable()

In py3k (eg. in Lib/test/support.py).

But the problem is now different: it looks like the bug was fixed, I don't see 
crashes anymore on  "x86 FreeBSD 7.2 3.x" buildbot :-)

There was failures on test_concurrent_futures, but Martin fixed it in #10798 
(not completly (?) but it's better).

I close the issue because it looks like the crash was fixed. Reopen the issue 
if the crash occurs again.

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

[issue10823] "conversion from 'Py_ssize_t' to 'int', possible loss of data" in various files

[STINNER Victor]

New submission from STINNER Victor :

On "AMD64 Windows Server 2008 3.x", there are many "conversion from 
'Py_ssize_t' to 'int', possible loss of data" errors:


Python\Python-ast.c(3403) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3409) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3439) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3445) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3498) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3504) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3606) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3612) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3631) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3637) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3697) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3703) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3722) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3728) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3769) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3775) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3794) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3800) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3853) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3859) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3890) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3896) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4014) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4020) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4039) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4045) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4090) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4096) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4115) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4121) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4165) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4171) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4190) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4196) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4251) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4257) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4324) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4330) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4349) : warning C4244: 'function' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4355) : warning C4244: 'initializing' : conversion from 
'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4374) : warning

[issue10823] "conversion from 'Py_ssize_t' to 'int', possible loss of data" in various files

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
resolution:  -> duplicate
status: open -> closed
superseder:  -> Compilation warnings under x64 Windows

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[Ralf Schmitt]

Changes by Ralf Schmitt :


--
nosy: +schmir

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[STINNER Victor]

STINNER Victor  added the comment:

r87733 fixes some conversions in:

 * Python/pythonrun.c
 * Objects/codeobject.c
 * Objects/typeobject.c
 * Objects/listobject.c
 * Modules/_ctypes/_ctypes.c
 * Modules/sha512module.c
 * Modules/unicodedata.c
 * Modules/selectmodule.c
 * Modules/pyexpat.c
 * Modules/audioop.c
 * Modules/sha1module.c
 * Modules/sha256module.c
 * Modules/_testcapimodule.c
 * Modules/md5module.c

For md5, sha1, sha256 and sha512: a smaller type (int) can be used for the 
local n variable. I don't know if it impacts performances or not. md5 and sha1 
used "unsigned long", sha256 and sha512 used "int".

--
nosy: +haypo

___
Python tracker 

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

[issue10512] regrtest ResourceWarning - unclosed sockets and files

[Nadeem Vawda]

Nadeem Vawda  added the comment:

r87710 introduces a ResourceWarning in test_threading. Fix attached.

--

___
Python tracker 

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

[issue10512] regrtest ResourceWarning - unclosed sockets and files

[Nadeem Vawda]

Changes by Nadeem Vawda :


Added file: http://bugs.python.org/file20255/test_threading.diff

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[STINNER Victor]

STINNER Victor  added the comment:

r87734 fixes stdprinter.write().

--

___
Python tracker 

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

[issue9554] test_argparse.py: use new unittest features

[Sandro Tosi]

Sandro Tosi  added the comment:

Hi, I've applied the patch and it goes fine (except for some offsets and the 
fact it was generated inside Lib/test) and the tests are still all ok. I'd 
suggest to apply it.

--
nosy: +sandro.tosi
stage:  -> commit review

___
Python tracker 

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

[issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47

[Sandro Tosi]

Sandro Tosi  added the comment:

Ok, so the situation is:

- I've test on debian sid and it works fine
- Dave on a Fedora 13 and it works
- I asked a couple of guys to try it on their systems, that's Fedora14 and 
Gentoo and it works fine

So I think we can conclude it's a Fedora Core 4 specific problem (that's EOL 
tho).

I'm closing this report (if someone thinks it's too early, please reopen it :)

Cheers,
Sandro

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

[issue10824] urandom should not block

[Michal Čihař]

New submission from Michal Čihař :

Currently if /dev/urandom does not provide any data, unradom() call is just 
stuck infinitely waiting for data.

I actually faced this issue when /dev/urandom was empty regular file (due to 
bug in pbuilder, but I don't think it matters how it did happen) and urandom() 
call just hang. I think it would be much saner in such case to throw an error 
and let user know that something it wrong than waiting infinitely.

--
components: Library (Lib)
messages: 125316
nosy: nijel
priority: normal
severity: normal
status: open
title: urandom should not block
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

[issue10825] use assertIsNone(...) instead of assertEquals(None, ...)

[Sandro Tosi]

New submission from Sandro Tosi :

Hello, after I saw that in issue9554, I created a small patch to replace all

  assertEquals(None, ...)

with

  assertIsNone(...)

It's not rocket science, but I think it makes test suite "better" and leverage 
new unittest features.

Cheers,
Sandro

--
assignee: sandro.tosi
components: Tests
files: use_assertIsNone-py3k.patch
keywords: patch
messages: 125317
nosy: sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: use assertIsNone(...) instead of assertEquals(None, ...)
versions: Python 3.3
Added file: http://bugs.python.org/file20256/use_assertIsNone-py3k.patch

___
Python tracker 

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

[issue10824] urandom should not block

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This would change semantics of the library call, though.
I see two possible solutions:
- do nothing and let users tackle the issue if necessary (e.g. by calling 
open() themselves and using select() on the resulting fd)
- add an optional "blocking" parameter to os.urandom() that, if False, would 
return None when no data is available

--
nosy: +pitrou
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7

___
Python tracker 

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

[issue10825] use assertIsNone(...) instead of assertEquals(None, ...)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Looks good.

--
nosy: +pitrou, r.david.murray

___
Python tracker 

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

[issue10824] urandom should not block

[Michal Čihař]

Michal Čihař  added the comment:

Well in this particular case (/dev/urandom is regular file), it might make 
sense to simply raise NotImplementedError

--

___
Python tracker 

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

[issue10824] urandom should not block

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Well in this particular case (/dev/urandom is regular file), it might
> make sense to simply raise NotImplementedError

IMO it would be quite fragile to try to detect regular files vs special
files. I suppose you noticed the issue quite quickly anyway, since you
had the blocking issue.

--

___
Python tracker 

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

[issue10824] urandom should not block

[Georg Brandl]

Georg Brandl  added the comment:

Is it really necessary to do something about this?  /dev/urandom being a 
regular file is clearly a bug in your system configuration, and I don't want to 
know what all the other programs will do that rely on it...

--
nosy: +georg.brandl

___
Python tracker 

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

[issue10824] urandom should not block

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

>From the documentation:
"This function returns random bytes from an OS-specific randomness source."

In your case, this problem shows up because of an OS misconfiguration : in that 
case, the behaviour is undefined (not much Python can do about it). Note that 
since /dev/urandom is used, with a properly configured system, this should 
never block (contrarily to /dev/random which might block until enough entropy 
has been gathered).

--
nosy: +neologix

___
Python tracker 

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

[issue10824] urandom should not block

[Michal Čihař]

Michal Čihař  added the comment:

Yes, it was blocking, but deep in some program (which was actually called by 
dpkg postinst script), so it took some time to figure out.

I don't think it's that fragile to figure out whether it is regular file using 
os.path.isfile.

Indeed it was bug in a system, but actually this was only thing which got stuck 
because of it.

--

___
Python tracker 

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

[issue10824] urandom should not block

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Note that since /dev/urandom is used, with a properly configured
> system, this should never block

Ok, suggesting closing then.

--
resolution:  -> invalid
status: open -> pending

___
Python tracker 

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

[issue9554] test_argparse.py: use new unittest features

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +r.david.murray

___
Python tracker 

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

[issue10826] pass_fds sometimes fails

[Antoine Pitrou]

New submission from Antoine Pitrou :

This happens selectively (and intermittently) on the Solaris buildbot:

test_pass_fds (test.test_subprocess.POSIXProcessTestCase) ...  -- maxfd = 256
[36787 refs]
 -- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13}
 -- fds that remained open: {0, 1, 2, 3, 5}
FAIL

test_pass_fds (test.test_subprocess.ProcessTestCasePOSIXPurePython) ...  -- 
maxfd = 256
[36787 refs]
 -- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13}
 -- fds that remained open: {0, 1, 2, 3, 5}
FAIL

As you see (thanks to debug output), all fds have been closed except number 5.

(http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/2466/steps/test/logs/stdio)

--
components: Library (Lib), Tests
messages: 125326
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
status: open
title: pass_fds sometimes fails
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

[Nick Coghlan]

Nick Coghlan  added the comment:

Agreed. I'll put something on python-dev about that, so MvL sees it.

--

___
Python tracker 

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

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

[Nick Coghlan]

Nick Coghlan  added the comment:

More direct - added MvL to nosy list.

Martin, we would like to exclude Py_buffer from the stable ABI for Python 3.2, 
until we have a chance to thrash out the missing pieces of the documentation 
for 3.3. I *think* it is a documentation problem, but until we're certain, it 
seems safer to leave it out.

--
nosy: +loewis

___
Python tracker 

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

[issue10826] pass_fds sometimes fails

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Another (perhaps more likely) possibility is that fd 5 was properly closed, but 
another one created at startup by the child Python interpreter. How could we 
diagnose that?

--

___
Python tracker 

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

[issue10001] ~Py_buffer.obj field is undocumented, though not hidden

[Nick Coghlan]

Nick Coghlan  added the comment:

Closing as a dupe of 10181, but transferring Lenard's comments over there.

--
resolution:  -> duplicate
status: open -> closed
superseder:  -> Problems with Py_buffer management in memoryobject.c (and 
elsewhere?)

___
Python tracker 

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

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

[Antoine Pitrou]

Antoine Pitrou  added the comment:

A new patch combining Ross' test with the simple approach from issue 976613. 
Works under Linux, OpenSolaris and Windows.

--
Added file: http://bugs.python.org/file20257/nonblock2.patch

___
Python tracker 

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

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

[Nick Coghlan]

Nick Coghlan  added the comment:

>From Lenard Lindstrom in issue 10001 (closed as dupe of this issue):

The ~Py_buffer.obj field is undocumented. Yet memoryview, that acts as a 
wrapper, includes the field in gc traversal. Also, if the field is not 
initialized by bf_getbuffer its value can be indeterminate. For memoryview the 
gc can crash (see attached C demo program).

--

___
Python tracker 

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

[issue985064] plistlib crashes too easily on bad files

[Mher Movsisyan]

Mher Movsisyan  added the comment:

I've replaced plistlib.InvalidPlistError with ValueError

--
Added file: http://bugs.python.org/file20258/plist_validation_v2.diff

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

r87733 in pyexpat.c modified a call to PyErr_Format with a %zi format code.
This format does not seem to be supported. %zd should be used instead.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue5945] PyMapping_Check returns 1 for lists

[Guido van Rossum]

Guido van Rossum  added the comment:

> In the meantime, would it be reasonable to add the moral equivalent
> of `hasattr(type(op), 'items')` to PyMapping_Check()?

That all depends on what it is used for.  Which is hard to say without someone 
following more of the links that Raymond posted.

--

___
Python tracker 

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

[issue5945] PyMapping_Check returns 1 for lists

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Modules/posixmodule.c: uses PyMapping_Size(), PyMapping_Keys() and 
PyMapping_Values() to parse an environment mapping (for execve() and friends).

PyFrame_New(): validates the "locals" argument in pydebug mode (only used for 
module-level code).
Note that functions in frameobject.c have "assert(PyDict_Check(dict))" where 
"dict" is that same locals argument (copied into f_locals)...

PC/_subprocess.c: uses PyMapping_Size(), PyMapping_Keys() and 
PyMapping_Values() to parse an environment mapping (for CreateProcessW()).

Python/btninmodule.c: validates the "locals" argument to eval().


There are also a couple of places where the PyMapping API (such 
PyMapping_Keys()) is used (e.g. _json), but without calling PyMapping_Check 
first.

--

___
Python tracker 

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

[issue1075356] exceeding obscure weakproxy bug

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

It's not fixed. range() now uses the tp_index slot, in weakrefs this becomes:
WRAP_UNARY(proxy_index, PyNumber_Index)
and indeed PyNumber_Index does not accept strings.

But try with time.sleep() instead; here the line
WRAP_UNARY(proxy_float, PyNumber_Float)
is involved:


import _weakref, time

class U(str): pass
u = U("1")

try:
time.sleep(u)
except TypeError:
print("raised, good")
else:
print("didn't raise, bad")

try:
time.sleep(_weakref.proxy(u))
except TypeError:
print("raised, good")
else:
print("didn't raise, bad")

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue6643] Throw away more radioactive locks that could be held across a fork in threading.py

[Nadeem Vawda]

Nadeem Vawda  added the comment:

r87710 introduces an AttributeError in test_thread's TestForkInThread test 
case. If os.fork() is called from a thread created by the _thread module, 
threading._after_fork() will get a _DummyThread (with no _block attribute) as 
the current thread.

I've attached a patch that checks whether the thread has a _block attribute 
before trying to reinitialize it.

--
nosy: +nvawda
Added file: http://bugs.python.org/file20259/test_thread.diff

___
Python tracker 

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

[issue6643] Throw away more radioactive locks that could be held across a fork in threading.py

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
status: closed -> open

___
Python tracker 

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

[Alexander Belopolsky]

New submission from Alexander Belopolsky :

"""
> http://docs.python.org/library/time.html#time-y2kissues
> "Values 100–1899 are always illegal."

Why are these values illegal? The GNU libc accepts year in [1900-2^31; 2^31-1] 
(tm_year in [-2147483648; 2147481747]). If time.accept2dyear=False, we should 
at least accept years in [1; ]. The system libc would raise an error 
(return NULL) if it doesn't know how to format years older than 1900.
""" -- Victor Stinner at msg12516

--
assignee: belopolsky
components: Extension Modules
messages: 125339
nosy: SilentGhost, belopolsky, haypo
priority: normal
severity: normal
status: open
title: Functions in time module should support year < 1900 when accept2dyear = 0
type: behavior

___
Python tracker 

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

[issue8013] time.asctime segfaults when given a time in the far future

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Committed in r87736.  I opened a separate issue #10827 to address the lower 
bound.

--
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue985064] plistlib crashes too easily on bad files

[Georg Brandl]

Georg Brandl  added the comment:

LGTM.

--
nosy: +georg.brandl

___
Python tracker 

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

[issue8013] time.asctime segfaults when given a time in the far future

[Georg Brandl]

Georg Brandl  added the comment:

Thanks!

--

___
Python tracker 

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> The system libc would raise an error (return NULL) if it doesn't know
> how to format years older than 1900.

As experience with asctime has shown, system libc can do whatever it pleases 
with out of range values including overrunning a fixed size buffer, returning 
non-sensical values etc.  However, now that we have control over asctime 
implemetation (see issue 8013), I don't see any problem in supporting at least 
year > 999 in time.asctime and time.ctime.  (Supporting full [1900-maxint, 
maxint] range would involve a decision on whether to fill < 4-digit values.)  
Some extra care would be required for time.strftime() because some systems may 
not support year < 1900 as well as others.

It looks like POSIX does not make any strong mandates:

"tm_year is a signed value; therefore, years before 1900 may be represented." 

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html

and regardless of what POSIX or C standards have to say, this is the area where 
systems a known to have spotty compliance records.

--

___
Python tracker 

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

[Andreas Stührk]

Changes by Andreas Stührk :


--
nosy: +Trundle

___
Python tracker 

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

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

[Alex Raitz]

Alex Raitz  added the comment:

Yes, I was referring to REMOTE_USER, apologies for the conflation with 
HTTP_REMOTE_USER, which was one of the HTTP headers that a proxy which we were 
testing was setting.

The customer that reported this issue to us was using FireFox with Tamper Data 
to set REMOTE-USER, AdNovum Nevis as the proxy, and Splunk as the server.  

For example, the following is received by the proxy in question:

Host: foobar:42000
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) 
Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Cookie: session_id_4200=69e6b6e33510fa64d8b18c34aa73b4b50eff37dc
remote-user: USER-SUPPLIED
Cache-Control: max-age=0 
Connection: Keep-Alive

The proxy sends the following to the server:

Host: localhost:4200
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) 
Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
REMOTE_USER: normal_user
X-Forwarded-For: 10.3.1.53
X-Forwarded-Host: foobar:42000
X-Forwarded-Server: foobar 
Cookie: session_id_4200=69e6b6e33510fa64d8b18c34aa73b4b50eff37dc
Authorization: Basic Z2FyZXRoOjUzMjc5 
Cache-Control: max-age=0
remote-user: USER-SUPPLIED
Connection: Keep-Alive

In this case, replacing '-' with '_' in wsgiref would overload 
'remote_user=normal_user' with 'remote_user=user-supplied'.

When testing with Apache, we found that all user-supplied variables were placed 
above the proxy-added variables, so that overloading was not an issue.  This 
seems like the appropriate and expected behavior.

However, given that the customer's chosen proxy did not exhibit this behavior, 
and searching for a specification for proxy behavior in this situation was 
inconclusive, our team deemed it advisable to file this issue.

Ideally, Python wsgiref should ensure that the proxy-supplied REMOTE_USER 
cannot be overloaded by a user-supplied REMOTE-USER that is passed to the 
server after the proxy-supplied REMOTE_USER.

Please note that Splunk uses wsgiref from the CherryPy framework, but when we 
investigated the issue we noticed that the replacement of '-' with '_' is the 
same in both Python and CherryPy wsgiref.  A bug has also been filed against 
CherryPy.

--

___
Python tracker 

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am attaching a patch.  While working on the patch, I noticed that although 
time.accept2dyear is documented as boolean, the current code expects int and 
treats any non-int including True as 0:

>>> time.accept2dyear = True; time.asctime((99,) + (0,)*8)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: year >= 1900 required

>>> time.accept2dyear = 1; time.asctime((99,) + (0,)*8)
'Mon Jan  1 00:00:00 1999'

This is clearly a bug.  (Although Y2K note contradicts time.accept2dyear 
documentation.)

Supporting year < 1900 would be a feature in my view, but I agree with 
SilentGhost that once we extended support to 5+ digit years, it is odd to keep 
year >= 1900 restriction.

--
keywords: +patch
Added file: http://bugs.python.org/file20260/issue10827.diff

___
Python tracker 

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

[issue6643] Throw away more radioactive locks that could be held across a fork in threading.py

[Gregory P. Smith]

Gregory P. Smith  added the comment:

eek, thanks for noticing that!

r87740 fixes this in py3k.  backporting to 3.1 and 2.7 now.

--
nosy: +barry
priority: normal -> release blocker

___
Python tracker 

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

[issue1170766] weakref.proxy incorrect behaviour

[Armin Rigo]

Armin Rigo  added the comment:

Not for me (the last example I posted, on 2.7 head).  But I will not fight for 
this.

--

___
Python tracker 

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

[issue5945] PyMapping_Check returns 1 for lists

[Guido van Rossum]

Guido van Rossum  added the comment:

The question is, if PyMapping_Check() returns True, and a list is passed, will 
the code segfault or raise an exception?  A segfault would be unacceptable; an 
exception would be acceptable assuming that the code would have raised an 
exception anyway if PyMapping_Check() had returned False.

--

___
Python tracker 

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Tue, Jan 4, 2011 at 1:30 PM, Alexander Belopolsky
 wrote:
..
> This is clearly a bug.  (Although Y2K note contradicts time.accept2dyear 
> documentation.)
>

PyObject_IsTrue() may fail - this is probably the reason for the
current odd logic.  My patch should be fixed top respect that, but I
still maintain that time.accept2dyear = True should work as expected.
(Would also make True the default rather 1.)

--

___
Python tracker 

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

[issue6643] Throw away more radioactive locks that could be held across a fork in threading.py

[Gregory P. Smith]

Gregory P. Smith  added the comment:

r87741 3.1
r87742 2.7

--
resolution: accepted -> 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

[issue5945] PyMapping_Check returns 1 for lists

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Exceptions seem to be raised (for code that can be exercised in Python), but 
not very obvious ones:

>>> eval("x", {}, [])
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1, in 
TypeError: list indices must be integers, not str

$ ./python -c "import os; os.execle('/bin/ls', 'ls', [])"
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/antoine/py3k/__svn__/Lib/os.py", line 320, in execle
execve(file, args[:-1], env)
AttributeError: values

--

___
Python tracker 

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

[issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Off the top of my head I don't _think_ so.. at least for posix.  I'm not sure 
about the implications of the if mswindows: code in there though.

--

___
Python tracker 

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

[Georg Brandl]

Georg Brandl  added the comment:

But if it fails, why not just let it fail?

--
nosy: +georg.brandl

___
Python tracker 

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

[issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well we could try a run of it on the buildbots, then :)

--

___
Python tracker 

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

[issue5945] PyMapping_Check returns 1 for lists

[Guido van Rossum]

Guido van Rossum  added the comment:

It looks like PyMapping_Check() already checks for the presence of a fairly 
arbitrary special operation (mp_subscript).  It sounds fine to replace that 
with a check for the presence of a keys() or items() method (I'm not sure which 
one is more representative). I wish the check can be done fast -- but I fear 
that it'll involve a dict lookup.  So be it.

--

___
Python tracker 

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Tue, Jan 4, 2011 at 1:49 PM, Georg Brandl  wrote:
..
> But if it fails, why not just let it fail?
>

Sure.  That's what I meant by fixing the patch.  See new patch attached.

--
Added file: http://bugs.python.org/file20261/issue10827a.diff

___
Python tracker 

___Index: Modules/timemodule.c
===
--- Modules/timemodule.c(revision 87738)
+++ Modules/timemodule.c(working copy)
@@ -355,21 +355,20 @@
 if (y < 1900) {
 PyObject *accept = PyDict_GetItemString(moddict,
 "accept2dyear");
-if (accept == NULL || !PyLong_CheckExact(accept) ||
-!PyObject_IsTrue(accept)) {
-PyErr_SetString(PyExc_ValueError,
-"year >= 1900 required");
+int acceptval = accept != NULL && PyObject_IsTrue(accept);
+if (acceptval == -1)
 return 0;
+if (acceptval) {
+if (69 <= y && y <= 99)
+y += 1900;
+else if (0 <= y && y <= 68)
+y += 2000;
+else {
+PyErr_SetString(PyExc_ValueError,
+"year out of range");
+return 0;
+}
 }
-if (69 <= y && y <= 99)
-y += 1900;
-else if (0 <= y && y <= 68)
-y += 2000;
-else {
-PyErr_SetString(PyExc_ValueError,
-"year out of range");
-return 0;
-}
 }
 p->tm_year = y - 1900;
 p->tm_mon--;
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Trying it in r87744.

--

___
Python tracker 

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

[issue10826] pass_fds sometimes fails

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Happened also on the OpenIndiana buildbot:

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/492/steps/test/logs/stdio

--

___
Python tracker 

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

[issue9738] Document the encoding of functions bytes arguments of the C API

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Victor,

Here is an interesting case for your collection: PyDict_GetItemString.  Note 
that it is documented as not setting error, but in fact it may if encoding 
fails.  This rarely an issue because most uses of PyDict_GetItemString are with 
an ASCII string literal.

--

___
Python tracker 

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

[issue10828] Cannot use nonascii utf8 in names of files imported from

[ingemar]

New submission from ingemar :

I have a set of programs written for Python3.1 and running well on Kubuntu. The 
source files are located on a Samba server on a Kubuntu box.  Several of the 
programs contain Python/PyQt  code to start other programs in the set (   
QtCore.QProcess().startDetached(kommando)   )
I have had no problems using non-ascii filenames in the Linux environment.


When I tried to check the programs in a MS Windows environment  (Win2K with 
Python 3.1.2 in a VirtualBox in a Kubuntu box) then Python complained:
ImportError: module xxx not found..

The ugly solution has been to refrain from the use of non-ascii characters in 
the names of files imported from. This involved the filename of the imported 
file and also one line of code changed in the importing file.

Example: 
1) rename  "gui_jämföra.py"   --->   "gui_jamfora.py"
2) in the importing file  "jämföra.py"  change one line:
"from  gui_jämföra  import  * "   --->   "from  gui_jamfora  import  
gui_Jämföra"

Is there a beautiful solution that will permit me to use non-ascii utf-8 also 
in the file names of files imported from?

--
messages: 125360
nosy: ingemar
priority: normal
severity: normal
status: open
title: Cannot use nonascii utf8 in names of files imported from
versions: Python 3.1

___
Python tracker 

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

[issue8052] subprocess close_fds behavior should only close open fds

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Does this mean that it's better to call the close() syscall 1000 or 1000  
times rather than listing the open fds & closing say a handful?

On Linux, the listdir function results in an open() syscall, 2 or so getdents() 
calls and a close() call - could this not be done inbetween the fork & exec, 
even if the actual python function isn't called directly?

--
nosy: +rosslagerwall

___
Python tracker 

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

[issue10824] urandom should not block

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I wonder why reading from /dev/urandom has a loop in the first place, though - 
isn't it guaranteed that you can read as many bytes as you want in one go? This 
goes back to #934711, and apparently, even the original patch had the loop - 
for reasons that got never questioned.

--
nosy: +loewis
status: pending -> open

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[STINNER Victor]

STINNER Victor  added the comment:

#10823 has been marked as a duplicate of this issue.

--

___
Python tracker 

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

[issue9419] RUNSHARED needs LDFLAGS

[Roumen Petrov]

Roumen Petrov  added the comment:

LDFLAGS make no sense for run time. The patch seems to me bogus.

--

___
Python tracker 

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

[issue10824] urandom should not block

[R. David Murray]

R. David Murray  added the comment:

Agreed that the original issue is invalid.  So either the title should be 
changed so it can be used to address Martin's question, or it should be closed.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue10828] Cannot use nonascii utf8 in names of files imported from

[R. David Murray]

R. David Murray  added the comment:

Have you tried 3.2b2?

--
nosy: +haypo, r.david.murray
type:  -> behavior

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

haypo: please avoid introducing explicit casts (such as the one in pyexpat.c). 
Use SAFECASTs instead. If you are absolutely certain that a cast cannot 
possibly truncate, add a comment explaining why that is. In the specific case, 
I think it actually *is* possible that the cast truncates, because the case 
that read() returned too many bytes is incorrectly handled (it should set len 
to -1).

--

___
Python tracker 

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

[issue10824] urandom should not block

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Closing it. It seems that people feel more safe when urandom loops until it has 
enough data (see 
http://stackoverflow.com/questions/4598507/dev-urandom-maximum-size/4598534#4598534).
 I might still pursue this idea, but in a different issue.

--
status: open -> closed

___
Python tracker 

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

[issue10824] urandom should not block

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

> Martin v. Löwis  added the comment:
>
> I wonder why reading from /dev/urandom has a loop in the first place, though 
> - isn't it guaranteed that you can read as many bytes as you want in one go? 
> This goes back to #934711, and apparently, even the original patch had the 
> loop - for reasons that got never questioned.
>

I found surprising that a read from /dev/urandom would be
uninterruptible, so I digged a little, and found this mail from 1998:

[patch] fix for urandom read(2) not interruptible
http://marc.info/?l=bugtraq&m=91495921611500&w=2

"It's a bug in random.c that doesn' t check for signal pending inside the
read(2) code, so you have no chance to kill the process via signals until
the read(2) syscall is finished, and it could take a lot of time before
return, if the buffer given to the read syscall is very big..."

I've had a quick look at the source code, and indeed, read(2) from
/dev/urandom can now be interrupted by a signal, so looping seems to
be justified.

> --
> nosy: +loewis
> status: pending -> open
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[STINNER Victor]

STINNER Victor  added the comment:

amaury> r87733 in pyexpat.c modified a call to PyErr_Format with a %zi
amaury> format code. This format does not seem to be supported. %zd
amaury> should be used instead.

Oh, that's surprising. Why %zd is supported but not %zi?

PyUnicode_FromFormatV() supports %d, %ld, %lld, %zd, %i, but not %li, %lli or 
%zi. Before fixing PyUnicode_FromFormatV(), I fixed pyexpat.c: r87747.

MvL> If you are absolutely certain that a cast cannot possibly truncate, 
MvL> add a comment explaining why that is.

Ah yes, sorry, I forgot to add a comment: done in r87746.

--

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[STINNER Victor]

STINNER Victor  added the comment:

> Python\pystrtod.c(902) : 'function' : conversion from 'Py_ssize_t' to 'int', 
> possible loss of data
> Python\pystrtod.c(1023) : '=' : conversion from 'Py_ssize_t' to 'int', 
> possible loss of data

I asked dmalcolm on IRC if int or Py_ssize_t should be used:

"this is the number of digits to use in the floating point representation, 
right? it strikes me that if you're overflowing an int, you're asking for a 
very very very long string" (yes, INT_MAX is usually 2^31)

"... looking at usage of precision seems to ultimately land in Python/dtoa.c, 
which uses int..."

--

___
Python tracker 

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

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I think this patch (nonblock2.patch) is wrong. If I have a non-blocking server 
socket on *BSD, and do accept, with no default timeout: IIUC, under the patch, 
I will get a blocking connection socket. However, according to the operating 
system API, I'm entitled to get a non-blocking socket (i.e. O_NONBLOCK must be 
inherited across accept).

--

___
Python tracker 

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

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I think this patch (nonblock2.patch) is wrong. If I have a
> non-blocking server socket on *BSD, and do accept, with no default
> timeout: IIUC, under the patch, I will get a blocking connection
> socket. However, according to the operating system API, I'm entitled
> to get a non-blocking socket (i.e. O_NONBLOCK must be inherited across
> accept).

Well, either the defaulttimeout should have the priority over the parent
socket's settings (your argument in msg125135), or it shouldn't. I'm
fine with both, but I think any more complicated combination would end
up puzzling for the user :)

--

___
Python tracker 

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

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

[Phillip J. Eby]

Phillip J. Eby  added the comment:

I'm still baffled.  How does this matter to anything?

The HTTP headers you describe would end up in an HTTP_REMOTE_USER environment 
variable, with no impact on REMOTE_USER.  REMOTE_USER could only be set by an 
actual web server, not via an HTTP header.

So I don't get how this is a security issue, or even a bug at all.

--

___
Python tracker 

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

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Antoine Pitrou  added the comment:
> 
> > I think this patch (nonblock2.patch) is wrong. If I have a
> > non-blocking server socket on *BSD, and do accept, with no default
> > timeout: IIUC, under the patch, I will get a blocking connection
> > socket. However, according to the operating system API, I'm entitled
> > to get a non-blocking socket (i.e. O_NONBLOCK must be inherited across
> > accept).
> 
> Well, either the defaulttimeout should have the priority over the parent
> socket's settings (your argument in msg125135), or it shouldn't. I'm
> fine with both, but I think any more complicated combination would end
> up puzzling for the user :)

I would add that, since flags inheritance through accept() is
platform-dependent while the default timeout is a well-defined Python
feature, I would lean slightly towards applying the default timeout.

--

___
Python tracker 

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

[issue10824] urandom should not block

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> "It's a bug in random.c that doesn' t check for signal pending inside the
> read(2) code, so you have no chance to kill the process via signals until
> the read(2) syscall is finished, and it could take a lot of time before
> return, if the buffer given to the read syscall is very big..."
> 
> I've had a quick look at the source code, and indeed, read(2) from
> /dev/urandom can now be interrupted by a signal, so looping seems to
> be justified.

No: if read(2) is interrupted, no data is returned, and exception is
raised. So it won't loop in that case, but raise the exception out of
urandom also (which is the right thing to do).

--

___
Python tracker 

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

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

[Alex Raitz]

Alex Raitz  added the comment:

Per the first line of my previous comment, please ignore HTTP_REMOTE_USER.

The risk is that if the proxy does not place the user-supplied 
'remote-user=VALUE1' before the proxy-supplied 'REMOTE_USER=VALUE2', wsgiref 
will overload REMOTE_USER with the value of REMOTE-USER.

1) Client supplies 'REMOTE-USER=admin'
2) Proxy adds 'REMOTE_USER=normal_user' and appends 'REMOTE-USER=admin'
3) Server using wsgiref processes header key/value 'REMOTE_USER=normal_user' 
and performs lowercase/replace, resulting in 'remote_user=normal_user'
4) Server using wsgiref continues to process the header, performs 
lowercase/replace on 'REMOTE-USER=admin', resulting in 'remote_user=admin', 
which overloads the proxy-supplied value for 'remote_user' and allows for 
arbitrary privilege escalation.

--

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> MvL> If you are absolutely certain that a cast cannot possibly truncate, 
> MvL> add a comment explaining why that is.
> 
> Ah yes, sorry, I forgot to add a comment: done in r87746.

But the comment is actually wrong: It says

len <= buf_size <= INT_MAX (see above)

however, len > buf_size may happen, after this code:

if (len > buf_size) {
PyErr_Format(PyExc_ValueError,
 "read() returned too much data: "
 "%i bytes requested, %zd returned",
 buf_size, len);
goto finally;
}

--

___
Python tracker 

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

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Well, either the defaulttimeout should have the priority over the parent
> socket's settings (your argument in msg125135), or it shouldn't. I'm
> fine with both, but I think any more complicated combination would end
> up puzzling for the user :)

Applying the default timeout if set is fine, and I agree it should have
precedence. In case no default timeout is configured, the platform
semantics should prevail. This is tradition in Python: when we define
some behavior (i.e. default timeout), we are entitled to consistently
define all aspects of it. In the other places we use the platform
semantics (leaning towards standards such as POSIX in case the platform
offers alternative semantics).

--

___
Python tracker 

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

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

[Phillip J. Eby]

Phillip J. Eby  added the comment:

You say it "would" do this.  Have you actually *tested* it?

Looking at the code in wsgiref again, I don't think it does what you think it 
does.  The '_' substitution is done to keyword arguments for header 
*parameters* only; it's not done to header *names*.

Please write a test case for wsgiref.headers.Headers that demonstrates the 
behavior you think it would be doing.  AFAICT, you will not even be able to get 
the replace() calls to execute without writing explicit add_header() calls, and 
even then, you *still* won't get the results you're describing.

--

___
Python tracker 

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

[issue10828] Cannot use nonascii utf8 in names of files imported from

[STINNER Victor]

STINNER Victor  added the comment:

I think that this issue is a duplicate of #8611 (and #9425), it should be fixed 
in Python 3.2.

--

___
Python tracker 

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

[issue5485] pyexpat has no unit tests for UseForeignDTD functionality

[Sandro Tosi]

Sandro Tosi  added the comment:

Hi all, I think this patch would be nice to be applied, but before start 
working on it (like adapt it to new code & stuff), I'd like to know if we are 
really targetting 2.7 or should we instead targer 3.3.

Cheers, Sandro

--
nosy: +sandro.tosi
stage:  -> patch review

___
Python tracker 

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

[issue5485] pyexpat has no unit tests for UseForeignDTD functionality

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I don't think we should adding tests to 2.7, perhaps unless there are also 
fixes for it. So targetting 3.3+ only seems reasonable.

--

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[STINNER Victor]

STINNER Victor  added the comment:

> But the comment is actually wrong: It says
> 
> len <= buf_size <= INT_MAX (see above)
> 
> however, len > buf_size may happen, after this code:
> 
> if (len > buf_size) {
> PyErr_Format(PyExc_ValueError,
>  "read() returned too much data: "
>  "%i bytes requested, %zd returned",
>  buf_size, len);
> goto finally;
> }

Oh. Not only is the comment is wrong, but the code is also wrong. It
should return a negative value on error, whereas it returns the string
length which is always positive (except on a unlikely Py_ssize_t => int
overflow?).

--

___
Python tracker 

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

[issue9566] Compilation warnings under x64 Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Oh. Not only is the comment is wrong, but the code is also wrong. It
> should return a negative value on error, whereas it returns the string
> length which is always positive (except on a unlikely Py_ssize_t => int
> overflow?).

Right. See msg125367.

--

___
Python tracker 

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

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

[Alex Raitz]

Alex Raitz  added the comment:

I had previously tested it against simple_server.  However, in reviewing my 
test, I realized that you are correct that wsgiref headers is not misbehaving.  

It appears that in simple_server, the values of remote-user and remote_user 
both end up in HTTP_REMOTE_USER because of the replacement behavior in 
simple_server (not in headers).

I am withdrawing this bug and will submit a subsequent ticket with the required 
details.  Thank you for your patience.

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