[issue20924] openssl init 100% CPU utilization
New submission from bob bob: We have written a server on Python 2.7.6 that uses openssl 0.9.8y running on Windows box. Time to time our server freezes utilizing 100% CPU on ssl_init (C routine). The following is the process stack: 0021ee80 10036d19 0176d259 0013 msvcr90+0x3b35d 0021ee9c 10022a22 0021ef1c 0176d218 1001bf62 _ssl!init_ssl+0x33b59 0021ef74 10073920 0176a158 0177ba18 00952a78 _ssl!init_ssl+0x1f862 0021ef84 10001714 0176a158 0147b350 _ssl!init_ssl+0x70760 0021ef88 0176a158 0147b350 00952a78 _ssl+0x1714 0021ef8c 0147b350 00952a78 0x176a158 0021ef90 00952a78 100d3038 0x147b350 This problem occurs when client connects to our server using slow modem channel. In this case client sends duplicated SYN TCP packet. When second SYN packet arrives to the server after SYN_ACK server's packet we have a trouble. Like this trace from server side: 140 38.80741 172.16.35.6 192.168.52.1 TCP 74 44697 > 20444 [SYN] Seq=0 Win=14600 Len=0 MSS=1314 SACK_PERM=1 TSval=495224007 TSecr=0 WS=16 141 38.807428000 192.168.52.1 172.16.35.6 TCP 78 20444 > 44697 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 148 39.288557000 172.16.35.6 192.168.52.1 TCP 74 44697 > 20444 [SYN] Seq=0 Win=14600 Len=0 MSS=1314 SACK_PERM=1 TSval=495224257 TSecr=0 WS=16 -- components: Library (Lib), Windows messages: 213555 nosy: bob.bob priority: normal severity: normal status: open title: openssl init 100% CPU utilization type: resource usage versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue20924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20924] openssl init 100% CPU utilization
bob bob added the comment: loewis: This is correct stack: 0021ee80 10036d19 0176d259 0013 msvcr90!memset+0x3d 0021ee9c 10022a22 0021ef1c 0176d218 1001bf62 _ssl!SHA1_Final+0x49 0021eea8 1001bf62 0021ef0c 0021ef1c 0146 _ssl!OPENSSL_cleanse+0x92 0021eebc 10010319 0021ef0c 0021ef1c _ssl!EVP_DigestFinal_ex+0x32 0021ef30 100035f3 0021ef74 0004 _ssl!RAND_SSLeay+0x2a9 0021ef44 10085da0 0021ef74 0004 _ssl!RAND_add+0x63 0021ef74 10073920 0176a158 0177ba18 00952a78 _ssl!ssl3_accept+0x40 0021ef84 10001714 0176a158 0147b350 _ssl!SSL_do_handshake+0x50 0021ef8c 0147b350 00952a78 _ssl!PySSL_SSLdo_handshake+0x74 [c:\users\martin\27\python\modules\_ssl.c @ 478] 0021ef90 00952a78 100d3038 0x147b350 dump file attached. Packets from 5 to 8 received after client process has been terminated. Thereafter, the CPU freed. -- Added file: http://bugs.python.org/file34514/server_side.pcap ___ Python tracker <http://bugs.python.org/issue20924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
Change by Bob : -- components: asyncio nosy: Bob_2021, asvetlov, yselivanov priority: normal severity: normal status: open title: Asyncio can't close sockets properly on Linux cause CLOSE_WAIT type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
New submission from Bob : I wrote a simple proxy with Python3.8 and Asyncio, but I found it couldn't handle passive close correctly, a lot of CLOSE_WAIT sockets couldn't be released. I had trouble shot it for a long time with no progress. netstat -anop tcp | grep CLOSE_WAIT tcp6 0 0 64.XXX.XXX.XXX:80113.58.229.12:46996 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80222.137.35.237:54914CLOSE_WAIT 10485/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80119.39.47.229:53882 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80123.14.254.238:49262CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80121.57.230.51:35036 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80124.235.138.253:44882 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:8036.5.157.219:38006 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80150.255.5.121:39288 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) -- ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
Change by Bob : Added file: https://bugs.python.org/file49799/server.py ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
Change by Bob : -- assignee: -> christian.heimes components: +SSL nosy: +christian.heimes versions: +Python 3.10, Python 3.7, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
Change by Bob : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14420] winreg SetValueEx DWord type incompatible with value argument
New submission from Bob : When calling winreg.SetValueEx(key, value_name, reserved, type, value), the value argument does not support the full range of a 32 bit unsigned integer, which the Window's registry API is expecting. For example, passing a value 0x8000 will result in the following exception: OverflowError: Python int too large to convert to C long. For consistency with the Window's binding, it should support an unsigned long. -- components: Windows messages: 156875 nosy: RoSanford priority: normal severity: normal status: open title: winreg SetValueEx DWord type incompatible with value argument type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue14420> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14420] winreg SetValueEx DWord type incompatible with value argument
Bob added the comment: Likewise, the winreg.QueryValueEx method returns a signed 32 bit value, instead of a 32 bit unsigned value. -- ___ Python tracker <http://bugs.python.org/issue14420> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35180] Ctypes segfault or TypeError tested for python2.7 and 3
New submission from Bob :
~Description of the problem:
I was using ctypes to get a directory file descriptor, and to do so I found
this mailing list (https://lists.gt.net/python/dev/696028) from 2008 where a
user wrote a piece that could do what the asking user and me were looking for.
What concerns me is how much this code has been used when I looked though
Github and Google and came across the same exact pieces.
The code provided looks like this:
from ctypes import CDLL, c_char_p, c_int, Structure, POINTER
from ctypes.util import find_library
class c_dir(Structure):
"""Opaque type for directory entries, corresponds to struct DIR"""
c_dir_p = POINTER(c_dir)
c_lib = CDLL(find_library("c"))
opendir = c_lib.opendir
opendir.argtypes = [c_char_p]
opendir.restype = c_dir_p
dirfd = c_lib.dirfd < -- IT FAILS HERE // STACK TRACE PROVIDED
dirfd.argtypes = [c_dir_p]
dirfd.restype = c_int
closedir = c_lib.closedir
closedir.argtypes = [c_dir_p]
closedir.restype = c_int
dir_p = opendir(".")
print "dir_p = %r" % dir_p
dir_fd = dirfd(dir_p)
print "dir_fd = %r" % dir_fd
print "closed (rc %r)" % closedir(dir_p)
When I implemented it in my machine, I changed it a bit so "opendir()" got its
arguments from an imputed value, and the final program looks like this:
from ctypes import *
import sys
import ctypes
from ctypes.util import find_library
class c_dir(Structure):
"""Opaque type for directory entries, corresponds to struct DIR"""
def get_directory_file_descriptor(directory):
c_dir_p = POINTER(c_dir)
c_lib = CDLL(find_library("c"))
opendir = c_lib.opendir
opendir.argtypes = [c_char_p]
opendir.restype = c_dir_p
dirfd = c_lib.dirfd < -- SAME. FAILS HERE.
dirfd.argtypes = [c_dir_p]
dirfd.restype = c_int
closedir = c_lib.closedir
closedir.argtypes = [c_dir_p]
closedir.restype = c_int
dir_p = opendir("%s" % directory)
print ("dir_p = %s:%r" % (directory, dir_p))
dir_fd = dirfd(dir_p)
print("dir_fd = %r" % dir_fd)
print ("closed (rc %r)" % closedir(dir_p))
get_directory_file_descriptor(sys.argv[1])
When I run it *with python 2.7*, the program runs normally if I enter the
expected value, like "/home/". But if I don't, the program exits with a
segmentation fault.
In python 3, it fails no matter what with a TypeError.
INPUT when NOT giving the error (in python 2.7): /home/
INPUT when giving the error: aaa
~Stack trace from python 2.7:
Program received signal SIGSEGV, Segmentation fault.
dirfd (dirp=0x0) at ../sysdeps/posix/dirfd.c:27
27 ../sysdeps/posix/dirfd.c: No such file or directory.
(gdb) bt
#0 dirfd (dirp=0x0) at ../sysdeps/posix/dirfd.c:27
#1 0x76698e40 in ffi_call_unix64 () from
/usr/lib/x86_64-linux-gnu/libffi.so.6
#2 0x766988ab in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#3 0x768a83df in _call_function_pointer (argcount=1,
resmem=0x7fffd630,
restype=, atypes=, avalues=0x7fffd610,
pProc=0x778b8960 , flags=4353)
at /build/python2.7-dPs3Rr/python2.7-2.7.12/Modules/_ctypes/callproc.c:837
#4 _ctypes_callproc (pProc=0x778b8960 , argtuple=,
flags=4353,
argtypes=(,),
restype=<_ctypes.PyCSimpleType at remote 0xa38ce0>, checker=0x0)
at /build/python2.7-dPs3Rr/python2.7-2.7.12/Modules/_ctypes/callproc.c:1180
#5 0x768acd82 in PyCFuncPtr_call.lto_priv.107
(self=self@entry=0x77e322c0,
inargs=inargs@entry=(,),
kwds=kwds@entry=0x0)
at /build/python2.7-dPs3Rr/python2.7-2.7.12/Modules/_ctypes/_ctypes.c:3954
#6 0x004c15bf in PyObject_Call (kw=0x0, arg=(,),
func=<_FuncPtr(__name__='dirfd') at remote 0x77e322c0>) at
../Objects/abstract.c:2546
#7 do_call (nk=, na=, pp_stack=0x7fffd890,
func=<_FuncPtr(__name__='dirfd') at remote 0x77e322c0>) at
../Python/ceval.c:4567
#8 call_function (oparg=, pp_stack=0x7fffd890) at
../Python/ceval.c:4372
#9 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#10 0x004c136f in fast_function (nk=, na=, n=1,
pp_stack=0x7fffd9b0, func=) at
../Python/ceval.c:4435
#11 call_function (oparg=, pp_stack=0x7fffd9b0) at
../Python/ceval.c:4370
#12 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#13 0x004b9ab6 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#14 0x004eb30f in PyEval_EvalCode (
locals={'c_void_p': <_ctypes.PyCSimpleType at remote 0xa3df50>, 'c_int64':
<_ctypes.PyCSimpleType at remote 0xa1d7b0>, 'c_ssize_t': <_ctypes.PyCSimpleType
at remote 0xa1d7b0>, 'c_longdouble': <_ctypes.PyCSimpleType at remote
0xa3c360>, 'Union': <_ctypes.UnionType at remote 0x76abc400>, 'cdll':
) at remote
[issue35180] Ctypes segfault or TypeError tested for python2.7 and 3
Bob added the comment: Hi Josh thanks for answering me and so quick. So if I understood correctly, by inserting an unexpected and unchecked on value, it could lead to a potential vulnerability in the program? Or just a plain failure (which could be a denial of service also)? Thanks again. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, November 6, 2018 5:07 PM, Josh Rosenberg wrote: > Josh Rosenberg shadowranger+pyt...@gmail.com added the comment: > > The TypeError on Py3 would be because functions taking c_char_p need > bytes-like objects, not str, on Python 3. '%s' % directory is pointless when > directory is a str; instead you need to encode it to a bytes-like object, > e.g. opendir(os.fsencode(directory)) (os.fsencode is Python 3 specific; plain > str works fine on Py 2). > > Your segfault isn't occurring when you load dirfd, it occurs when you call it > on the result of opendir, when opendir returned NULL on failure (due to the > non-existent directory you call it with). You didn't check the return value, > and end up doing flagrantly illegal things with it. > > In neither case is this a bug in Python; ctypes lets you do evil things that > break the rules, and if you break the rules the wrong way, segfaults are to > be expected. Fix your argument types (for Py3), check your return values (for > Py2). > > --- > > nosy: +josh.r > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > Python tracker rep...@bugs.python.org > https://bugs.python.org/issue35180 -- ___ Python tracker <https://bugs.python.org/issue35180> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8995] Performance issue with multiprocessing queue (3.1 VS 2.6)
New submission from Bob :
Hi,
I've found a strange performance issue when comparing queue.queue and
multiprocessing.queue in python 2.6 and 3.1
My program creates a queue, and do 1 million put and get operations on either a
small data or a "big" array.
My code: (This is the 3.1 version. Switch module name from queue to Queue to
run on 2.6)
import multiprocessing
import queue
def with_queue(queuetype,datatype):
if queuetype == 'multi':
q = multiprocessing.Queue(1000)
else:
q = queue.Queue(1000)
if datatype == 'small':
data = 'some data'
else:
data = []
for i in range(1000):
data.append(i)
for d in range(100):
q.put(data)
q.get()
if __name__=='__main__':
from timeit import Timer
t1 = Timer("with_queue('simple','small')","from __main__ import with_queue")
t2 = Timer("with_queue('simple','big')","from __main__ import with_queue")
t3 = Timer("with_queue('multi','small')","from __main__ import with_queue")
t4 = Timer("with_queue('multi','big')","from __main__ import with_queue")
print ('Using queue.Queue with small data: ',t1.timeit(1))
print ('Using queue.Queue with huge data : ',t2.timeit(1))
print ('Using multiprocessing.Queue with small data : ',t3.timeit(1))
print ('Using multiprocessing.Queue with huge data : ',t4.timeit(1))
#
And the results (on my linux box:)
python2.6 read_write.py
Using queue.Queue with small data: 10.31s
Using queue.Queue with huge data : 10.39s
Using multiprocessing.Queue with small data : 33.85s
Using multiprocessing.Queue with huge data : 155.38s
python3.1 read_write.py
Using queue.Queue with small data: 10.68s
Using queue.Queue with huge data : 10.61s
Using multiprocessing.Queue with small data : 50.27s
Using multiprocessing.Queue with huge data : 472.49s
As you can see 3.1 is 50% slower than 2.6 in the third test; but 300 % slower
in the 4th test.
If i go further with bigger data, 3.1 run for hours ... and i have to kill it
before any result shows.
Am i doing something wrong or is there any known issue in 3.1 that can explain
this ?
Thanks !
Bob
--
components: Extension Modules
messages: 107775
nosy: bob
priority: normal
severity: normal
status: open
title: Performance issue with multiprocessing queue (3.1 VS 2.6)
type: performance
versions: Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue8995>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Bob added the comment:
I was looking into
http://lists.cs.uiuc.edu/pipermail/llvmbugs/2012-September/025152.html 'Use of
libclang python bindings on Windows 7 64 bit fails with memory access violation'
It appears to be 90% fixed with this patch, but I believe there is still a
problem when structs are passed back though a callback function.
Could this be the correct addition to fix it?
in ffi_prep_incoming_args_SYSV() _ctypes\libffi_msvc\ffi.c(line 377)
/* because we're little endian, this is what it turns into. */
+#if _WIN64
+ if ((*p_arg)->type == FFI_TYPE_STRUCT && z > 8)
+ {
+ z = 8;
+ *p_argv = *(void**)argp;
+ }
+ else
+ {
+ *p_argv = (void*)argp;
+ }
+#else
*p_argv = (void*)argp;
+#endif
--
nosy: +Bob
___
Python tracker
<http://bugs.python.org/issue20160>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Bob added the comment: ok, forgive me for asking a newbe question ot two, but when you say 'fixed in nov 2014' are you refering to the release mentioned below or something else, possibly something that didn't make it into 2.7.9? I dont really understand what 'resync libffi with the upstream version' means, but I assume that if this is done my python-clang issue might be fixed? So having a test is important, I'll see what I can do. I'm working with the 2.7.9 release source, because I need a fix that can be dropped into the 2.7.9 official release folder so that people here can use python-clang. The source I have for 2.7.9 does appear to have the release below in it, including the changes to test_win32.py (which still passes with my fix) -- ___ Python tracker <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Bob added the comment: What I see is that structs lager that 8 bytes are not passed correctly to a callback funtion. I've attached a patchfile that includes my fix and a test to demonstrate the problem. -- Added file: http://bugs.python.org/file38687/large_struct_callback.patch ___ Python tracker <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46281] Python 3.10.1 build errors on Ubuntu 18.04
New submission from Bob Rivoir : _hashlib and _ssl modules failed to compile on my Ubuntu 18.04 system. Attached is a file with the error outputs. -- files: python-3.10.1-build-errors.txt messages: 409853 nosy: rhr242 priority: normal severity: normal status: open title: Python 3.10.1 build errors on Ubuntu 18.04 type: compile error versions: Python 3.10 Added file: https://bugs.python.org/file50545/python-3.10.1-build-errors.txt ___ Python tracker <https://bugs.python.org/issue46281> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46281] Python 3.10.1 build errors on Ubuntu 18.04
Bob Rivoir added the comment: According to synaptic, I have openssl 1.1.1-1ubuntu2.1~18.04-14 installed. On the openssl.org site they mention that this version doesn't eol till 2023. Shouldn't this still work? Or does python require the 3.0 version? -- ___ Python tracker <https://bugs.python.org/issue46281> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172] Documentation for done attribute of FieldStorage class
New submission from Bob Kline: I have attached a patch which adds partial documentation for the done attribute of the cgi.FieldStorage class. This addition is needed in order to make it safe to rely on the current behavior of the class, which sets this attribute to the value -1 when an uploaded file from a CGI form does not arrive intact. If I have sufficient free time to do so at some point in the future, I would like to submit a more extensive modification for the module's documentation, using a format which matches that used for most of the other modules (that is, including documentation of all of the methods and attributes intended for public use), and I'd be inclined to modify the cgi.py module itself, to use a less opaque approach for conveying the failure than the 'done' attribute. I'd want some indication that there was a reasonable chance that if I were to invest the work on this improvement the results would actually be used (I see my latest patch for the module has been languishing in the 'ignored' pile for over a year). If anyone else is doing some overhaul work in this area, please speak up so we don't end up with duplication of effort. I would think that this module would be one of the most commonly used in the entire Python library, and would thus warrant careful maintenance (including addressing all of the "XXX let's fix this ..." comments. Cheers! -- components: Documentation files: cgi.rst.diff messages: 55975 nosy: bkline severity: normal status: open title: Documentation for done attribute of FieldStorage class type: rfe __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1172> __--- cgi.rst 2007-09-17 13:40:51.0 -0400 +++ cgi.rst-20070917 2007-09-17 14:57:00.0 -0400 @@ -147,6 +147,11 @@ if not line: break linecount = linecount + 1 +If an error is encountered when obtaining the contents of an uploaded file +(for example, when the user interrupts the form submission by clicking on +a Back or Cancel button) the :attr:`done` attribute of the object for the +field will be set to the value -1. + The file upload draft standard entertains the possibility of uploading multiple files from one field (using a recursive :mimetype:`multipart/\*` encoding). When this occurs, the item will be a dictionary-like :class:`FieldStorage` item. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172] Documentation for done attribute of FieldStorage class
Bob Kline added the comment: Thanks for the very quick follow-up. I may be shooting myself in the foot here, but Sean's encouragement about getting patches to the actual code lead me to wonder if it might be better to go straight for the optimal solution here. As I implied in my original message for this issue, there are approaches for exposing the ability to detect failure which would be more straightforward than testing for field.done == -1. A step in the right direction might be an attribute named something like 'incomplete' (True|False). Or perhaps an access method? Based on my more recent experience with getting code patches accepted, I had settled on just documenting the existing code more fully as a minimal solution, but if Sean's more optimistic advice is justified, I'd be happy to wait a little longer for a cleaner solution (and to pitch in for the work to create it, if that's appropriate). I know I have more than one bit of Python code I wrote years ago for situations similar to this where if I had to do it over again I would have thrown an exception, and maybe that's the right thing to do here, with an optional argument to the constructor which suppresses the exception. Perhaps Guido might want to weigh in with his own preferences (this is his code, and he's still listed as the current maintainer of the module). But I'd rather have the documentation patch for the existing code than nothing at all. Cheers, Bob __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1172> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172] Documentation for done attribute of FieldStorage class
Bob Kline added the comment: Sean Reifschneider wrote: > Assign your issue that has been ignored to me and I'll take a > look at it. I tried, but it doesn't look like I have sufficient permission to change the assignment. It's http://bugs.python.org/issue1541463 Thanks! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1172> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1541463] Optimizations for cgi.FieldStorage methods
Bob Kline added the comment: Please note that the documentation of the keys() method of the FieldStorage class (both in the method's docstring as well as in the separate library manual) describes the method as a "dictionary style keys() method." Section 3.8 of the documentation has this to say about the keys() method of a dictionary: "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions." I believe the proposed implementation conforms with this specified behavior. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1541463> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1541463] Optimizations for cgi.FieldStorage methods
Bob Kline added the comment: I'm not sure I would characterize a speedup of several orders of magnitude a "tiny performance gain." We had scripts with very large numbers of fields which were actually timing out. While I understand and agree with the principle of breaking as little existing code as possible, when programmers have actually been told that the method behaves the way the dictionary keys() method behaves it seems unreasonable to assume that the method will preserve the original order of fields (whatever that might mean for multiply-occurring field names). _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1541463> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10019] json.dumps with indent = 0 not adding newlines
Bob Ippolito added the comment: The test in the patch assumes a specific iteration order for the dict "h", changing the dict to have only one key would fix this problem with the test. -- ___ Python tracker <http://bugs.python.org/issue10019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10019] json.dumps with indent = 0 not adding newlines
Bob Ippolito added the comment: The test also repeats an equivalent dict to "h" in the check function. -- ___ Python tracker <http://bugs.python.org/issue10019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10019] json.dumps with indent = 0 not adding newlines
Bob Ippolito added the comment: I just applied a version of this patch with corrections to the tests here: http://code.google.com/p/simplejson/source/detail?r=234 -- ___ Python tracker <http://bugs.python.org/issue10019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5729] Allows tabs for indenting JSON output
Bob Ippolito added the comment: Sorry but I don't think I will be able to. I'd be happy to accept patches into simplejson that make it easier to merge with Python 3 in the future, but I simply do not have the time to maintain the Python 3 branch of the code that we don't use. -- ___ Python tracker <http://bugs.python.org/issue5729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10158] BadInternalCall running test_multiprocessing
New submission from Bob Halley : For reasons not germane to this bug report, I was running a modified Python 2.7 where PyTrash_UNWIND_LEVEL in Include/object.h had been defined to 10 instead of 50. With such a python, running test_multiprocessing causes a BadInternalCall to be triggered at line 903 of weakrefobject.c. test_finalize (__main__.WithProcessesTestFinalize) ... Process Process-18: Traceback (most recent call last): File "/Users/halley/src/release27-maint/Lib/multiprocessing/process.py", line 229, in _bootstrap util._run_after_forkers() File "/Users/halley/src/release27-maint/Lib/multiprocessing/util.py", line 125, in _run_after_forkers items = list(_afterfork_registry.items()) File "/Users/halley/src/release27-maint/Lib/weakref.py", line 116, in items for key, wr in self.data.items(): SystemError: Objects/weakrefobject.c:903: bad argument to internal function I'm running the head of the release27-maint branch, but the problem occurs with the released 2.7 too. The trigger for the error is that object->ob_refcount is 1. I stuck an abort() into the code just before the BadInternalCall, and looked at the core. The ob_type is a Semaphore, and the last bit of the call chain is: (gdb) bt #0 0x7fff8791c3d6 in __kill () #1 0x7fff879bc972 in abort () #2 0x00010007eb05 in PyObject_ClearWeakRefs (object=) at Objects/weakrefobject.c:903 #3 0x00010006c949 in subtype_dealloc (self=0x10070a150) at Objects/typeobject.c:952 #4 0x00010005341b in _PyTrash_destroy_chain () at Objects/object.c:2435 #5 0x00010003bfaf in listiter_next (it=0x1006db8d0) at Objects/listobject.c:2917 #6 0x0001000b9f16 in PyEval_EvalFrameEx (f=0x1013b91a0, throwflag=) at Python/ceval.c:2496 #7 0x0001000c0966 in PyEval_EvalFrameEx (f=0x1013bcc40, throwflag=) at Python/ceval.c:4098 #8 0x0001000c0966 in PyEval_EvalFrameEx (f=0x10137a500, throwflag=) at Python/ceval.c:4098 #9 0x0001000c0966 in PyEval_EvalFrameEx (f=0x101374aa0, throwflag=) at Python/ceval.c:4098 #10 0x0001000c1826 in PyEval_EvalCodeEx (co=0x10065d1b0, globals=, locals=, args=0x100708458, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252 #11 0x000100037580 in function_call (func=0x100678488, arg=0x100708440, kw=0x0) at Objects/funcobject.c:526 #12 0x000163e2 in PyObject_Call (func=0x100678488, arg=0x100708440, kw=0x0) at Objects/abstract.c:2529 #13 0x0001000177bd in instancemethod_call (func=0x100678488, arg=0x100708440, kw=0x0) at Objects/classobject.c:2578 #14 0x000163e2 in PyObject_Call (func=0x100704780, arg=0x1006f17d0, kw=0x0) at Objects/abstract.c:2529 #15 0x000100071a38 in slot_tp_init (self=, args=0x1006f17d0, kwds=0x0) at Objects/typeobject.c:5651 #16 0x00010006ee75 in type_call (type=0x10130bd10, args=0x1006f17d0, kwds=0x0) at Objects/typeobject.c:726 #17 0x000163e2 in PyObject_Call (func=0x10130bd10, arg=0x1006f17d0, kw=0x0) at Objects/abstract.c:2529 Note that the trashcan function _PyTrash_destroy_chain() is involved. I don't understand this code well enough to have figured out what's going wrong yet. I worry that there's some subtle interaction with weakrefs, subtyped objects, and the trashcan, but maybe it's something simpler! Regards, /Bob -- components: Interpreter Core messages: 119233 nosy: rthalley priority: normal severity: normal status: open title: BadInternalCall running test_multiprocessing type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue10158> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10158] BadInternalCall running test_multiprocessing
Bob Halley added the comment:
I rebuilt using --with-pydebug and -O0 -g. It now triggers an assertion a bit
earlier.
test_finalize (__main__.WithProcessesTestFinalize) ... Assertion failed:
(op->ob_refcnt == 0), function _PyTrash_destroy_chain, file Objects/object.c,
line 2433
(gdb) bt
#0 0x7fff8791c3d6 in __kill ()
#1 0x7fff879bc972 in abort ()
#2 0x7fff879a99b4 in __assert_rtn ()
#3 0x0001000796e0 in _PyTrash_destroy_chain () at Objects/object.c:2433
#4 0x000100053efe in list_dealloc (op=0x10114cc18) at
Objects/listobject.c:317
#5 0x00010007905b in _Py_Dealloc (op=0x10114cc18) at Objects/object.c:2228
#6 0x00010005aee7 in listiter_next (it=0x10160d610) at
Objects/listobject.c:2917
#7 0x0001001158c8 in PyEval_EvalFrameEx (f=0x1014c72c0, throwflag=0) at
Python/ceval.c:2496
[ ... snip ... ]
(gdb) f 3
#3 0x0001000796e0 in _PyTrash_destroy_chain () at Objects/object.c:2433
2433assert(op->ob_refcnt == 0);
(gdb) list
2428 * fool Py_DECREF into calling it indirectly, but
2429 * Py_DECREF was already called on this object, and in
2430 * assorted non-release builds calling Py_DECREF again ends
2431 * up distorting allocation statistics.
2432 */
2433assert(op->ob_refcnt == 0);
2434++_PyTrash_delete_nesting;
2435(*dealloc)(op);
2436--_PyTrash_delete_nesting;
2437}
(gdb) p *op
$2 = {
_ob_next = 0x0,
_ob_prev = 0x0,
ob_refcnt = 1,
ob_type = 0x101441d70
}
(gdb) p *op->ob_type
$4 = {
_ob_next = 0x10076d798,
_ob_prev = 0x101442930,
ob_refcnt = 9,
ob_type = 0x1001f84e0,
ob_size = 0,
tp_name = 0x1013e88b4 "Semaphore",
tp_basicsize = 48,
tp_itemsize = 0,
tp_dealloc = 0x10009dd9d ,
tp_print = 0,
tp_getattr = 0,
tp_setattr = 0,
tp_compare = 0,
tp_repr = 0x1000af4a0 ,
tp_as_number = 0x101441f08,
tp_as_sequence = 0x101442058,
tp_as_mapping = 0x101442040,
tp_hash = 0x1000761bc <_Py_HashPointer>,
tp_call = 0,
tp_str = 0x1000a44e4 ,
tp_getattro = 0x10007728a ,
tp_setattro = 0x100077676 ,
tp_as_buffer = 0x1014420a8,
tp_flags = 940027,
tp_doc = 0x0,
tp_traverse = 0x10009da40 ,
tp_clear = 0x10009dce5 ,
tp_richcompare = 0,
tp_weaklistoffset = 40,
tp_iter = 0,
tp_iternext = 0x100076c13 <_PyObject_NextNotImplemented>,
tp_methods = 0x0,
tp_members = 0x1014420e8,
tp_getset = 0x0,
tp_base = 0x1014499f0,
tp_dict = 0x101442930,
tp_descr_get = 0,
tp_descr_set = 0,
tp_dictoffset = 32,
tp_init = 0x1000b06dd ,
tp_alloc = 0x10009d7a7 ,
tp_new = 0x1000a3f03 ,
tp_free = 0x10016bda4 ,
tp_is_gc = 0,
tp_bases = 0x1010bc840,
tp_mro = 0x100744060,
tp_cache = 0x0,
tp_subclasses = 0x10074d240,
tp_weaklist = 0x10075f528,
tp_del = 0,
tp_version_tag = 194
}
--
___
Python tracker
<http://bugs.python.org/issue10158>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11373] Fix 2 new typos in the docs
Bob Wintemberg added the comment: The following is a patch to fix this documentation issue in release27-maint. -- keywords: +patch nosy: +rwinte Added file: http://bugs.python.org/file20993/patch-27.diff ___ Python tracker <http://bugs.python.org/issue11373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11373] Fix 2 new typos in the docs
Bob Wintemberg added the comment: The following is a patch to fix this documentation issue in py3k. -- Added file: http://bugs.python.org/file20994/patch-3k.diff ___ Python tracker <http://bugs.python.org/issue11373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5340] Change in cgi behavior breaks existing software
Bob Kline added the comment: Just to make life interesting, someone went in and changed all the URLs for messages in the Python mailing list. Here's the new URL for the message which contains the repro instructions: http://mail.python.org/pipermail/python-list/2009-February/1192951.html The URL which represents the reported behavior in that message now points to a machine which has been upgraded to Python 2.7, not 2.6 as reported in the repro instructions, but the behavior is still the same. Of course, these instructions won't be useful forever, because the Debian server which is running Python 2.5 (to show the previous behavior) will (I assume) eventually move on to a later version of Python itself. But for now the repro instructions are still valid. -- ___ Python tracker <http://bugs.python.org/issue5340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11844] Update json to upstream simplejson latest release
Bob Ippolito added the comment: That's not a problem, I'm more than happy to give permission for any patch. If it's easier I can consider dual-licensing in the simplejson source. -- ___ Python tracker <http://bugs.python.org/issue11844> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5723] Incomplete json tests
Bob Ippolito added the comment: I did this some time ago in simplejson by defining a TestSuite subclass and instrumenting simplejson so that speedups can be enabled and disabled easily with a private API. https://github.com/simplejson/simplejson/blob/master/simplejson/tests/__init__.py -- ___ Python tracker <http://bugs.python.org/issue5723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9233] json.load failure when C optimizations aren't built
Bob Ippolito added the comment: For what it's worth, I don't think any of the failures mentioned here are in the current version of simplejson. There aren't any tests that check the speedup module name, the speedup tests are skipped when speedups are not detected, and the empty json object bug was fixed in June 2009. http://code.google.com/p/simplejson/issues/detail?id=57 -- ___ Python tracker <http://bugs.python.org/issue9233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Bob Atkins <[EMAIL PROTECTED]> added the comment: Martin, Your method is just flat wrong - equivalent to using a sledgehammer. The libraries fail to link not because gcc install is wrong but because the -m64 flag needs to be passed to the linker. Your method just fixes the compilation stage. You are blaming the gcc installation for your problem when in fact the /_*rest*_/ of the open source world builds just fine using gcc when the proper flags are passed at the proper stages of the build. This situation is so sad to see. This isn't the way open source development is supposed to be. Basically _/*you*/_ alone are the gatekeeper and you are refusing to deal with what is a very simple problem. To be sure I really don't care anymore - we will continue to apply the patches that we have to fix the build problem however, we will also actively discourage the use of Python for our customers and all future development/deployment since it is obvious that as the maintainer you are completely closed minded and uncooperative when it comes to fixing things. My suggestion for the rest of the Python community is to branch and re-host the Python project elsewhere if anyone wants to see it move forward. Added file: http://bugs.python.org/file10524/unnamed Added file: http://bugs.python.org/file10525/DigiLink_esig_logo.jpg ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> ___ Martin, Your method is just flat wrong - equivalent to using a sledgehammer. The libraries fail to link not because gcc install is wrong but because the -m64 flag needs to be passed to the linker. Your method just fixes the compilation stage. You are blaming the gcc installation for your problem when in fact the rest of the open source world builds just fine using gcc when the proper flags are passed at the proper stages of the build. This situation is so sad to see. This isn't the way open source development is supposed to be. Basically you alone are the gatekeeper and you are refusing to deal with what is a very simple problem. To be sure I really don't care anymore - we will continue to apply the patches that we have to fix the build problem however, we will also actively discourage the use of Python for our customers and all future development/deployment since it is obvious that as the maintainer you are completely closed minded and uncooperative when it comes to fixing things. My suggestion for the rest of the Python community is to branch and re-host the Python project elsewhere if anyone wants to see it move forward. -- Untitled Document Bob Atkins  President/CEO http://www.digilink.net";> Business Inter-net-working The Cure for the Common ISP! Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] Martin v. Löwis wrote: Martin v. Löwis mailto:[EMAIL PROTECTED]"><[EMAIL PROTECTED]> added the comment: So, since this patch allows python to be built 64-bit on a biarch system, and without it, the build doesn't work This is simply not true. I can build Python 2.5 just fine for 64-bit SPARC, using gcc, with CC="gcc -m64" ./configure make Or, using SunPRO, with CC="cc -m64" ./configure make I tested it myself, and it successfully builds a Python executable (For gcc, the extension modules fail to load because it picks up the wrong libgcc_s, which I believe is a gcc installation bug. For SunPRO, the extension modules also build fine). So before anything is fixed, I'd like to see an actual, reliable, reproducable error report. The subject of this report (Python 2.5 64 bit compile fails on Solaris 10 with gcc) is not reproducable, so I'm tempted to close this report as "works for me". ___ Python tracker mailto:[EMAIL PROTECTED]"><[EMAIL PROTECTED]> http://bugs.python.org/issue1628484";><http://bugs.python.org/issue1628484>; ___  <>___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Bob Atkins <[EMAIL PROTECTED]> added the comment: I rest my case - you found /_*one*_/ of the problems which you are blaming on gcc but in fact is not gcc's fault. You /_*must*_/ specify the correct -L and -R paths to the various alternate 64 bit libs. Don't expect the compiler to figure it out. Of course you can also fix the problem by changing the defaults to the system link/loader and I'm sure other non-standard methods. The bottom line is that I just don't know how to describe daylight to a blind man FYI, we are using gcc 4.1.1 - same problem and we aren't using or relying on just the /usr/sfw tree sine much of what comes with Solaris isn't 64 bit we have had to build our own libs which are kept in /opt/lib --- Bob Martin v. Löwis wrote: > Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > > Just to demonstrate there is really a problem with the gcc installation > (gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)), here is the > linker line: > > gcc -m64 -shared > build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o > -L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.5/_struct.so > > and here is what gcc actually invokes (printed with -v): > > /usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/collect2 -V -G -dy -z > text -Y P,/usr/lib/sparcv9 -Qy -o > build/lib.solaris-2.10-sun4u-2.5/_struct.so > /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crti.o > /usr/ccs/lib/sparcv9/values-Xa.o > /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtbegin.o > -L/usr/local/lib -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9 > -L/usr/ccs/lib/sparcv9 > -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../sparcv9 > -L/lib/sparcv9 -L/usr/lib/sparcv9 > build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o > -R/usr/sfw/lib -lgcc_s_sparcv9 -R/usr/sfw/lib -lgcc_s_sparcv9 > /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtend.o > /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtn.o > > As you can see, it's picking up -lgcc_s_sparcv9 (from > /usr/sfw/lib/sparcv9/libgcc_s_sparcv9.so), so it does link with the > 64-bit libgcc_s.so.1. However, when then trying to import the module, it > complains > > ImportError: ld.so.1: python: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong > ELF class: ELFCLASS32 > > This is due to the option -R/usr/sfw/lib, which should have been > -R/usr/sfw/lib/sparcv9. Fixing the specs file to change the -R option > actually fixes that problem. > > So please don't claim that I did something wrong when there is really a > bug in sfw version of gcc. > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1628484> > ___ > > > Added file: http://bugs.python.org/file10526/unnamed Added file: http://bugs.python.org/file10527/DigiLink_esig_logo.jpg ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> ___ I rest my case - you found one of the problems which you are blaming on gcc but in fact is not gcc's fault. You must specify the correct -L and -R paths to the various alternate 64 bit libs. Don't expect the compiler to figure it out. Of course you can also fix the problem by changing the defaults to the system link/loader and I'm sure other non-standard methods. The bottom line is that I just don't know how to describe daylight to a blind man FYI, we are using gcc 4.1.1 - same problem and we aren't using or relying on just the /usr/sfw tree sine much of what comes with Solaris isn't 64 bit we have had to build our own libs which are kept in /opt/lib --- Bob Martin v. Löwis wrote: Martin v. Löwis mailto:[EMAIL PROTECTED]"><[EMAIL PROTECTED]> added the comment: Just to demonstrate there is really a problem with the gcc installation (gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)), here is the linker line: gcc -m64 -shared build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o -L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.5/_struct.so and here is what gcc actually invokes (printed with -v): /usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/collect2 -V -G -dy -z text -Y P,/usr/lib/sparcv9 -Qy -o build/lib.solaris-2.10-sun4u-2.5/_struct.so /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crti.o /usr/ccs/lib/sparcv9/values-Xa.o /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtbegin.o -L/usr/local/lib -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9 -L/usr/ccs/lib/sparcv9 -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../sparcv9 -L/lib/sparcv9 -L/usr/lib/sparcv9 build/temp.solaris-2.10-
[issue3126] Lib/logging/__init__.py assumes its stream has flush and close methods
New submission from Bob Farrell <[EMAIL PROTECTED]>: The documentation for the sys module says: "stdout and stderr needn't be built-in file objects: any object is acceptable as long as it has a write() method that takes a string argument." However, the logging module calls flush() and close() on StreamHandler.stream (and stream may be stdout), yet stdout does not apparently need to have these methods - this caused breakage for a program of mine that redirects stdout and can import arbitrary modules (it's an interactive interpreter). The attached patch checks that these two methods exist (using hastattr) before calling them. -- components: Library (Lib) files: __init__.py.patch keywords: patch messages: 68296 nosy: bobf severity: normal status: open title: Lib/logging/__init__.py assumes its stream has flush and close methods type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file10640/__init__.py.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3126> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3322] bugs in scanstring_str() and scanstring_unicode() of _json module
Bob Ippolito <[EMAIL PROTECTED]> added the comment: Am I to understand that the bug here is that the C extension doesn't validate input properly if you call into it directly? Without a test I'm not entirely sure exactly how you could possibly get negative values into those functions using the json module as-is. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3322] bugs in scanstring_str() and scanstring_unicode() of _json module
Bob Ippolito <[EMAIL PROTECTED]> added the comment: I've audited the patch, while it does fix the input range it looks like it regresses other things (at least the error messages). "begin" was intentionally used. The patch is not suitable for use, I'll create a minimal patch that just fixes input validation. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3322] bugs in scanstring_str() and scanstring_unicode() of _json module
Bob Ippolito <[EMAIL PROTECTED]> added the comment: I just committed a fix to trunk in r65147, needs port to py3k? -- assignee: bob.ippolito -> georg.brandl ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()
Bob Ippolito <[EMAIL PROTECTED]> added the comment: That patch looks ok to me, but I'm not at all familiar with the changes in python 3.0 yet. Is this something that needs to be backported to 2.6? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3623> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()
Bob Ippolito <[EMAIL PROTECTED]> added the comment: I applied the changes proposed in _json26.patch to simplejson and they worked perfectly fine. Again I'm not the best judge of python 3.0 code because I have not made myself familiar with the API changes so someone else should review it (but it's probably fine). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3623> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8006] os.popen in Python 3.1
Bob Buckley added the comment: I could not get it to open a write pipe. I am trying to drive GNUplot from Python. It worked OK in Python 2.x but does not work well in 3.x. I have it partially working now ... I am calling subprocess.Popen but I cannot get a text mode pipe which is disappointing. I have not yet got my head around Python 3's byte vs string stuff. regards Bob Buckley On 21/03/2010 8:02 AM, R. David Murray wrote: > R. David Murray added the comment: > > Well, actually os.popen in Python3 is implemented by calling subprocess.Popen. > > So, Bob, how does it fail? > > -- > nosy: +r.david.murray > priority: -> normal > stage: -> test needed > > ___ > Python tracker > <http://bugs.python.org/issue8006> > ___ > -- ___ Python tracker <http://bugs.python.org/issue8006> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1614] bug in string method "title"
New submission from Bob Helmbold: Summary: "title" method of string objects does not handle contractions and possessives correctly. See the following short program and its results for examples. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< """ Test of string method 'capitalize' """ stringList=["we're", "you're", "they're", "i've", "we've", "you've", "they've", "can't", "won't", "doesn't", "haven't", "daren't", "shouldn't", "weren't", "wasn't", "i'm" ] for item in stringList: n=len(item) spaces=' '*(12-n) itemTitled = item.title() isATitle = itemTitled.istitle() print "%s -> %s%s is title=%s" %(item, spaces, itemTitled, isATitle) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Results in: we're ->We'Re is title=True you're -> You'Re is title=True they're -> They'Re is title=True i've -> I'Ve is title=True we've ->We'Ve is title=True you've -> You'Ve is title=True they've -> They'Ve is title=True can't ->Can'T is title=True won't ->Won'T is title=True doesn't -> Doesn'T is title=True haven't -> Haven'T is title=True daren't -> Daren'T is title=True shouldn't ->Shouldn'T is title=True weren't -> Weren'T is title=True wasn't -> Wasn'T is title=True i'm -> I'M is title=True -- components: Interpreter Core messages: 58544 nosy: ElGordo severity: normal status: open title: bug in string method "title" type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1614> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2103] __x should be _x in documentation of property()
New submission from bob gailer: Library Reference 2.1 under property(): class C(object): def __init__(self): self.__x = None __x should be _x -- components: Documentation messages: 62368 nosy: bgailer severity: normal status: open title: __x should be _x in documentation of property() versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2103> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2103] __x should be _x in documentation of property()
bob gailer added the comment: I tried to search for a prior report with no success. How should I have done tha __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2103> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Bob Atkins <[EMAIL PROTECTED]> added the comment: Martin, I've been quietly reading all of the back and forth regarding this problem. Your suggestion for using the CC variable to fix the problem that I reported won't work - I already tried it and based on what others are reporting, you are beating a dead horse. Believe me I would rather not modify anyone's code in order to build something. The problem is that the CC variable doesn't fix the link stages and overall your autconf build is broken particularly as it relates to flowing variables down to sub builds. I don't know why you are resisting this change. I took the time to report the bug, proposed a fix /_*and*_/ contributed the patch that would make the Python build process more standard relative to the vast majority of open source packages that use autoconf. I am glad to see that my patch appears to be generic enough that it works on other platforms as well. I didn't have to post a bug report let alone contribute a patch but, I believe strongly that is what open source is all about. As the maintainer you don't have to accept either the bug or the patch but, resisting without good cause will discourage further contributions - certainly from me because I won't waste my time submitting something when I know that a maintainer of a package is being closed minded. We do a lot of work with open source software here and it is our policy to contribute back to the community as much as possible. However, when we run into a brick wall we quickly give up because we can't justify the time and effort. As an example, we have completely suspended all contributions to the asterisk project. We operate a very large asterisk environment with a lot of fixes and improvements that I am sure lots of others would love to have but the maintainer's attitude was that a Sun Solaris platform was not important. What the maintainer doesn't know is that many of our fixes and changes affect /_*all*_/ platforms. So now they get nothing from us and the asterisk community as a whole is deprived of the benefits of our work. I also know that many others have also suspended contributions for the same reason and as a result the asterisk package suffers. The resistance on your part to recognizing this problem and a fix is unjustified. Overall it improves the Python package if it can be built on more platforms in different ways - especially if it uses the standard autoconf approach that the majority of other open source packages use. Those of us that have to deal with building almost a hundred different packages for different platforms and architectures very much appreciate not having to deal with unnecessary exceptions or idiosyncrasies. I don't care whether you incorporate the change or not - we certainly will continue to patch future versions of Python (we have a fully automated build process here) in order to produce a successful build. Clearly the genie is out of the bottle and others will also likely use the patch for their builds. Why not just make everyone happy and incorporate it or a reasonably similar approach that properly implements the flow of /_*all*_/ autoconf variables to the sub-builds of the Python package so that more people can take full advantage of Python on their 64 bit platforms and also deal with whatever unique build requirements that they might have. Sincerely, Bob Atkins Martin v. Löwis wrote: >Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > > > >>This is what you get when you try to build a 64-bit Python on a biarch >>machine (64-bit kernel, 32-bit userspace), using a gcc that generates >>natively 32-bit objects (therefore, you *must* pass the '-m64' option >>for the compiler): >> >> > >Or you install an additional, different, C compiler that defaults to >AMD64. > > > >>1) As you could see above, actually you need CFLAGS in order to compile >>Python correctly. As far as I could investigate, the reason you need >>this is because of the tests that are done by configure. Without the >>CFLAGS, configure will think it's building a 32-bit Python, despite of >>the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS >>through Makefile or not? IMHO, we do. >> >> > >Not necessarily. I think you can achieve the same effect by specifying >CC="gcc -m64" to configure. > > > >>2) Even with CFLAGS and BASECFLAGS set, the compilation fails. Using >>LDFLAGS makes the compilation process continue a little more, but it >>still doesn't solve the problem. AFAIK, the reason it doesn't solve the >>problem is, again, because we are not propagating it through the >>Makefile. Can you see any different reason? Al
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Bob Atkins <[EMAIL PROTECTED]> added the comment: Martin, Martin v. Löwis wrote: It does not when link stage specific options are required that are not valid for compilation stages. My mistake. I was thinking of another package - you can scratch that comment. There is no hard and fast rule that specifying the CFLAGS or other configure variables have to override /_*all*_/ of the compile flags that a developer chooses to use in their build process. Most open source packages use the configure CFLAGS, LDFLAGS, etc, variables to add to the compile and link flags and not completely override them. My patch follows the same philosophy that I have seen in the majority of other open source packages. On the contrary - it does /_*not*_/ make it more complex and it /_*does*_/ provide a solution to a number of compile and link failures that have been reported over and over again. When I first posted this bug I read through the various forums and bug reports and I noticed quite a bit of complaining regarding this issue and I acknowledged that by noting in my report that what I was opening a bug report on what was clearly a sore subject within the Python community. To be specific the complaints were regarding the symptoms (unusual compile and link problems) related to this issue, not the specific cause of the problem which is why I filed the bug as I did. The patch that I submitted will allow a build of Python to be performed the /_exact_/ same way it is today without any modifications to CFLAGS or LDFLAGS, etc. Those of us that /need/ to use these variables will be able to modify the build options to the configure script as necessary /_*without*_/ any complexity and without losing 'important' compile options that are currently generated by configure. All of your suggestions to use the CC variable in lieu of using the more appropriate CFLAGS, LDFLAGS, etc., introduce the very complexity and non-standard approach you are claiming you want top avoid. Again, I don't see what your concerns are. My patch is a completely non-affecting change to the way Python is built today /_*but*_/ it does add the necessary fixes so that those that require specific compile and link options can specify them to the configure script. In addition, while you are fixing the build/compile options, I noticed that you are missing the -fPIC compile option. Without it you can't link shared libraries and the build fails. You should probably be including -fPIC as a standard compile option so it is not required to be passed into the build via the configure script. --- Bob Added file: http://bugs.python.org/file10033/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> _ Martin, Martin v. Löwis wrote: Martin v. Löwis mailto:[EMAIL PROTECTED]"><[EMAIL PROTECTED]> added the comment: Your suggestion for using the CC variable to fix the problem that I reported won't work - I already tried it and based on what others are reporting, you are beating a dead horse. Believe me I would rather not modify anyone's code in order to build something. The problem is that the CC variable doesn't fix the link stages Why is that? It should work fine. It does not when link stage specific options are required that are not valid for compilation stages. and overall your autconf build is broken particularly as it relates to flowing variables down to sub builds. This I don't understand. What is a sub build? My mistake. I was thinking of another package - you can scratch that comment. I don't know why you are resisting this change. I took the time to report the bug, proposed a fix /_*and*_/ contributed the patch that would make the Python build process more standard relative to the vast majority of open source packages that use autoconf. I don't think that's the case. In autoconf, if you specify CFLAGS, you expect that this overrides, not adds to, anything configure computes on its own. This patch does not do that, i.e. it doesn't allow you to override the settings that configure computes. There is no hard and fast rule that specifying the CFLAGS or other configure variables have to override all of the compile flags that a developer chooses to use in their build process. Most open source packages use the configure CFLAGS, LDFLAGS, etc, variables to add to the compile and link flags and not completely override them. My patch follows the same philosophy that I have seen in the majority of other open source packages. I'm concerned that the patch merely makes the entire setup more complex, rather than solving an actual technical problem. That's why I'm resisting to accept it. On the contrary - it does not make it more compl
[issue1376292] Write user's version of RefGuide
bob gailer <[EMAIL PROTECTED]> added the comment: I find a Reference Manual and a Library Reference. I presume you are referring to the Reference Manual. True? I might be interested in helping create the shorter friendlier guide. I suggest we create some guidelines or specifications for it. This might be a task for several of us, each taking a section, or some other form of collaboration. -- nosy: +bgailer _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. -- title: Write user's version of RefGuide -> Write user's version of Added file: http://bugs.python.org/file10090/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10091/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10092/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10093/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10094/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10095/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10096/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10097/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10098/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10099/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10100/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer <[EMAIL PROTECTED]> added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10101/unnamed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1376292> _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.Bob Gailer in Chapel Hill NC.___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] pickling of large recursive structures fails
Bob Kline <[EMAIL PROTECTED]> added the comment: I just ran into this behavior with an attempt to pickle a dom tree for an XML document whose nesting level never got deeper than nine child nodes, and indeed it crashed the interpreter. Throwing an exception would be preferable, of course, to silent blowing up Python, but even the exception seems to fly in the face of the documentation for the pickle module [1] which claims (summarizing) that serializing recursive objects using marshal will fail but pickling recursive objects will not fail. I can provide a repro for the XML/DOM pickling case if you think that would be helpful, but that seems redundant since essentially you've already illustrated the problem with your own repro case. Thanks for your work on the solution. [1] http://docs.python.org/lib/node314.html -- nosy: +bkline type: -> crash __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2480> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] eliminate recursion in pickling
Bob Kline <[EMAIL PROTECTED]> added the comment: > Please open a new issue and don't forget to provide an example case. Looks like Daniel beat me to the punch. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2480> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
New submission from Bob Ippolito <[EMAIL PROTECTED]>: Attached is the tarball for simplejson 1.9, the proposed version to be included in the stdlib. Estimated work remaining: * Rename simplejson to json * Build simplejson/_speedups.c from Modules/Setup and Windows projects * Convert documentation to Python docs * Port to Python 3.0 -- components: Library (Lib) files: simplejson-1.9.tar.gz messages: 66176 nosy: bob.ippolito severity: normal status: open title: Add simplejson to Python 2.6/3.0 standard library type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10185/simplejson-1.9.tar.gz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2750> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Bob Ippolito <[EMAIL PROTECTED]> added the comment: The json package is in brett's branch, integrates with the test suite, builds the C extension and passes all tests (at least on OS X and Linux UCS2 and UCS4). Missing the docs and python 3.0 support still, otherwise things look good. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2750> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Bob Ippolito <[EMAIL PROTECTED]> added the comment: It doesn't work on alternate implementations right now anyway, because it (ab)uses some sre APIs that aren't widely implemented outside of cpython. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2750> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Bob Ippolito <[EMAIL PROTECTED]> added the comment: it's isolated to json.scanner, if that was re-implemented in more general terms then it wouldn't be dependent on sre anymore. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2750> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Bob Ippolito <[EMAIL PROTECTED]> added the comment: Well, that's unfortunate. I found it very useful __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2750> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Bob Ippolito <[EMAIL PROTECTED]> added the comment: They look good, but is there an easy way to look at them post-formatting or do I have to install the sphinx toolchain myself? I moved the command-line stuff to json.tool to get around the package problem. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2750> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Bob Ippolito <[EMAIL PROTECTED]> added the comment: I don't think that makes sense, "tool" makes it pretty clear that it's something you use from the command-line rather than a module to import and call functions from where pp does not. I'd also rather call it pprint than pp if that were the decision.. EIBTI. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2750> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Bob Ippolito <[EMAIL PROTECTED]> added the comment: loads will take unicode or str. if it's str then it assumes utf-8, otherwise the explicitly specified encoding. All of the string instances generated by loads will be unicode objects (some of them may be str objects if they're all ASCII as an optimization, I'm not sure if I implemented that or not). dumps produces an ASCII str, but if you explicitly specify ensure_ascii=False then it will return a unicode object. obviously load and dump will be working on a file-like object so should be dealing with bytes... I'm not entirely sure whether semantically dumps should produce bytes or str in py3k, I guess whatever the other text-based encodings do is appropriate (e.g. base64, mime). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2750> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.3
New submission from Bob Ippolito <[EMAIL PROTECTED]>: simplejson 2.0.3 includes major performance enhancements (both in Python and C) and removes usage of the private sre functionality. I will need some help with 3.0 since I am not well versed in the changes to the C API or Python code for that, but merging for 2.6.1 should be no big deal. How should I go about this? -- assignee: bob.ippolito components: Library (Lib) messages: 74872 nosy: bob.ippolito severity: normal status: open title: merge json library with simplejson 2.0.3 versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.3
Bob Ippolito <[EMAIL PROTECTED]> added the comment: Sure, but that doesn't port it to Python 3.0 :) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.3
Bob Ippolito <[EMAIL PROTECTED]> added the comment: patch to r66961 of trunk is attached. -- keywords: +26backport, patch versions: +Python 2.7, Python 3.1 Added file: http://bugs.python.org/file11822/json_issue4136_r66961.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.3
Bob Ippolito <[EMAIL PROTECTED]> added the comment: You're probably right, I don't remember what code I was using as a template for that. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.3
Bob Ippolito <[EMAIL PROTECTED]> added the comment: Actually, if I remove those lines from the equivalent module in simplejson it no longer works properly with Python 2.5.2. File "/Users/bob/src/simplejson/simplejson/decoder.py", line 307, in __init__ self.scan_once = make_scanner(self) TypeError: cannot create 'make_scanner' instances ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.3
Bob Ippolito <[EMAIL PROTECTED]> added the comment: I don't recall exactly why they aren't in the struct itself, it may not have worked with some compiler on some platform. It's not really a complete rewrite, the encoding path is largely the same and the tests haven't changed. Anyway, there is no further work planned for simplejson. It's done except for the potential for bug fixes. The only enhancements were performance related and this is about as fast as it's going to get. The majority of this work was ready before Python 2.6 was released but it was frozen so I couldn't get this in. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.3
Bob Ippolito <[EMAIL PROTECTED]> added the comment: http://codereview.appspot.com/7311 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.3
Bob Ippolito <[EMAIL PROTECTED]> added the comment: Attached is a new diff, one byte fix to the float parser when parsing JSON documents that are just a float (also a test and a version bump). Added file: http://bugs.python.org/file11870/json_issue4136_r67009.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.4
Changes by Bob Ippolito <[EMAIL PROTECTED]>: -- title: merge json library with simplejson 2.0.3 -> merge json library with simplejson 2.0.4 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4783] json documentation needs a BAWM (Big A** Warning Message)
Bob Ippolito added the comment: You're the first person to ever raise any of these issues in the slightly more than 3 years that the package has been around (by other names), so I'm not sure such a warning needs to be that big. JSON doesn't really have any framing, so serializing more than one document to or from the same place doesn't work so well. It's not even talked about in the spec, and I've never seen someone try it before. -- priority: -> low ___ Python tracker <http://bugs.python.org/issue4783> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4783] json documentation needs a BAWM (Big A** Warning Message)
Bob Ippolito added the comment: Ok, I've added some notes to the trunk of simplejson's documentation. Not sure when/if that'll hit the Python trunks, I've been having a hard time getting my other patches to sync up with simplejson through: http://bugs.python.org/issue4136 ___ Python tracker <http://bugs.python.org/issue4783> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4782] json documentation missing load(), loads()
Bob Ippolito added the comment: There are some missing colons in the documentation apparently, which causes reStructuredText to ignore the documentation for those two functions. -- nosy: +bob.ippolito ___ Python tracker <http://bugs.python.org/issue4782> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with simplejson 2.0.3
Bob Ippolito added the comment:
By "next patch" I'm referring to a currently nonexistent patch that
would merge the json library with simplejson 2.0.7 (svn trunk at the
moment). I may have time to create it next weekend.
---
http://codereview.appspot.com/7311/diff/1/8
File Lib/json/decoder.py (right):
http://codereview.appspot.com/7311/diff/1/8#newcode55
Line 55: def py_scanstring(s, end, encoding=None, strict=True,
_b=BACKSLASH, _m=STRINGCHUNK.match):
Commented in the next patch.
http://codereview.appspot.com/7311/diff/1/8#newcode71
Line 71: _append(content)
Commented in the next patch
http://codereview.appspot.com/7311/diff/1/8#newcode76
Line 76: msg = "Invalid control character {0!r} at".format(esc)
This is a bug in the exception handling code, fixed in the next patch.
http://codereview.appspot.com/7311/diff/1/8#newcode104
Line 104: raise ValueError
Exception is caught at the except block and re-raised with a message.
Next patch unrolls this so it's not confusing.
http://codereview.appspot.com/7311/diff/1/8#newcode107
Line 107: raise ValueError
Exception is caught at the except block and re-raised with a message.
Next patch unrolls this so it's not confusing.
http://codereview.appspot.com/7311/diff/1/8#newcode111
Line 111: m = unichr(uni)
Renamed m to char in the next patch.
http://codereview.appspot.com/7311/diff/1/8#newcode127
Line 127: nextchar = s[end:end + 1]
commented in next patch (only once). s[end] can raise an IndexError with
bad input, s[end:end+1] returns an empty string on underflow, which is
caught later with a more helpful error message.
http://codereview.appspot.com/7311/diff/1/8#newcode132
Line 132: nextchar = s[end:end + 1]
commented in next patch (only once). s[end] can raise an IndexError with
bad input, s[end:end+1] returns an empty string on underflow, which is
caught later with a more helpful error message.
http://codereview.appspot.com/7311/diff/1/8#newcode290
Line 290: following strings: -Infinity, Infinity, NaN.
Not practically speaking. The documented purpose of this callback is
"This can be used to raise an exception if invalid JSON numbers are
encountered.". I've never seen it used to handle None, True, False in a
different manner. That was more of an implementation detail than
anything else, and that is fixed by this patch. Existing implementations
of this callback will simply have dead code since they will never be
called with "null", "true" or "false" anymore.
http://codereview.appspot.com/7311/diff/1/8#newcode317
Line 317: def raw_decode(self, s, idx=0):
It is a compatible change.
http://codereview.appspot.com/7311/diff/1/9
File Modules/_json.c (right):
http://codereview.appspot.com/7311/diff/1/9#newcode196
Line 196: output_size *= 2;
_PyString_Resize checks for integer overflow, so it would explode there
just fine. The next patch changes this slightly to avoid unnecessary
calls to _PyString_Resize when the size didn't actually change, but
doesn't do any explicit integer overflow checking
http://codereview.appspot.com/7311/diff/1/9#newcode215
Line 215: ascii_escape_str(PyObject *pystr)
Done in the next patch
http://codereview.appspot.com/7311/diff/1/9#newcode733
Line 733: "..."
Done in the next patch.
http://codereview.appspot.com/7311/diff/1/9#newcode1320
Line 1320: if ((idx + 3 < length) && str[idx + 1] == 'u' && str[idx + 2]
== 'l' && str[idx + 3] == 'l') {
Probably not, but strncmp doesn't work for PyUnicode and the same code
is repeated there.
http://codereview.appspot.com/7311/diff/1/9#newcode1528
Line 1528: PyTypeObject PyScannerType = {
I don't think it's possible to cause a cycle using the documented APIs,
since the encoder is created and thrown away behind the scenes and never
passed to user code. Someone else can write that patch if it's
necessary.
http://codereview.appspot.com/7311/diff/1/9#newcode2025
Line 2025: "make_encoder", /* tp_name */
It's not a type that's ever exposed to user code, make_encoder is
somewhat less confusing because that's the name it's exposed as. I'll
change it anyway though, it doesn't really matter since this is all
private API.
___
Python tracker
<http://bugs.python.org/issue4136>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5145] struct.calcsize('cd') returns 16 instead of 9
bob gailer added the comment: Someone pointed out that one must consider alignment. I had overlooked that. It makes sense that a d is double-word aligned. Perhaps the documentation should mention alignment. ___ Python tracker <http://bugs.python.org/issue5145> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5145] struct.calcsize('cd') returns 16 instead of 9
New submission from bob gailer :
struct.calcsize('cd') returns 16 instead of 9
struct.calcsize('dc') returns 9 as expected
--
components: Extension Modules
messages: 81085
nosy: bgailer
severity: normal
status: open
title: struct.calcsize('cd') returns 16 instead of 9
type: behavior
versions: Python 2.5
___
Python tracker
<http://bugs.python.org/issue5145>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with latest simplejson 2.0.x
Bob Ippolito added the comment: patch to r69662 is attached as json_issue4136_r69662.diff -- note that simplejson 2.0.9 isn't released, as of r169 it's just simplejson 2.0.8 with some trivial changes to make this backport easier for me ___ Python tracker <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with latest simplejson 2.0.x
Changes by Bob Ippolito : Added file: http://bugs.python.org/file13106/json_issue4136_r69662.diff ___ Python tracker <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4136] merge json library with latest simplejson 2.0.x
Bob Ippolito added the comment: Old-style relative imports and the way that it does join are there because it's Python 2.4 compatible code that I'm porting. I'll add those to the list of things that need to be changed when backporting, implement cyclic GC on the types, and I'll take a look at lines > 80 chars and fix any that occur in Python code (though for some of the tests it may be a bit more effort than its worth). It will probably take another week or two for me to implement those things and then do another backport. ___ Python tracker <http://bugs.python.org/issue4136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
New submission from Bob Kline :
-UNWANTED = re.compile("""['".,?!:;()[\]{}<>\u201C\u201D\u00A1\u00BF]+""")
+UNWANTED =
re.compile("""['".,?!:;()[\]{}<>\\u201C\\u201D\\u00A1\\u00BF]+""")
The non-ASCII characters in the original string are perfectly legitimate str
characters, using valid standard escapes recognized and handled by the Python
parser. It is unnecessary to lengthen the string argument passed to
re.compile() and defer the conversion of the doubled escapes for the regular
expression engine to handle.
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 350922
nosy: bkline
priority: normal
severity: normal
status: open
title: 2to3 introduces unwanted extra backslashes for unicode characters in
regular expressions
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37996>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment: The original string had u"""...""" and the u had already been removed by hand in preparation for moving to Python 3. -- ___ Python tracker <https://bugs.python.org/issue37996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment:
Ah, this is worse than I first thought. It's not just converting code by adding
extra backslashes to regular expression strings, where at least the regular
expression engine will do what the original code was asking the Python parser
to do (unless user code checks for and enforces limits on regular expression
string lengths, so even that case is broken), but 2to3 is also mangling strings
in places where the behavior is changed (that is, broken). 2to3 wants to change
if c not in ".-_:\u00B7\u0e87":
to
if c not in ".-_:\\u00B7\\u0e87":
Not the same thing at all, as illustrated here:
$ python
Python 3.7.3 (default, Jun 19 2019, 07:38:49)
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> len("\u00B7")
1
>>> len("\\u00B7")
6
>>>
That breaks the original code. This is a serious bug.
--
___
Python tracker
<https://bugs.python.org/issue37996>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment: Thanks, I understand. However, this highlights something which had slipped under my radar. You get one shot at running a code set through the tool. You can't do what I was doing, which was to run the tool in "don't write" mode, then fix by hand some of the things it says will need to be done, then run it again in the same mode, fix, etc., until I got to the point where I felt like I could trust it (except for things like adding unnecessary `list()` wrappers, for which I learned how to use the option for suppressing certain default fixers), and then run the tool in write mode to fix what was left. I now totally get why the tool did what it did, and why the approach I was using was inappropriate, but was there a warning to this effect that I missed in the documentation? Something like "you can only run this tool once per fixer (or set of fixers) in write mode, and you cannot run a fixer on code for which you have performed any of the needed conversions for that fixer yourself"? Of cour se, it's always possible I'm the only developer clueless enough not to have figured this out without such a warning. :-) Partly in my (lame) defense, I had lured myself into the frame of mind where what I was doing seemed to make sense by having just come out of a similar exercise with pylint, where iterative "fixing" works just fine. I guess I should take this as a good sign, that my brain has moved so far into the Python 3 world that "..." was no longer recognizable as a bytestring. Again, thanks for the gentle explanation. :-) -- ___ Python tracker <https://bugs.python.org/issue37996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment: In fact, I suppose it's possible that the warning as I worded it is still not restrictive enough, and that there are subtle dependencies between the fixers which would make the action of one of them render the code no longer safely fixable as Python 2 code by the other fixers, and the real warning should really say something like, "You can only run this tool once in write-in-place mode on a given code set. You can run as many times without the -w option as many times, with as many combinations of fixers as you want, determining which of the fixers you will enable for the final write-in-place run." Are there such dependencies between fixers? -- ___ Python tracker <https://bugs.python.org/issue37996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Incorrect "fixing" of isinstance tests for basestring
New submission from Bob Kline : We are attempting to convert a large Python 2 code base. Following the guidance of the official documentation (https://docs.python.org/2/library/functions.html#basestring) we created tests in many, many places that look like this: if isinstance(value, basestring): if not isinstance(value, unicode): value = value.decode(encoding) else: some other code It seems that the 2to3 tool is unaware that replacing basestring with str in such cases will break the software. Here's an example. $ 2to3 repro.py ... --- repro.py(original) +++ repro.py(refactored) @@ -1,8 +1,8 @@ from frobnitz import transform def foo(value, encoding=None): -if isinstance(value, basestring): -if not isinstance(value, unicode): +if isinstance(value, str): +if not isinstance(value, str): value = value.decode(encoding or "utf-8") return value else: Help me understand how this "fix" results in the correct behavior. -- components: 2to3 (2.x to 3.x conversion tool) messages: 350964 nosy: bkline priority: normal severity: normal status: open title: Incorrect "fixing" of isinstance tests for basestring type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Incorrect "fixing" of isinstance tests for basestring
Bob Kline added the comment: > Use str instead. Sure. I understand the advantages of the new approach to strings. Which, by the way, weren't available when this project began. I don't disagree with anything you say in the context of writing new code. I was, however, surprised and dismayed to learn of the cavalier approach the upgrade tool has taken to silently breaking existing code which it is claiming to "fix." Here's my favorite so far. --- cdr.py (original) +++ cdr.py (refactored) @@ -36,15 +36,15 @@ # == from six import itervalues try: -basestring +str is_python3 = False base64encode = base64.encodestring base64decode = base64.decodestring except: base64encode = base64.encodebytes base64decode = base64.decodebytes -basestring = (str, bytes) -unicode = str +str = (str, bytes) +str = str is_python3 = True We wrote this following the example of comparable techniques in http://python-future.org/compatible_idioms.html and similar guides to an upgrade path. Seems we're being punished for taking the trouble to make our code work with Python 2 and 3 during the transition period. :-( It's hard to see how this conversion resulted in something better than what we already had. -- ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Incorrect "fixing" of isinstance tests for basestring
Bob Kline added the comment: > Unless you have a specific proposal, ... I _do_ have a specific proposal: replace `basestring` with `(str, bytes)`, which preserves the behavior of the original code. So, if isinstance(value, basestring) becomes if isinstance(value, (str, bytes)) -- ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Change 2to3 to replace 'basestring' with '(str,bytes)'
Bob Kline added the comment: OK, I give up. In parting I will point out that the official Python 2 documentation says "basestring() This abstract type is the superclass for str and unicode. It cannot be called or instantiated, but it can be used to test whether an object is an instance of str or unicode. isinstance(obj, basestring) is equivalent to isinstance(obj, (str, unicode))." That's exactly what the code we are converting (much of which was written years before Python 3 even existed) was doing. As for the idea that we weren't really "planning to use it as logical text" (ignoring the fact that _everyone_ used Python 2 str objects to represent logical text back in 2003, and ignoring the fact that the repro case given at the top of this report converts the 8-bit string value to Unicode -- why else would it do that except to use the value as "logical text"?) ... well, I don't know where to start. I'm done here. :->} -- ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38409] Typo in doc string for str.strip
New submission from Bob Dowling : The doc string for str.strip() has a typo: the "d" at the end of "removed" is missing. help(str.strip) Currently: Return a copy of the string with leading and trailing whitespace remove. Should be: Return a copy of the string with leading and trailing whitespace removed. I have attached an offered patch. -- components: Library (Lib) files: str_strip.patch keywords: patch messages: 354209 nosy: Bob Dowling priority: normal severity: normal status: open title: Typo in doc string for str.strip type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48648/str_strip.patch ___ Python tracker <https://bugs.python.org/issue38409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38438] argparse "usage" overly-complex with nargs="*"
New submission from Bob Alexander :
This program:
import argparse
ap = argparse.ArgumentParser()
ap.add_argument("arg", nargs="*")
ap.parse_args()
Gives usage message:
usage: help_complexity.py [-h] [arg [arg ...]]
It's correct, but unnecessarily complex and challenging to the user.
If I were manually writing the usage, arg... would do, or maybe [arg ...] to be
consistent with other messages??
--
components: Library (Lib)
messages: 354402
nosy: bobjalex
priority: normal
severity: normal
status: open
title: argparse "usage" overly-complex with nargs="*"
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue38438>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
