[issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4

Gregory P. Smith added the comment: "extended support" for windows 2000 server ends in a few months, mainstream support ended 5 years ago: http://support.microsoft.com/lifecycle/?LN=en-us&x=8&y=9&p1=7274 That, IMNSHO, implies that python 2.7 and 3.2 should not bother supporting win2k. Rega

[issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4

Martin v. Löwis added the comment: Bumping the API level to XP might mean that we stop supporting Windows 2000; I'm not sure whether we agreed to that yet. I'd be curious to find out why the constants were defined in Python 2.5. -- ___ Python track

[issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4

Gregory P. Smith added the comment: In PC/pyconfig.h we #define Py_WINVER to _WIN32_WINNT_WIN2K (0x500) for 32bit builds. I think we should update this to _WIN32_WINNT_WINXP (0x501) for all builds, not just 64bit. Assigning to loewis as he does our windows release builds so likely knows

[issue8032] Add gdb7 hooks to make it easier to debug Python

Changes by Gregory P. Smith : -- nosy: +gregory.p.smith priority: -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue7849] Improve "test_support.check_warnings()"

Antoine Pitrou added the comment: "lazy" sounds like a bad name for that parameter. It makes me think of lazy evaluation, not error checking. There's also the problem that check_py3k_warnings() will check all DeprecationWarnings, not only py3k-specific ones. We need a Py3kDeprecationWarning

[issue8031] Can't get f2py to work at all

Éric Araujo added the comment: While I’m thinking about this, is there a way to make the syntax error traceback more informative, i.e. adding “'{}' is a reserved keyword” in such cases? -- ___ Python tracker

[issue8031] Can't get f2py to work at all

Éric Araujo added the comment: Hello This is indeed a problem with f2py. Please tell its maintaines that they can’t name an object “as” since it’s a reserved keyword in Python 2.6 and higher. Testing with 2.5 (previous stable version, released in 2006) would have shown it:

[issue6729] Add support for ssize_t

Ryan Coyner added the comment: You don't want to do c_size_t = c_void_p because that will prevent type checking. We want c_size_t to be integers; setting it to c_void_p will accept other values. The lines that define c_size_t are doing a sizeof check to determine how many bits the CPU support

[issue8033] sqlite: broken long integer handling for arguments to user-defined functions

Fred Fettinger added the comment: I've never really looked at the python source before, but this is my best guess at the problem: For the standard SELECT query: In Modules/_sqlite/cursor.c, _pysqlite_fetch_one_row() has this code: PY_LONG_LONG intval; ... } else if (coltype == SQLITE_INTEGER)

[issue8033] sqlite: broken long integer handling for arguments to user-defined functions

New submission from Fred Fettinger : Handling of long integers is broken for arguments to sqlite functions created with the create_function api. Integers passed to a sqlite function are always converted to int instead of long, which produces an incorrect value for integers outside the range of

[issue3892] bsddb: test01_basic_replication fails sometimes

Gregory P. Smith added the comment: r.david.murray - sounds like a good idea. -- ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue6560] socket sendmsg(), recvmsg() methods

David Watson added the comment: Thanks for your interest! I'm actually still working on the patch I posted, docs and a test suite, and I'll post something soon. Yes, you could just use b"".join() with sendmsg() (and get slightly annoyed because it doesn't accept buffers ;) ). I made sendmsg()

[issue7242] Forking in a thread raises RuntimeError

Greg Jednaszewski added the comment: I tested the updated patch, and the new unit test passes on my Sol 8 sparc, but the test_threading test still hangs on my system. However, given that the test is skipped on several platforms and it does work on more relevant versions of Solaris, it's prob

[issue8031] Can't get f2py to work at all

Peter Jones added the comment: I would like to recall this bug report. What happend was I went to the f2py web site and dowloaded the "latest" version and installed it over Pythoh x,y. So I uninstalled P x,y and resinstalled and the f2py works OK now. Some one should make it more clear in the

[issue8031] Can't get f2py to work at all

Benjamin Peterson added the comment: This is a 3rd party package problem. Please ask the maintainers of it. -- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed ___ Python tracker

[issue8032] Add gdb7 hooks to make it easier to debug Python

Changes by Dave Malcolm : -- keywords: +patch Added file: http://bugs.python.org/file16403/add-gdb7-python-hooks-to-trunk.patch ___ Python tracker ___ ___

[issue8032] Add gdb7 hooks to make it easier to debug Python

New submission from Dave Malcolm : gdb 7 can be extended with Python code, allowing the writing of domain-specific pretty-printers and commands. I've been working on gdb 7 hooks to make it easier to debug python itself, as mentioned here: https://fedoraproject.org/wiki/Features/EasierPythonD

[issue8031] Can't get f2py to work at all

New submission from Peter Jones : I am user 11943. OS is Windows Vista Ultimate. I have followed the instructions on how to use f2py and get this error when I try it (is this a known bug? It appears that there is bug in f2py): C:\Python26\Scripts>python f2py.py Traceback (most recent call last

[issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail

Gregory P. Smith added the comment: fwiw - The documentation was updated in trunk, py3k and release31-maint to mention this behavior of assertSameElements. Assigning to Michael for a decision on whether or not to add to the API. python-unittest-backport has since been supplanted by Michael's

[issue7232] Support of 'with' statement fo TarFile class

Lars Gustäbel added the comment: I found an issue that needs to be addressed: if there is an error while the TarFile object is opened for writing, we cannot simply call TarFile.close() in the __exit__() method. close() would try to finalize the archive, i.e. write two zero end-of-archive bloc

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

Gregory P. Smith added the comment: Reviewers: gregory.p.smith, Benjamin, ilya.sandler, Message: Also, can you take a look at how the pdb unittests work and see if you can come up with a way to unittest the KeyboardInterrupt behavior? Particular for the 4 scenarios you outlined in your prior c

[issue5802] The security descriptors of python binaries in Windows are not strict enough

Hong Chen added the comment: Sorry for the delay, it's been a busy month. I just tried python 3.1 If installed under c:\program files, the access control list would be correct, only system & administrator accounts get the modify privilege. The default installation is to c:\python31, in which

[issue7481] Failing to start a thread leaves "zombie" thread in "initial" state

Gregory P. Smith added the comment: r78519 r78520 for py3k and 3.1. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-l

[issue7232] Support of 'with' statement fo TarFile class

Lars Gustäbel added the comment: IMO it is okay for __enter__() and __exit__() not to have docstrings. I cannot see what's so special about the behaviour of __enter__() and __exit__(). __enter__() raises IOError only if the TarFile object has been already closed. This is exactly the behaviour

[issue7481] Failing to start a thread leaves "zombie" thread in "initial" state

Gregory P. Smith added the comment: fixed in trunk r78517 and release26-maint r78518. still needs merging into py3k and release31-maint -- resolution: -> accepted ___ Python tracker __

[issue8030] documentation bugs and improvements

New submission from Christopher the Magnificent : Help for list looks like this: >>> help(list) class list(object) | list() -> new list | list(sequence) -> new list initialized from sequence's items | Help for dict looks like this: >>> help(dict) c

[issue7242] Forking in a thread raises RuntimeError

Gregory P. Smith added the comment: If you have a chance tonight that'd be awesome. I'd love to get this in before 2.6.5rc1 (being cut tomorrow) but as its platform specific (and a pretty-old platform at that) its not worth holding up the release. --

[issue7232] Support of 'with' statement fo TarFile class

Meador Inge added the comment: > This is common practice in the standard library. This doesn't necessarily mean it is a correct practice :-). All kidding aside, I think the assumption that the standard documentation on '__enter__' and '__exit__' is sufficient is a bad one. With respect to

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

R. David Murray added the comment: Hmm. I liked Eric's idea, and it would be easier to get in, but 'call' is actually an argument against it. It would mean that in addition to PopenExec and PopenShell we'd need call_exec and call_shell, and check_call_exec and check_call_shell. Proliferati

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

Brian Curtin added the comment: That seems reasonable. We already have subprocess.call, the thin wrapper around Popen. Maybe add this as subprocess.call_shell and call_exec? -- nosy: +brian.curtin ___ Python tracker

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

Eric Smith added the comment: I think the better design is to have 2 distinct APIs: Popen_shell and Popen_exec. I'm not wild about the name Popen_exec, suggestions welcome. Neither of these would accept a shell parameter. For starters these could be convenience APIs that just call Popen with

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

R. David Murray added the comment: Because the shell argument provides important functionality. Or are you suggesting that passing a list implies shell=False and passing a string implies shell=True? That is a possibility, but I think it would not be a good idea, because people will 'acciden

[issue7242] Forking in a thread raises RuntimeError

Greg Jednaszewski added the comment: The problem only seems to appear on Solaris 9 and earlier. I'll try to test the updated patch tonight or tomorrow and let you know what I find. -- ___ Python tracker _

[issue8029] bug in 2to3 dealing with "print FOO, " followed by "sys.stdout.write('')"

Changes by R. David Murray : -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue7232] Support of 'with' statement fo TarFile class

Lars Gustäbel added the comment: Another version of the patch (issue7232.6.diff) that checks if the TarFile object is still open in the __enter__() method (plus a test for that). I removed the docstrings as Eric suggested. This is common practice in the standard library. -- Added fil

[issue7242] Forking in a thread raises RuntimeError

Gregory P. Smith added the comment: Using issue7242-gps01.diff on release26-maint and a freshly downloaded opensolaris 2009-06 VM test_thread, test_threading and test_subprocess all pass for me both before -and- after the patch. Nor does the original thread_test.py cause the problem for me (