[issue2182] tokenize: does not allow CR for a newline
Jared Grubb [EMAIL PROTECTED] added the comment:
Yes, but exec(string) also gives a syntax error for \r\n:
exec('x=1\r\nprint x')
The only explanation I could find for ONLY permitting \n as newlines in
exec(string) comes from PEP278: There is no support for universal
newlines in strings passed to eval() or exec. It is envisioned that such
strings always have the standard \n line feed, if the strings come from
a file that file can be read with universal newlines. (This is why my
original example had to be exec(file) and not just a simple exec(string))
Of the 3 newline types, exec(*) allows 1 or all 3 as the case may be,
and tokenize allows exactly 2 of them. I honestly am not sure what the
right way is (or should be), but either way, the tokenize module is
not consistent with exec.
(By the way, if you're curious why I filed this issue and Issue#2180,
I'm working on the PyPy project to help improve its current Python
lexer/parser. In order to ensure that it is correct and robust, I was
experimenting with corner cases in Python syntax and I found these cases
where tokenize disagrees with exec.)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2182
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
Guido van Rossum [EMAIL PROTECTED] added the comment: I recommend that you only care about \n and consider everything else unspecified. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
Jared Grubb [EMAIL PROTECTED] added the comment: I actually hadnt thought of that. PyPy should actually use universal newlines to its advantage; after all, it IS written in Python... Thanks for the suggestion! In any case, I wanted to get this bug about the standard library in your record, in case you wanted to handle it. It is fairly innocuous, so I'll let it go. Take care. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Trent Nelson [EMAIL PROTECTED] added the comment: Invested quite a few cycles on this issue last night. The more time I spent on it, the more I became convinced that every single test working with sockets should be changed in one fell swoop in order to facilitate (virtually unlimited) parallel test execution without fear of port conflicts. I've attached a second patch, trunk.2550-2.patch, which is my progress so far on doing just this. The main changes can be expressed by the following two points: a) do whatever it takes in network-oriented tests to ensure unique ports are obtained (relying on the bind_port() and find_unused_port() methods exposed by test_support) b) never, ever, ever call SO_REUSEADDR on a socket from a test; because we're putting so much effort into obtaining a unique port, this should never be necessary -- in the rare cases that our attempts to obtain a unique port fail, then we absolutely should fail with EADDRINUSE, as the ability to obtain a unique port for the duration of a client/server test is an invariant that we *must* be able to depend upon. If the invariant is broken, fail immediately (don't mask the problem with SO_REUSEADDR). With this patch applied, I can spawn a handful of Python processes and run the entire test suite (without -r, ensuring all tests are run in the same order, which should encourage port conflicts (if there were any)) without any errors*. Doing that now is completely and utterly impossible. [*] Well, almost without error. All the I/O related tests that try and open @test fail. I believe there's still outstanding work to do with this patch with regards to how the intracacies of SO_REUSEADDR and SO_EXCLUSIVEADDRUSE should be handled in the rest of the stdlib. I'm still thinking about the best approach for this. However, the patch as it currently stands is still quite substantial so I wanted to get it out sooner rather than later for review. (I'll forward this to python-dev@ to try and encourage more eyes from people with far more network-fu than I.) Added file: http://bugs.python.org/file9980/trunk.2550-2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2550 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2574] Add RFC 3768 SSM Multicast support to socket
Benjamin Peterson [EMAIL PROTECTED] added the comment: Ok, we'll see what we can do. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2574 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2582] Unpickling of range objects fail in Py3k
New submission from Anand B Pillai [EMAIL PROTECTED]: Unpickling of range objects is throwing an exception in Python 3.0 -- components: Interpreter Core, Library (Lib) files: bugdemo.py messages: 65157 nosy: pythonhacker severity: normal status: open title: Unpickling of range objects fail in Py3k versions: Python 3.0 Added file: http://bugs.python.org/file9981/bugdemo.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2582 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.
Tarek Ziadé [EMAIL PROTECTED] added the comment:
For writing the metadata, we don't need to make any assumptions. We
can just write the bytes as-is. This is how distutils has behaved
for many releases now, and this is how users have been using it.
But write_pkg_file will use ascii encoding if we don't indicate it
here:
pkg_info.write('Author: %s\n' % self.get_contact() )
So wouldn't a light fix in write_pkg_file() would be sufficient when a
unicode(field) fails, as MAL mentioned ? by trying utf8:
try:
...pkg_info.write('Author: %s\n' % self.get_contact() )
... except UnicodeEncodeError:
...pkg_info.write('Author: %s\n' % self.get_contact().encode('utf8') )
As far as I know, this simple change will not impact people and will
just make it possible to use Unicode. And everything will be fine under
Py3K as it is now.
But I don't know yet how this would impact 3rd party softwares that reads
the egg-info file. But like MAL said, they will have to get fixed as well.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2562
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2564] Python hangs on FreeBSD7 in test_capi
Trent Nelson [EMAIL PROTECTED] added the comment: Ahh, more FreeBSD threading woes. If no-one beats me to it, I'll be able to start taking a look at this when our FreeBSD 7 server is up in a week or so. -- assignee: - Trent.Nelson nosy: +Trent.Nelson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2564 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2563] embed manifest in windows extensions
Trent Nelson [EMAIL PROTECTED] added the comment: +1 from me on principle (haven't tested). -- nosy: +Trent.Nelson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2563 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2564] Python hangs on FreeBSD7 in test_capi
Guilherme Polo [EMAIL PROTECTED] added the comment: Hi Trent, FreeBSD 7 uses libthr as default, which would possibly eliminate this problem. -- nosy: +gpolo __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2564 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2583] urlparse normalize URL path
New submission from monk.e.boy [EMAIL PROTECTED]: Hi, This is my first problem with anything Python :-) and my first issue. Doing in the following: urlparse.urljoin( 'http://site.com/', '../../../../path/' ) 'http://site.com/../../../../path/' urlparse.urljoin( 'http://site.com/', '/path/../path/.././path/./' ) 'http://site.com/path/../path/.././path/./' These URLs are normalized to http://site.com/path/ in both Firefox and Google (the google spider would follow these OK) I think the documentation could be improved to point at the posixpath.py normpath function and how it solves the above. I blogged a how to: http://teethgrinder.co.uk/blog/Normalize-URL-path-python/ I hope my bug report is OK. Thanks for all the code :-) [EMAIL PROTECTED] -- components: Library (Lib) messages: 65162 nosy: monk.e.boy severity: normal status: open title: urlparse normalize URL path type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2583 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1489] test_socket_ssl hanhs on Windows (deadlock)
Trent Nelson [EMAIL PROTECTED] added the comment: Re-assigned this to myself (hope you don't mind janssen ;-) as I'm actively looking into it. We build openssl.exe as part of our Windows build so we should make an effort to use this where possible. Note that there is definitely a problem with 'openssl s_server' on Windows, I'm not sure if it's to do with buffering though as I can step through the same actions the test is performing in the console and I get 'ERROR\n' immediately back from the server. This sort of falls into my existing work with issue 2550 (and patches) to improve network- oriented tests such that they can be ran in parallel. Note that patch trunk.2550-2.patch attached to issue2550 goes as far as converting openssl to use the -accept [port] option such that we don't bind on 4443 by default (thus impeding other test_ssl_socket tests that may be running). Also, openssl.exe in the s_server mode is using SO_REUSEADDR when it should be using SO_EXCLUSIVEADDRUSE. That's not our problem per se, but given that we maintain our own openssl-0.9.8g sources, I'm considering fixing it if it improves the reliability of the test. (I'll feed back any changes to the OpenSSL project, of course.) -- assignee: janssen - Trent.Nelson nosy: +Trent.Nelson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1489 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Changes by Trent Nelson [EMAIL PROTECTED]: -- nosy: +Trent.Nelson _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1220212 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2563] embed manifest in windows extensions
Christian Heimes [EMAIL PROTECTED] added the comment: Yes, it's me ;) I'm +1 on the feature but I haven't reviewed your patch. IIRC and unless I'm not mistaken you can tell the linker to embed the manifest without the extra mt.exe dance. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2563 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2564] Python hangs on FreeBSD7 in test_capi
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I think that this problem is not FreeBSD specific: - import test.autotest runs the whole test suite as a side-effect of an import statement. - in the test suite test_capi spawns threads, which also import. - a lock ensues... See for example test_threaded_import.py:: if imp.lock_held(): # This triggers on, e.g., from test import autotest. raise TestSkipped(can't run when import lock is held) I the test_capi case, I think that the two imports in TestThreadState should be moved outside the function. Also, the backtrace file shows two other threads locked in a import socket statement. I suspect problems in test_urllib2.py or test_urllib2net.py... -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2564 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2410] absolute import doesn't work for standard python modules
Nick Coghlan [EMAIL PROTECTED] added the comment: Running the interactive interpreter like that places the current directory on sys.path, so it *is* doing an absolute import of your pseudo email package. (If it didn't do that, your test would fail at the import foo line) Instead of cd'ing into test the way you did, invoke the interpreter from the next directory up and do an import of 'test.foo', and you should see the absolute imports in the foo module having the desired effect. (I expect the reason you didn't run into this for the os module is because the os module is bootstrapped quite early in Python's startup process, so you'd have to try really hard to get it to see something other than the builtin standard library version of os) -- nosy: +ncoghlan resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2410 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2584] numeric overflow in IDLE
New submission from Tim Wilcoxson [EMAIL PROTECTED]: According to the documentation there is not suppose to be numeric overflow in python 2.5. However If you run a for loop with the range(1, 3)a couple of times (for me 2 or 3 times worked) in the IDLE (1.2.2)GUI . It will cause what appears to be a memory leak, at least under vista home edition. Haven't tested out other platforms yet. Vista's logon process will fail to start security dialog as well if you try to ctrl-alt-del. Which effectively cripples the system. I haven't tested to see if the condition will get better over long period of time. I've waited a max of 10 minutes for the system to respond. I tested running the script multiple times under cmd in windows, and it spits out a memory error after a minute of not responding and then the cmd prompts will close and the system will begin responding. So it appears to be isolated to IDLE. -- components: IDLE files: for_loop.py messages: 65167 nosy: Qodosh severity: normal status: open title: numeric overflow in IDLE type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9982/for_loop.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2584 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2585] urllib2.HTTPError broken due to urllib.addinfourl changes
New submission from djc [EMAIL PROTECTED]:
[EMAIL PROTECTED] tests $ python2.6
Python 2.6a2+ (trunk, Apr 4 2008, 20:21:45)
[GCC 4.1.2 20070214 ( (gdc 0.24, using dmd 1.020)) (Gentoo 4.1.2
p1.0.2)] on linux2
Type help, copyright, credits or license for more information.
import urllib2
try:
... urllib2.urlopen('http://example.com/weird')
... except urllib2.HTTPError, inst:
... print inst.code
...
None
urllib.addinfourl.__init__() was changed in r60133 to set self.code.
Unfortunately, this overrides HTTPError.code, which is probably not good.
--
components: Library (Lib)
messages: 65168
nosy: birkenfeld, djc
severity: normal
status: open
title: urllib2.HTTPError broken due to urllib.addinfourl changes
versions: Python 2.6
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2585
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2197] Further simplify dict literal bytecode
Alexander Belopolsky [EMAIL PROTECTED] added the comment: Python-3000 discussion http://mail.python.org/pipermail/python- 3000/2008-March/012753.html did not reveal any opposition to the idea of batch processing of dict displays. However, a compromise suggestion was made to limit batches to 256 items http://mail.python.org/pipermail/python-3000/2008-March/012829.html. I don't think this type of micro-optimization belongs to the core. A rare application that would benefit from limited size batch processing can do so explicitly using dict.update. See also relevant discussion at issue2292 (starting at msg65111). I believe this issue can be reopen. I will submit documentation patch if the change is accepted in principle. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2197 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1489] test_socket_ssl hanhs on Windows (deadlock)
Bill Janssen [EMAIL PROTECTED] added the comment: Fine with me. I don't have a checkout of the code handy, but I believe this is obsolete test code. All the SSL tests are, or should be, in test_ssl, for 2.6 and 3.x. The right fix is to remove it. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1489 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
New submission from Justin Ferguson [EMAIL PROTECTED]: The zlib module in multiple places fails to adequately check the sanity of its arguments resulting in memory corruption, please see two attached PoCs. -- components: Extension Modules files: python-2.5.2-zlib-unflush-misallocation.py messages: 65171 nosy: jnferguson severity: normal status: open title: Integer signedness bugs in zlib modules type: security versions: Python 2.5 Added file: http://bugs.python.org/file9983/python-2.5.2-zlib-unflush-misallocation.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
Changes by Justin Ferguson [EMAIL PROTECTED]: Added file: http://bugs.python.org/file9984/python-2.5.2-zlib-unflush-signedness.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsane
New submission from Justin Ferguson [EMAIL PROTECTED]: The PyString_FromStringAndSize() function takes a pointer and signed integer as input parameters however it fails to adequately check the sanity of the integer argument. Because of the failure to check for negative values and because it sums the integer with the size of the PyStringObject structure it becomes possible for the allocator to take either of the code paths in PyObject_MALLOC()-- both of which will incorrectly allocate memory. This may not seem like a big deal, but I'm posting this instead of filing a bug for every place this screws you guys over. if (0 len || len PYSSIZE_T_MAX/sizeof(PyStringObject)) return NULL; -- components: Interpreter Core messages: 65172 nosy: jnferguson severity: normal status: open title: PyString_FromStringAndSize() to be considered unsane type: security versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2197] Further simplify dict literal bytecode
Raymond Hettinger [EMAIL PROTECTED] added the comment: -1 I don't think this is worth the semantic change. The current approach doesn't require special cases for different dict sizes. The code/time savings is very small (seven bytes of opcodes per item get condensed by only one byte and the cost of one time around the eval- loop is tiny in comparison to the cost of inserting a new dict entry). Besides, dict literals almost never occur in the inner-loops of time critical code. I recommend that this stay closed. Better to aim for meaningful optimizations using the AST and avoid micro-optimizations that subtly change semantics. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2197 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
New submission from Justin Ferguson [EMAIL PROTECTED]:
The PyOS_vsnprintf() contains the caveat that the length parameter
cannot be zero, however this is only enforced via assert() which is
compiled out. As a result if the length parameter is zero then the
function will underflow and write a null byte to invalid memory.
53 int
54 PyOS_vsnprintf(char *str, size_t size, const char *format, va_list va)
55 {
56 int len; /* # bytes written, excluding \0 */
57 #ifndef HAVE_SNPRINTF
58 char *buffer;
59 #endif
60 assert(str != NULL);
61 assert(size 0);
62 assert(format != NULL);
[...]
65 len = vsnprintf(str, size, format, va);
[...]
91 str[size-1] = '\0';
92 return len;
93 }
--
components: Distutils
messages: 65174
nosy: jnferguson
severity: normal
status: open
title: PyOS_vsnprintf() underflow leads to memory corruption
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2588
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
Changes by Justin Ferguson [EMAIL PROTECTED]: -- components: +Interpreter Core -Distutils __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2589] PyOS_vsnprintf() potential integer overflow leads to memory corruption on esoteric architectures
New submission from Justin Ferguson [EMAIL PROTECTED]:
On architectures that do not have a vsnprintf() in their standard
library Python attempts to emulate it. When doing so, the implementation
ambitiously allocates more memory than requested without verifying the
sanity of the summed value. As a result it becomes possible (although
unlikely) for an integer overflow to occur misallocating memory and
causing a buffer overflow.
53 int
54 PyOS_vsnprintf(char *str, size_t size, const char *format, va_list va)
55 {
56 int len; /* # bytes written, excluding \0 */
[...]
60 assert(str != NULL);
61 assert(size 0);
62 assert(format != NULL);
63
[...]
67 /* Emulate it. */
68 buffer = PyMem_MALLOC(size + 512);
69 if (buffer == NULL) {
70 len = -666;
71 goto Done;
72 }
73
74 len = vsprintf(buffer, format, va);
75 if (len 0)
76 /* ignore the error */;
77
78 else if ((size_t)len = size + 512)
79 Py_FatalError(Buffer overflow in
PyOS_snprintf/PyOS_vsnprintf);
80
81 else {
82 const size_t to_copy = (size_t)len size ?
83 (size_t)len : size - 1;
84 assert(to_copy size);
85 memcpy(str, buffer, to_copy);
86 str[to_copy] = '\0';
87 }
88 PyMem_FREE(buffer);
89 Done:
[...]
91 str[size-1] = '\0';
92 return len;
93 }
--
components: Interpreter Core
messages: 65175
nosy: jnferguson
severity: normal
status: open
title: PyOS_vsnprintf() potential integer overflow leads to memory corruption
on esoteric architectures
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2589
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2584] numeric overflow in IDLE
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I wonder why do you suspect a numeric overflow. It may very well be that the system needs more time to become responsive, when the script is run by Idle. Idle actually spawns another python process to execute commands. then the cmd prompts will close Did you try to close the cmd window? -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2584 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2590] S_unpack_from() Read Access Violation
New submission from Justin Ferguson [EMAIL PROTECTED]:
The S_unpack_from() function in Modules/_struct.c does not adequately
validate its arguments, potentially causing an out-of-bounds read
access. It should be noted that the check at line 1561 is inadequate for
obscene values of offset. Finally, because they're not really important
and I really don't want to type them all up-- you guys might want to go
through your code-- especially the modules and look for constructs where
an empty string will cause memory to be uninitialized-- look at the
audioop module for examples of what I mean-- the only thing that
actually saved you guys from overflows there was that the loops you
write with use the same variable.
1533 static PyObject *
1534 s_unpack_from(PyObject *self, PyObject *args, PyObject *kwds)
1535 {
1536 static char *kwlist[] = {buffer, offset, 0};
1537 #if (PY_VERSION_HEX 0x0205)
1538 static char *fmt = z#|i:unpack_from;
1539 #else
1540 static char *fmt = z#|n:unpack_from;
1541 #endif
1542 Py_ssize_t buffer_len = 0, offset = 0;
[...]
1547
1548 if (!PyArg_ParseTupleAndKeywords(args, kwds, fmt, kwlist,
1549 buffer, buffer_len,
offset))
1550 return NULL;
[...]
1558 if (offset 0)
1559 offset += buffer_len;
1560
1561 if (offset 0 || (buffer_len - offset) soself-s_size) {
[...]
1566 }
1567 return s_unpack_internal(soself, buffer + offset);
1568 }
--
components: Extension Modules
messages: 65178
nosy: jnferguson
severity: normal
status: open
title: S_unpack_from() Read Access Violation
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2590
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue643841] New class special method lookup change
Nick Coghlan [EMAIL PROTECTED] added the comment: I spent an enlightening evening browsing through the source code for weakref.proxy. The way that code works is to define every slot, delegating to the proxied object to handle each call (wrapping and unwrapping the proxied object as needed). This is normally transparent to the user due to the fact that __getattribute__ is one of the proxied methods (and at the C level, the delegated slot invocations return NotImplemented or set the appropriate exceptions). The only way it shows through is the fact that operator.isNumber and operator.isMapping will always return True for the proxy instance, and operator.isSequence will always return False - this is due to the proxy type filling in the number and mapping slots, but not the sequence slots. However, this prompted me to try an experiment (Python 2.5.1), and the results didn't fill me with confidence regarding the approach of expecting 3rd party developers to explicitly delegate all of the special methods: class Demo: ... def __index__(self): ... return 1 ... a = Demo() b = weakref.proxy(a) operator.index(a) 1 operator.index(b) Traceback (most recent call last): File stdin, line 1, in module TypeError: 'weakproxy' object cannot be interpreted as an index Oops. Tracker [EMAIL PROTECTED] http://bugs.python.org/issue643841 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2591] ErrorHandler buffer overflow in ?unused? SGI extension module almodule.c
New submission from Justin Ferguson [EMAIL PROTECTED]:
I don't think any of these SGI modules even get used, but they're really
buggy-- you guys might want to consider just dropping them all together.
When printing errors larger than 128 bytes a stack based overflow occurs.
44 static void
45 ErrorHandler(long code, const char *fmt, ...)
46 {
47 va_list args;
48 char buf[128];
49
50 va_start(args, fmt);
51 vsprintf(buf, fmt, args);
52 va_end(args);
53 PyErr_SetString(ErrorObject, buf);
54 }
--
components: Extension Modules
messages: 65180
nosy: jnferguson
severity: normal
status: open
title: ErrorHandler buffer overflow in ?unused? SGI extension module almodule.c
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2591
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsane
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: This is done already: the second line in PyString_FromStringAndSize() is assert(size=0); You have to build python in debug mode though... Oh, I realize this is not a real patch: no error is raised, and why PYSSIZE_T_MAX/sizeof(PyStringObject), when the allocation is PyObject_MALLOC(sizeof(PyStringObject)+size)? -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2592] weakref.proxy fails to delegate tp_index slot
New submission from Nick Coghlan [EMAIL PROTECTED]: From the discussion of issue 643841: class Demo: ... def __index__(self): ... return 1 ... a = Demo() b = weakref.proxy(a) operator.index(a) 1 operator.index(b) Traceback (most recent call last): File stdin, line 1, in module TypeError: 'weakproxy' object cannot be interpreted as an index The weakref proxy types need to be updated to delegate 2.5's new tp_index slot. -- components: Library (Lib) messages: 65182 nosy: ncoghlan severity: normal status: open title: weakref.proxy fails to delegate tp_index slot versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2592 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2593] alp_ReadFrames() integer overflow leads to buffer overflow
New submission from Justin Ferguson [EMAIL PROTECTED]:
Please see bug 2591 for a suggestion on what to do with these SGI modules.
(sorry I don't have any pocs/repros I dont have an sgi box handy atm)
Integer overflow/invalid allocation at 768, write to memory at 773
716 static PyObject *
717 alp_ReadFrames(alpobject *self, PyObject *args)
718 {
719 int framecount;
720 PyObject *v;
721 int size;
722 int ch;
723 ALconfig c;
724
725 if (!PyArg_ParseTuple(args, i:ReadFrames, framecount))
726 return NULL;
727 if (framecount 0) {
728 PyErr_SetString(ErrorObject, negative framecount);
729 return NULL;
730 }
[...] 732 switch (alGetSampFmt(c)) {
733 case AL_SAMPFMT_TWOSCOMP:
734 switch (alGetWidth(c)) {
735 case AL_SAMPLE_8:
736 size = 1;
737 break;
738 case AL_SAMPLE_16:
739 size = 2;
740 break;
741 case AL_SAMPLE_24:
742 size = 4;
743 break;
744 default:
745 PyErr_SetString(ErrorObject, can't
determine width);
746 alFreeConfig(c);
747 return NULL;
748 }
749 break;
750 case AL_SAMPFMT_FLOAT:
751 size = 4;
752 break;
753 case AL_SAMPFMT_DOUBLE:
754 size = 8;
755 break;
756 default:
757 PyErr_SetString(ErrorObject, can't determine format);
758 alFreeConfig(c);
759 return NULL;
760 }
761 ch = alGetChannels(c);
762 alFreeConfig(c);
763 if (ch 0) {
764 PyErr_SetString(ErrorObject, can't determine # of
channels);
765 return NULL;
766 }
767 size *= ch;
768 v = PyString_FromStringAndSize((char *) NULL, size *
framecount);
769 if (v == NULL)
770 return NULL;
771
[...]
773 alReadFrames(self-port, (void *) PyString_AS_STRING(v),
framecount);
--
components: Extension Modules
messages: 65183
nosy: jnferguson
severity: normal
status: open
title: alp_ReadFrames() integer overflow leads to buffer overflow
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2593
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I think that programming errors against the python API are best checked with asserts: I develop in development mode (with asserts enabled), then I want my released program to run at full speed. Other thoughts? -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsane
Justin Ferguson [EMAIL PROTECTED] added the comment: The problem with assert()'s is they require debugging to be enabled, obviously, who compiles it that way? You may not even want to worry about the second check, when you pass it into the allocator it gets converted to an unsigned int which will cause the allocator to either fail (32-bit) or allocate more memory than expected-- either cause it handled/benign. If you'd prefer I can file every place where this actually bites you guys, I was just trying to be nice. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
Justin Ferguson [EMAIL PROTECTED] added the comment: I can generally agree with that, and I admit I haven't verified all of the code paths here- theres several hundred of them leading into this function, are you positive all of them are safe? (seems like it would be easier to just move the check into an if than sitting down and verifying that all XXX hundred code paths are safe). In the other bug, I have verified code paths into it, for instance test the misallocation poc in 2586 as an example __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsane
Justin Ferguson [EMAIL PROTECTED] added the comment: Adding a poc from 2586 to demonstrate my point, this causes a call to the allocator requesting zero bytes. Added file: http://bugs.python.org/file9985/python-2.5.2-zlib-unflush-misallocation.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2594] alp_readsamps() overflow leads to memory corruption in ?unused? SGI extension module almodule.c
New submission from Justin Ferguson [EMAIL PROTECTED]:
You guys should probably just remove the SGI modules, the code looks
like it hasn't been touched in some time and hasn't gone through the
same security checks as other pieces of code. Sorry I have no
repro's/pocs, I don't have an irix box either though ;]
integer overflow/misallocation occurs at 1071, write to bad memory at 1076
1042 alp_readsamps(alpobject *self, PyObject *args)
1043 {
1044 long count;
1045 PyObject *v;
1046 ALconfig c;
1047 int width;
1048 int ret;
1049
1050 if (!PyArg_ParseTuple(args, l:readsamps, count))
1051 return NULL;
1052
1053 if (count = 0) {
1054 PyErr_SetString(ErrorObject, al.readsamps : arg =
0);
1055 return NULL;
1056 }
1057
1058 c = ALgetconfig(self-port);
1059 #ifdef AL_405
1060 width = ALgetsampfmt(c);
1061 if (width == AL_SAMPFMT_FLOAT)
1062 width = sizeof(float);
1063 else if (width == AL_SAMPFMT_DOUBLE)
1064 width = sizeof(double);
1065 else
1066 width = ALgetwidth(c);
1067 #else
1068 width = ALgetwidth(c);
1069 #endif /* AL_405 */
1070 ALfreeconfig(c);
1071 v = PyString_FromStringAndSize((char *)NULL, width * count);
1072 if (v == NULL)
1073 return NULL;
1074
1075 Py_BEGIN_ALLOW_THREADS
1076 ret = ALreadsamps(self-port, (void *)
PyString_AsString(v), count);
1077 Py_END_ALLOW_THREADS
1078 if (ret == -1) {
1079 Py_DECREF(v);
1080 return NULL;
1081 }
1082
1083 return (v);
1084 }
--
components: Extension Modules
messages: 65188
nosy: jnferguson
severity: normal
status: open
title: alp_readsamps() overflow leads to memory corruption in ?unused? SGI
extension module almodule.c
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2594
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: You can't change the codec - it's being used in other places as well, e.g. for use cases where you need to have a 7-bit encoded readable version of a Unicode object. Adding a new codec would be fine, though I don't know how this would map raw Unicode strings with non-ASCII characters in them to an 8-bit string. Perhaps this is not needed at all in Py3k. -- nosy: +lemburg __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2541 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2592] weakref.proxy fails to delegate tp_index slot
Nick Coghlan [EMAIL PROTECTED] added the comment: Marking as easy - it should be possible to just look at what the code in Objects\weakref.c is already doing for slots like tp_len and tp_int and do the same thing for tp_index. -- keywords: +easy __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2592 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
Justin Ferguson [EMAIL PROTECTED] added the comment: Just so you know, the scripts actually do two different things-- the bugs are both related to negative values though. One causes PyString_FromStringAndSize() to try an allocate zero bytes (the -24 one), the other causes like 22 bytes to get allocated and then takes advantage of the sign-conversion when the value is assigned to the zlib structure member (the member is unsigned, the value is signed) Honestly, you guys should consider enforcing the safe downcast usage because signedness issues are all over your code base (as I'm sure you know) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2584] numeric overflow in IDLE
Tim Wilcoxson [EMAIL PROTECTED] added the comment: msg65177, i did try to close cmd. thats why it closed. i wasnt clear enough. my apologies. it merely lags in command line in gives a memory error. in IDLE, it wont respond, and it gives a logon process erorr in windows if you try to view the security dialog. Let's just say this. i got dressed, walked out my apartment several flights of strairs, went across a large parking lot, grabbed a bag, came back, got comfortable, looked at my computer, and it was still completely unresponsive. I did this several times, same problem. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2584 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1536059] Missing builtin help for with and as
Nick Coghlan [EMAIL PROTECTED] added the comment: Georg Brandl applied Santiago's patch in rev. 54329, 54330 -- resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1536059 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2595] Multiple integer overflows in imgfile extension module lead to buffer overflow
New submission from Justin Ferguson [EMAIL PROTECTED]:
The imgfile module contains multiple integer overflows, this module is
only used on SGI boxes and is likely mostly unused and thus is fairly
low priority imho-- no repros, no poc, no sgi box :/
I'm only going to post one to give you the idea, there's no need for me
to (further) spam the bug database by filing a bug for each one of
these, they're all pretty much the same.
Here the variables xsize, ysize and zsize are all externally derived.
While xsize and zsize are sanity checked, ysize is not. This potentially
results in an integer overflow/misallocation at line 133 and writes to
invalid memory in the calls to getrow()
85 static PyObject *
86 imgfile_read(PyObject *self, PyObject *args)
87 {
88 char *fname;
89 PyObject *rv;
90 int xsize, ysize, zsize;
91 char *cdatap;
92 long *idatap;
93 static short rs[8192], gs[8192], bs[8192];
94 int x, y;
95 IMAGE *image;
96 int yfirst, ylast, ystep;
97
98 if ( !PyArg_ParseTuple(args, s:read, fname) )
99 return NULL;
100
101 if ( (image = imgfile_open(fname)) == NULL )
102 return NULL;
[...]
116 xsize = image-xsize;
117 ysize = image-ysize;
118 zsize = image-zsize;
119 if ( zsize != 1 zsize != 3) {
120 iclose(image);
121 PyErr_SetString(ImgfileError,
122 Can only handle 1 or 3 byte pixels);
123 return NULL;
124 }
125 if ( xsize 8192 ) {
126 iclose(image);
127 PyErr_SetString(ImgfileError,
128 Can't handle image with 8192
columns);
129 return NULL;
130 }
131
132 if ( zsize == 3 ) zsize = 4;
133 rv = PyString_FromStringAndSize((char *)NULL,
xsize*ysize*zsize);
134 if ( rv == NULL ) {
138 cdatap = PyString_AsString(rv);
139 idatap = (long *)cdatap;
[...]
150 for ( y=yfirst; y != ylast !error_called; y += ystep ) {
151 if ( zsize == 1 ) {
152 getrow(image, rs, y, 0);
153 for(x=0; xxsize; x++ )
154 *cdatap++ = rs[x];
155 } else {
156 getrow(image, rs, y, 0);
157 getrow(image, gs, y, 1);
158 getrow(image, bs, y, 2);
159 for(x=0; xxsize; x++ )
160 *idatap++ = (rs[x] 0xff) |
161 ((gs[x] 0xff)8) |
162 ((bs[x] 0xff)16);
163 }
164 }
--
components: Extension Modules
messages: 65194
nosy: jnferguson
severity: normal
status: open
title: Multiple integer overflows in imgfile extension module lead to buffer
overflow
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2595
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1184112] Missing trailing newline with comment raises SyntaxError
Nick Coghlan [EMAIL PROTECTED] added the comment: As of 2.5.1, a missing trailing newline no longer causes a Syntax Error, making the second part of the caveat in the documentation unnecessary. Changing to a documentation bug applicable to 2.5+. -- assignee: - georg.brandl components: +Documentation -Interpreter Core keywords: +easy nosy: +georg.brandl type: - behavior versions: +Python 2.5, Python 2.6, Python 3.0 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1184112 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2595] Multiple integer overflows in imgfile extension module lead to buffer overflow
Justin Ferguson [EMAIL PROTECTED] added the comment: I'm not going to file a different bug for rgbimgmodule.c, it has the same types of issues. Sorry, I don't mean to drop a ton of bugs, I'm prepping up to do a talk on attacking the metadata in scripting languages (i.e. the python call stack instead of the processors) and I need to have these public/patched before I talk about them. I've got a bunch more bugs, I'll file them later when some of this stuff is caught up with. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2595 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsane
Justin Ferguson [EMAIL PROTECTED] added the comment:
As an addemdum, consider the following code (theres no assert, but it
wouldnt have helped you outside of debug builds anyways):
488 static PyObject *PySSL_SSLread(PySSLObject *self, PyObject *args)
489 {
490 PyObject *buf;
491 int count = 0;
492 int len = 1024;
[...]
496 if (!PyArg_ParseTuple(args, |i:read, len))
497 return NULL;
498
499 if (!(buf = PyString_FromStringAndSize((char *) 0, len)))
500 return NULL;
[...]
521 count = SSL_read(self-ssl, PyString_AsString(buf),
len);
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2587
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue992389] attribute error after non-from import
Nick Coghlan [EMAIL PROTECTED] added the comment: I think the lowered priority got lost somewhere along the line. -- priority: normal - low Tracker [EMAIL PROTECTED] http://bugs.python.org/issue992389 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2576] httplib read() very slow due to lack of socket buffer
Facundo Batista [EMAIL PROTECTED] added the comment: Daniel, Aren, please submit also what Daniel described, and I'll take a look and push it forward. Regards, -- nosy: +facundobatista __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2576 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2571] cmd.py always uses raw_input, even when another stdin is specified
Richard King [EMAIL PROTECTED] added the comment: (this is really 2 mails because my home email address was not registered so they were rejected at first) Right - I wasn't too clear. The module stashes stdin, whether from sys or passed in, in self.stdin. When it reads input it uses a flag raw_input to determine whether to use raw_input or self.stdin.readline(), but the flag is not reset when a different stdin is passed in, so raw_input is always true. The flag should be True/False, and I didn't think of setting it directly to be honest because it never occurred to me that I should have to do that to get a cmd class that i just instantiated with a different input object to use the one it was created with. I think the flag should be eliminated and replaced with the test self.stdin == sys.stdin anyway. I also entered a feature request to add a stack of stdin's which are stacked when you want to process lines in a file, and then pop off the stack automatically at end of file. This would make it easy to write a command-line tool, like i'm doing, so that any input object could enter commands that change to other input objects and then restore the previous input objectthis would allow for nesting of command files. There would be special conditions for sys.stdin (sys.stdin can only be used if there are no items on the stack). This could all be done outside the module, but it's so easy when it's integrated right in there. I think I understand better what you are getting at, but it makes more sense to me to be explicit in the code and not take advantage of the fact the raw_input always works off sys.stdin. Also, I see now that maybe the idea was to have raw_input be changeable so that you could switch back and forth between stdin (whatever that is), and some other input object - I'm having a hard time seeing the usefulness of that, though. Anyway, instantiating a cmd class with a non-stdin input object and then having to set raw_input to False to get it to use that input object seems wrong. does this make sense? -Rick King Daniel Diniz wrote: Daniel Diniz [EMAIL PROTECTED] added the comment: I don't think it should stop using raw_input just because you changed stdin, as you can change it to something that will work with raw_input. Consider: import sys sys.stdin = open(/dev/tty) raw_input() a 'a' You can tie it to any object (e.g. a GUI input) that supports the file protocol and keep using raw_input. Or change Cmd.use_rawinput to 0 to use stdin.readline directly. On a related issue. Cmd.use_rawinput should be True, not 1... -- nosy: +ajaksu2 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2571 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2571 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2564] Python hangs on FreeBSD7 in test_capi
Taavi Repän [EMAIL PROTECTED] added the comment: I don't that the problem is in tests. For example import pygtk import gtk hangs also. I don't have backtrace for PyGtk hang yet, but it hangs in ucond state too (like test_capi). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2564 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2584] numeric overflow in IDLE
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: So let's it interpret this way: range(1, 3) consumes more and more memory, and causes the system to hang. When python.exe is in a console, you have the ability to close the window and kill the process. When using Idle, the interpreter cannot be killed so easily: I suppose you closed the main windows, but this did not kill the subprocess used to run commands. BTW1: did you try xrange(1, 3000) BTW2: msg65177 is not a pseudo... it's the message ID in the bug tracker ;-) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2584 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1285086] urllib.quote is too slow
Daniel Diniz [EMAIL PROTECTED] added the comment: This is what I found doing some timings: For the short-circuit path, the regexp can make quote 10x as fast in exceptional cases, even comparing to the faster version in trunk. The average win for short-circuit seems to be twice as fast as the map in my timings. This sounds good. For the normal path, the overhead can make quote 50% slower. This IMHO makes it unfit for quote replacement. Perhaps good for a cookbook recipe? Regarding the OP's use case, I believe either adding a string cache to quote or flagging stored strings as safe or must quote would result in a much greater impact on performance. Attaching patch against trunk. Web framework developers should be interested in testing this and could provide the use cases/data needed for settling this issue. -- keywords: +patch nosy: +ajaksu2 Added file: http://bugs.python.org/file9986/urllib.quote.patch _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1285086 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2596] 2to3's fix_range needs fix_dict's context information
New submission from Collin Winter [EMAIL PROTECTED]: 2to3 should be able to translate the code snippet below successfully. First guess: generalizing fix_dict's notion of special contexts would do the trick. import random numbers = range(1, 50) chosen = [] while len(chosen) 6: number = random.choice(numbers) numbers.remove(number) chosen.append(number) chosen.sort() print(This week's numbers are, chosen) print(The bonus ball is, random.choice(numbers)) -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 65204 nosy: collinwinter priority: normal severity: normal status: open title: 2to3's fix_range needs fix_dict's context information type: behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2596 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2584] numeric overflow in IDLE
Tim Wilcoxson [EMAIL PROTECTED] added the comment: not a nick aye? lol. I am new cant you tell. And when i ran the script nothing could be closed. And, yes, I realize it could be a memory exhaustion issue with windows. windows is notorious for crappy resource handling. However, my concern came when I actually got an error and a clean exit with cmd prompt but not with the GUI. explorer.exe didn't crash. And I've had memory exhaustion under windows before, and it still allowed me enough memory to (albeit slowly) ctrl-alt-del. However the login process wouldnt even function. I did try xrange, it hung as the other. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2584 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2597] python2.6 -3 should report list.sort(cmp) as DeprecationWarning
New submission from Bruce Frederiksen [EMAIL PROTECTED]: this is not reported in 2.6a1. -- components: Interpreter Core messages: 65207 nosy: dangyogi severity: normal status: open title: python2.6 -3 should report list.sort(cmp) as DeprecationWarning type: feature request versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2597 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2597] python2.6 -3 should report list.sort(cmp) as DeprecationWarning
Raymond Hettinger [EMAIL PROTECTED] added the comment: Already done in 2.6a2 -- nosy: +rhettinger resolution: - out of date status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2597 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2598] { +(}.format(**{' +(': 44}) should produce ValueError: invalid identifier, ' +(' in format
New submission from Bruce Frederiksen [EMAIL PROTECTED]:
Format strings are documented to only allow identifiers or integers as
the field_name, but allow almost anything.
Python 3.0a3
--
components: Interpreter Core
messages: 65209
nosy: dangyogi
severity: normal
status: open
title: { +(}.format(**{' +(': 44}) should produce ValueError: invalid
identifier, ' +(' in format
type: behavior
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2598
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2599] allow field_name in format strings to default to next positional argument (e.g., {})
New submission from Bruce Frederiksen [EMAIL PROTECTED]:
Being forced to number the arguments when using positional arguments in
a format string is difficult to maintain. Adding an argument to the
format string either requires renumbering all subsequent arguments, or
using an out of sequence number such that the order of the format()
arguments no longer matches the order of the {...} arguments. Making
the integer optional would solve this. Thus, {} would be like the old
%s where it was far easier to add %s arguments in the middle of the
format string.
Python 3.0a3
--
components: Interpreter Core
messages: 65210
nosy: dangyogi
severity: normal
status: open
title: allow field_name in format strings to default to next positional
argument (e.g., {})
type: feature request
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2599
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Changes by Marc-Andre Lemburg [EMAIL PROTECTED]: __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2541 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: You can't change the codec - it's being used in other places as well, e.g. for use cases where you need to have an 8-bit encoded readable version of a Unicode object (which happens to be Latin-1 + Unicode escapes for all non-Latin-1 characters, due to Unicode being a superset of Latin-1). Adding a new codec would be fine, though I don't know how this would map raw Unicode strings with non-Latin-1 characters in them to an 8-bit string. Perhaps this is not needed at all in Py3k. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2541 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Isn't unicode-escape enough for this purpose? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2541 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.
Martin v. Löwis [EMAIL PROTECTED] added the comment:
But write_pkg_file will use ascii encoding if we don't indicate it
here:
pkg_info.write('Author: %s\n' % self.get_contact() )
Why do you say that it uses ascii? It uses whatever encoding the string
returned by get_contact uses. See the attached P1-1.0.tar.gz for an
example. This doesn't use ASCII, and doesn't use UTF-8, and works with
2.4.
So wouldn't a light fix in write_pkg_file() would be sufficient when a
unicode(field) fails, as MAL mentioned ? by trying utf8:
try:
...pkg_info.write('Author: %s\n' % self.get_contact() )
... except UnicodeEncodeError:
...pkg_info.write('Author: %s\n' % self.get_contact().encode('utf8') )
That would work - although I fail to see what this has to do with
a failing unicode(field). Instead, it has rather to do with a failing
.write().
Added file: http://bugs.python.org/file9987/P1-1.0.tar.gz
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2562
__
P1-1.0.tar.gz
Description: GNU Zip compressed data
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2585] urllib2.HTTPError broken due to urllib.addinfourl changes
Changes by djc [EMAIL PROTECTED]: -- nosy: +georg.brandl -birkenfeld __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2585 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.
Tarek Ziadé [EMAIL PROTECTED] added the comment:
pkg_info.write('Author: %s\n' % self.get_contact() )
Why do you say that it uses ascii? It uses whatever encoding the string
returned by get_contact uses. See the attached P1-1.0.tar.gz for an
example. This doesn't use ASCII, and doesn't use UTF-8, and works with
2.4.
This happens of course only when get_contact returns an unicode.
It uses the ascii codec by default. Here's an example:
contact = u'Barnabé'
f = open('/tmp/test', 'w')
f.write('Author: %s' % contact)
Traceback (most recent call last):
File stdin, line 1, in module
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 14: ordinal not in range(128)
That would work - although I fail to see what this has to do with
a failing unicode(field). Instead, it has rather to do with a failing
.write().
Absolutely, I was focusing on write_pkg_file() method that fails
when the egg-info file is written.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2562
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2564] Python hangs on FreeBSD7 in test_capi
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: In any case, I reproduce the problem on Windows too. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2564 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2600] BindingHTTPConnectionWithTimeout and BindingHTTPHandlerWithTimeout
New submission from Pau Aliagas [EMAIL PROTECTED]: I wanted to use urllib2 with something as usual as binding to a given network interface and it was incredibly complex. I also did not like the usual propodes solution to timeout the connections: set the global socket timeour. I needed a different timeout for each connection. So I took my time, I learnt about httplib and urllib2 and made a patch to enhance both libraries. BindingHTTPConnectionWithTimeout extends HTTPConection with supports timeouts and a binding address. BindingHTTPHandlerWithTimeout extends HTTPHandler and basically uses the new http class provided. The patch is really simple and would make a great addition to the standard library. I've tried to follow the style amd copied similar methods, giving the due credits. I hope you find it useful and consider it for inclusion. -- components: Library (Lib) files: urllib2_util.py messages: 65215 nosy: pau severity: normal status: open title: BindingHTTPConnectionWithTimeout and BindingHTTPHandlerWithTimeout type: feature request versions: Python 2.4, Python 2.5 Added file: http://bugs.python.org/file9988/urllib2_util.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2600 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
Changes by Alexander Belopolsky [EMAIL PROTECTED]: -- title: PyString_FromStringAndSize() to be considered unsane - PyString_FromStringAndSize() to be considered unsafe __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2530] Document IO module
Benjamin Peterson [EMAIL PROTECTED] added the comment: Attaching an updated patch from a review Mark Summerfield. Added file: http://bugs.python.org/file9989/io_doc3.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2530 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2563] embed manifest in windows extensions
Mark Hammond [EMAIL PROTECTED] added the comment: Note that we are actually using the linker to *generate* the manifest (something linkers pre VC2005 couldn't do), so if we could tell the linker to skip that manifest generation and embed it directly in the DLL, it would certainly be easier. But, IIRC (which I may not), you can embed a manifest directly via the linker by converting the manifest to a resource and linking that - however, that conversion still requires an extra tool. This is the alternative process outlined on the MS page I linked to. And finally, it seems Visual Studio itself embeds the resource this way. So if there is a way to embed the manifest without an additional step, I don't know about it :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2563 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time
New submission from Matthias Klose [EMAIL PROTECTED]: r61009 on the 2.5 branch - Bug #1389051, 1092502: fix excessively large memory allocations when calling .read() on a socket object wrapped with makefile(). causes a regression compared to 2.4.5 and 2.5.2: When reading from urllib2 file descriptor, python will read the data a byte at a time regardless of how much you ask for. python versions up to 2.5.2 will read the data in 8K chunks. This has enough of a performance impact that it increases download time for a large file over a gigabit LAN from 10 seconds to 34 minutes. (!) Trivial/obvious example code: f = urllib2.urlopen(http://launchpadlibrarian.net/13214672/nexuiz-data_2.4.orig.tar.gz;) while 1: chunk = f.read() ... and then strace it to see the recv()'s chugging along, one byte at a time. -- assignee: akuchling components: Library (Lib) messages: 65219 nosy: akuchling, doko priority: high severity: normal status: open title: [regression] reading from a urllib2 file descriptor happens byte-at-a-time type: performance versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2601 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2564] Python hangs on FreeBSD7 in test_capi
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Committed r62229. Please file a separate issue for the gtk module, it's really another thing. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2564 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2408] types module can be implemented only in Python
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Committed r62231: remove _types module. I did not add CellType though, because of discussion in #1605. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2408 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2596] 2to3's fix_xrange needs fix_dict's context information
Collin Winter [EMAIL PROTECTED] added the comment: Fixed in r62232. Verified that the sample code below runs successfully under Python 3.0a4+ (r62209) after being run through 2to3. -- resolution: - fixed status: open - closed title: 2to3's fix_range needs fix_dict's context information - 2to3's fix_xrange needs fix_dict's context information __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2596 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: What do you mean with enough ? The raw-unicode-escape codec is used in Python 2.x to convert literal strings of the form ur to Unicode objects. It's a variant of the unicode-escape codec. The codec is also being used in cPickle, pickle, variants of pickle, Python code generators, etc. It serves its purpose, just like unicode-escape and all the other codecs in Python. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2541 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Trent Nelson [EMAIL PROTECTED] added the comment: Committed updates to relevant network-oriented tests, as well as test_support changes discussed, in r62234. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2550 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I mean: now that raw strings cannot represent all unicode points (or more precisely, they need the file encoding to do so), is there a use case for raw-unicode-escape that cannot be filled by the unicode-escape codec? Note that pickle does not use raw-unicode-escape as is: it replaces backslashes by \u005c. This has the nice effect that pickled strings can also be decoded by unicode-escape. That's why I propose to completely remove raw-unicode-escape, and use unicode-escape instead. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2541 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
Alexander Belopolsky [EMAIL PROTECTED] added the comment: As long as snprintf is used with a fixed size buffer using an idiom snprintf(buffer, sizeof(buffer), ..) there is no issue because sizeof(buffer) cannot be zero. AFAICT, this is how python uses PyOS_vsnprintf wrapper. On the other hand, may this is a good opportunity to revisit the decision to make PyOS_vsnprintf semantics different from C99 vsnprintf. C99 defines snprintf semantics as follows: int snprintf(char *restrict s, size_t n, const char *restrict format, ...); The snprintf() function shall be equivalent to sprintf(), with the addition of the n argument which states the size of the buffer referred to by s. If n is zero, nothing shall be written and s may be a null pointer. Otherwise, output bytes beyond the n-1st shall be discarded instead of being written to the array, and a null byte is written at the end of the bytes actually written into the array. http://www.opengroup.org/onlinepubs/95399/functions/printf.html -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
Justin Ferguson [EMAIL PROTECTED] added the comment: I do agree with your point about snprintf(..., sizeof(x), ...)-- my single biggest point (and maybe i'm just not seeing it), is that there appears to be no good reason for having this caveat and in turn its essentially just code waiting to break; with as commonly used of a function as it is, it's really a matter of when and not so much if. While no one seems to ever use it this way, don't forget that a good alternative to asprintf() is calling sprintf() with a length of zero to get the length (in compliant implementations), allocating the memory and then calling it again. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Tue, Apr 8, 2008 at 9:21 PM, Justin Ferguson [EMAIL PROTECTED] wrote: .. While no one seems to ever use it this way, don't forget that a good alternative to asprintf() is calling sprintf() with a length of zero to get the length (in compliant implementations), allocating the memory and then calling it again. Remember that PyOS_vsnprintf was introduced back in 2001 when (according to the comments in the file) not all platforms provided c99 compliant implementations. If you can verify that the situation has changes for the supported platforms, I think you will have a good case for making the wrapper c99 compliant. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
Alexander Belopolsky [EMAIL PROTECTED] added the comment: This has just been fixed in the trunk: r62235. -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
Raymond Hettinger [EMAIL PROTECTED] added the comment: Thx -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2454] sha and md5 fixer
Changes by Collin Winter [EMAIL PROTECTED]: -- priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2454 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2410] absolute import doesn't work for standard python modules
Nick Coghlan [EMAIL PROTECTED] added the comment: Using relative imports within smtplib wouldn't have made any difference in this case. Your dummy email package was the first one encountered on sys.path, so the import email.smtplib line (which does an import email internally as the first step in resolving the import, and then tries to find smtplib in email.__path__) picked it up. Putting an internal package directory on sys.path (as your example does) is seriously bad ju-ju. It's one of the main reason why people are so strongly discouraged from directly executing files that are stored in package directories (along with another nasty side effect in getting two different copies of the same module using different names, it also has the same effect as what you did here - subpackages/modules can end up overriding standard library modules and packages because the script directory gets placed on sys.path). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2410 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2576] httplib read() very slow due to lack of socket buffer
Daniel Diniz [EMAIL PROTECTED] added the comment: The code patch is trivial, he said, only to find out it was not :) Facundo, thanks in advance for taking a look at this! This patch tries to implement, document and test an optional argument to HTTPConnection, which passes it to HTTPResponse. So far, it's called sockbuf, but I truly hope we can find a better name. The crux of the test is that it shouldn't be possible to use a buffered socket and a persistent connection simultaneously, as that was the reason a buffer was left out (see issue 508157). It also tries to check correctly allowing Keep-Alive when sockbuf==0. However, it fails to exercise HTTPResponse properly and needs a review down the auto-reconnect path. Persistent connections should be tested. Regarding the code, there's a chance that some changes touching forced closing are bogus (but not harmful). I'll get back to it and to persistent connection tests. Thanks again :) Added file: http://bugs.python.org/file9990/buffered_socket.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2576 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
