[issue1481036] IOBaseError
Changes by Armin Rigo [EMAIL PROTECTED]: -- nosy: -arigo _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481036 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1529142] Allowing multiple instances of IDLE with sub-processes
Tal Einat [EMAIL PROTECTED] added the comment: I really, really wish we could get this in for Python2.6 - this issue is a major drawback for beginners, for whom IDLE is mostly intended. Perhaps not this specific patch; I am willing to work on cleaning up the code and getting it tested by users on different platforms. Is there any chance of this happening? What can I do to get this moving again? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1529142 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2630] repr() should not escape non-ASCII characters
New submission from atsuo ishimoto [EMAIL PROTECTED]: In py3k, repr() escapes non-ASCII characters in Unicode to \u as Python 2. This is unpleasant feature if you are working with non-latin characters. This issue was once discussed by Hye-Shik Chang[1], but was rejected. Here's a new challenge for Python 3 to fix issue. In this patch, repr() converts special ascii characters such as \t, \r, \n, but doesn't convert non-ASCII characters to \u form. Non-ASCII characters are converted by TextIOWrapper on printing. I set 'errors' attribute of sys.stdout and sys.stderr to 'backslashreplace', so un-printable characters are converted to '\u' if your console cannot print such characters. This patch breaks five regr tests on my environment. I'll fix these tests if this patch is acceptable. [1] http://mail.python.org/pipermail/python-dev/2002-October/029443.html http://bugs.python.org/issue479898 -- components: None files: diff.txt messages: 65461 nosy: ishimoto severity: normal status: open title: repr() should not escape non-ASCII characters type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file10028/diff.txt __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2058] reduce tarfile memory footprint
Lars Gustäbel [EMAIL PROTECTED] added the comment: Checked into the py3k branch as r62337. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2058 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2628] ftplib Persistent data connection
Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- nosy: +giampaolo.rodola __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2628 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2518] smtpd.py to handle huge email
Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- nosy: +giampaolo.rodola __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2518 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2559] atom sorting error when building ctypes
Thomas Heller [EMAIL PROTECTED] added the comment: So closing this as won't fix. -- resolution: - wont fix status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2559 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1797] ctypes function pointer enhancements
Changes by Thomas Heller [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9129/ctypes-funcptr.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1797 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1797] ctypes function pointer enhancements
Thomas Heller [EMAIL PROTECTED] added the comment: Remove useless file (doesn't contain a patch). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1797 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1092502] Memory leak in socket.py on Mac OS X
Ralf Schmitt [EMAIL PROTECTED] added the comment: I think this should be fixed somewhere in the c code. people calling sock.recv which a large recv size will also trigger this error. this fix is wrong. the fixed code reads one byte at a time. see: http://mail.python.org/pipermail/python-dev/2008-April/078613.html -- nosy: +schmir _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1092502 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2616] ctypes.pointer(), ctypes.POINTER() speedup
Thomas Heller [EMAIL PROTECTED] added the comment: Committed a slightly modified patch as rev 62338; will also be merged into py3k. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2616 __ ___ 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
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi Martin, 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): # ./configure --enable-shared --target=powerpc64-unknown-linux BASECFLAGS='-m64' output generated by configure script # make gcc -pthread -c -m64 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from Include/Python.h:57, from ./Modules/python.c:3: Include/pyport.h:761:2: error: #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). make: *** [Modules/python.o] Error 1 As you can see, the compilation fails. Now, if I try this configure line: # ./configure --enable-shared --target=powerpc64-unknown-linux BASECFLAGS='-m64' CFLAGS='-m64' output from configure # make Compilation goes well untill: gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl -lutil -o Parser/pgen As you can see, in this specific line we don't have the '-m64' flag, what causes a bunch of errors (all of them due to the absence of '-m64' flag). Ok, so I decided to try with LDFLAGS: # ./configure --enable-shared --target=powerpc64-unknown-linux BASECFLAGS='-m64' CFLAGS='-m64' LDFLAGS='-m64' output from configure # make Now, the error happens when libpython.so is generated (and the reason is the same: missing '-m64'). Well, now I have a few questions: 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. 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? Also, should we propagate LDFLAGS through Makefile? IMHO, we should. Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'. But again, I don't think this is a solution for this issue :-). _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1092502] Memory leak in socket.py on Mac OS X
A.M. Kuchling [EMAIL PROTECTED] added the comment: Note that _rbufsize is only set to 1 if the _fileobject's bufsize is set to 0. So perhaps the bug is that some library is turning off buffering when it shouldn't. I don't see how you would fix this in the C code, other than manually doing two separate mallocs and copying the data, which would unfairly penalize platforms with smarter malloc() implementations. What sort of fix would you suggest? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1092502 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2389] Array pickling exposes internal memory representation of elements
Guido van Rossum [EMAIL PROTECTED] added the comment: This looks indeed wrong. Unfortunately it also looks hard to fix in a way that won't break unpickling arrays pickled by a previous Python version. We won't be able to fix this in 2.5 (it'll be a new feature) but we should try to fix this in 2.6 and 3.0. -- nosy: +gvanrossum priority: - critical versions: +Python 3.0 -Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2389 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2630] repr() should not escape non-ASCII characters
Guido van Rossum [EMAIL PROTECTED] added the comment: I think this has potential, but it is too liberal. There are many more characters that cannot be assumed printable, e.g. many of the Latin-1 characters in the range 0x80 through 0x9F. Isn't there some Unicode data table that shows code points that are safely printable? OTOH there are other potential use cases where it would be nice to see the \u escapes, e.g. when one is concerned about sequences that print the same but don't have the same content (e.g. pre-normalization). The backslashreplace trick is nice, I didn't even know about that. :-) -- keywords: +patch nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2631] IMPORT_NAME Documentation is incomplete
New submission from Paul Bonser [EMAIL PROTECTED]: The documentation for IMPORT_NAME at http://docs.python.org/lib/bytecodes.html doesn't mention the fact that the instruction requires two parameters to be on the stack. TOS and TOS1 should map to the fromlist and level parameters to the builtin function __import__, respectively. -- assignee: georg.brandl components: Documentation messages: 65471 nosy: georg.brandl, pib severity: normal status: open title: IMPORT_NAME Documentation is incomplete versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2631 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
New submission from Curt Hagenlocher [EMAIL PROTECTED]: First reported by Ralf Schmitt. I haven't checked 2.6 or 3.0. -- components: Library (Lib) files: socket.py.diff keywords: patch messages: 65472 nosy: CurtHagenlocher severity: normal status: open title: socket._fileobject.read(n) should ignore _rbufsize when 1 type: performance versions: Python 2.5 Added file: http://bugs.python.org/file10029/socket.py.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Raghuram Devarakonda [EMAIL PROTECTED] added the comment: The relevant python-dev thread is http://mail.python.org/pipermail/python-dev/2008-April/078613.html -- nosy: +draghuram __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Guido van Rossum [EMAIL PROTECTED] added the comment: Do I need to look at this, or is the review going well without my interference? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue852532] ^$ won't split on empty line
Mike Coleman [EMAIL PROTECTED] added the comment: I'd feel better about this bug being 'wont fix'ed if I had a sense that several people considered the patch and thought that it sucked. At the moment, it seems more like it just fell off of the end without ever being seriously contemplated. :-( Tracker [EMAIL PROTECTED] http://bugs.python.org/issue852532 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: Hi Guido, The patch changes a minor things to io.py to allow io.BytesIO to pass my test suite, so you may want to check it out. Other than that, I think the review is going fine. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2277] MozillaCookieJar does not support Firefox3 cookie files
Changes by Gerhard Häring [EMAIL PROTECTED]: -- nosy: +ghaering __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2277 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Guido van Rossum [EMAIL PROTECTED] added the comment: Once the review for this is completed I have no objection to it going in. -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ 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
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? Also, should we propagate LDFLAGS through Makefile? IMHO, we should. Again, if you specify CC as above, you don't have to. Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'. But again, I don't think this is a solution for this issue :-). Why not? Regards, Martin _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Michael Amrhein [EMAIL PROTECTED] added the comment: Alexander Belopolsky [EMAIL PROTECTED] added the comment: ... '*' is a perfectly legal filename character on most filesystems Oops! Never thought of putting a '*' into a file name. Obviously, I should have tried before ... Ok, then I agree that, for not breaking existing code, the match function should default to string comparison. I'll provide a second revised patch in the next days. And, I'll chain ignore and hide, as you proposed. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1738 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1683368] object.__init__ shouldn't allow args/kwds
Changes by Guido van Rossum [EMAIL PROTECTED]: -- status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1683368 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2633] Improve subprocess.Popen() documentation (env parameter)
New submission from Roy Smith [EMAIL PROTECTED]: http://docs.python.org/lib/node528.html (17.1.1 Using the subprocess Module) describes the env parameter thusly: If env is not None, it defines the environment variables for the new process. This is too vague to be useful. If it's not None, what should it be? A dictionary in the style of os.environ? A sequence of name/value pairs? A string with some sort of delimiter between each entry? -- assignee: georg.brandl components: Documentation messages: 65480 nosy: georg.brandl, roysmith severity: normal status: open title: Improve subprocess.Popen() documentation (env parameter) versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2633 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2535] duplicate Misc.lower
Changes by A.M. Kuchling [EMAIL PROTECTED]: -- keywords: +easy __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2535 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1092502] Memory leak in socket.py on Mac OS X
Ralf Schmitt [EMAIL PROTECTED] added the comment: Well, I think the right thing to do is limit the maximal size to be read inside the c function (just to make it impossible to pass around large values). This is basically the same fix just at another place in the code. http://twistedmatrix.com/trac/ticket/1079 describes the same problem (but with 64 k read requests: it can even leak with small requests). The fix there was to really copy those strings around into a StringIO object. Note that the code does not read byte by byte when passing in no size argument. Instead it read recv_size bytes: if self._rbufsize = 1: recv_size = self.default_bufsize else: recv_size = self._rbufsize This seems clearly wrong to me. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1092502 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1092502] Memory leak in socket.py on Mac OS X
Ralf Schmitt [EMAIL PROTECTED] added the comment: that is it seems wrong that it uses 1 byte when a size is given, and recv_size when size is not given. By the way I think if you ask for 4096 bytes and the buffering is set to 2048 bytes it should still try to read the full 4096 bytes. The number of bytes it tries to read however. should be limited by whatever the system maximally returns. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1092502 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2630] repr() should not escape non-ASCII characters
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: What if we turn on the backslashreplace trick for some operations only? For example: sys_displayhook and sys_excepthook. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Changes by Ralf Schmitt [EMAIL PROTECTED]: -- nosy: +schmir __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2622] Import errors in email.message.py
John Jackson [EMAIL PROTECTED] added the comment: Attached is a sample code that reproduces the problem under python 2.5 on Mac OS 10.4.11. See file for instructions on how to reproduce the issue. Added file: http://bugs.python.org/file10030/test_mailbox.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2622 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Ralf Schmitt [EMAIL PROTECTED] added the comment: One more time: the change is wrong. It should try to recv the maximum not the minimum of size, buffer_size. If you using a buffering of 16 bytes it will otherwise call recv 256 times when you want to read 1024 bytes. this is wrong. However there should be an upper limit, it doesn't make sense to read 10MB from socket in one recv call (imap bug). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Changes by Ralf Schmitt [EMAIL PROTECTED]: -- versions: +Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Changes by Guido van Rossum [EMAIL PROTECTED]: -- priority: - critical __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Ralf Schmitt [EMAIL PROTECTED] added the comment: akuchling, I added you to the nosy list. hope that's ok. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Changes by Ralf Schmitt [EMAIL PROTECTED]: -- nosy: +akuchling __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Antoine Pitrou [EMAIL PROTECTED] added the comment: This is apparently the same issue as #2601. -- nosy: +pitrou __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time
Antoine Pitrou [EMAIL PROTECTED] added the comment: See #2632 for more discussion of what is probably the same issue. -- nosy: +pitrou __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2601 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time
Changes by Ralf Schmitt [EMAIL PROTECTED]: -- nosy: +schmir __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2601 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Ralf Schmitt [EMAIL PROTECTED] added the comment: ahh. yes, same issue. should have taken a look at the bugtracker before, would have saved me some time... __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2630] repr() should not escape non-ASCII characters
atsuo ishimoto [EMAIL PROTECTED] added the comment: I think this has potential, but it is too liberal. There are many more characters that cannot be assumed printable, e.g. many of the Latin-1 characters in the range 0x80 through 0x9F. Isn't there some Unicode data table that shows code points that are safely printable? As Michael Urman pointed out, we can use Unicode properties. Or we can define a set of non-printable characters (e.g. sys.nonprintablechars). OTOH there are other potential use cases where it would be nice to see the \u escapes, e.g. when one is concerned about sequences that print the same but don't have the same content (e.g. pre-normalization). For such cases, print(s.encode(ascii, backslashreplace)) might work. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2630] repr() should not escape non-ASCII characters
atsuo ishimoto [EMAIL PROTECTED] added the comment: What if we turn on the backslashreplace trick for some operations only? For example: sys_displayhook and sys_excepthook. It would be difficult, since *_repr() API don't know who is the caller. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ 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? Also, should we propagate LDFLAGS through Makefile? IMHO, we should. Again, if you specify CC as above, you don't have to. Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'. But again, I don't think this is a solution for this issue :-). Why not? Regards, Martin _ Tracker [EMAIL
[issue2630] repr() should not escape non-ASCII characters
Guido van Rossum [EMAIL PROTECTED] added the comment: Atsuo: I missed Michael Urman's comment. Can you copy it here, or (better :-) write a patch that uses it? Amaury: I think it would be okay to use backslashreplace as the default error handler for sys.stderr. Probably not for sys.stdout or other files, since I'm sure many users prefer the errors when their data cannot be printed rather than silently writing \u escapes that might cause other code reading their output to choke. For sys.stderr though I think not having exceptions raised when attempting to print errors is very valuable. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2630] repr() should not escape non-ASCII characters
atsuo ishimoto [EMAIL PROTECTED] added the comment: Okay, I'll revise a patch later today. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2611] Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.
Neal Norwitz [EMAIL PROTECTED] added the comment: I think this will be fairly difficult to set up. If the clean buildstep had been executed, you would have to rerun configure and compile before you can run any tests. We could re-order and do clean first. That would leave all the build artifacts in tact after a build which would be nice for some debugging. Also, how would you communicate what specific test you want to run? I agree here. My guess is it would be pretty hard to modify the buildbot to support this. I don't have bandwidth to help. It would be nice to have, but probably not a high priority. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2611 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2634] os.execvpe() docs need to be more specific
New submission from Roy Smith [EMAIL PROTECTED]: Note: this is (sort of) related to Issue2633. http://docs.python.org/lib/os-process.html (14.1.5 Process Management). The docs for os.execvpe() say, the env parameter must be a mapping which is used to define the environment variables for the new process. It's not clear if this mapping replaces the existing environment, or defines additional entries which are added to the existing environment. This should be clarified. This applies to the spawn*() methods too. -- assignee: georg.brandl components: Documentation messages: 65496 nosy: georg.brandl, roysmith severity: normal status: open title: os.execvpe() docs need to be more specific versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2634 __ ___ 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
Martin v. Löwis [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. 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? 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. 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. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2611] Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.
Martin v. Löwis [EMAIL PROTECTED] added the comment: We could re-order and do clean first. That would leave all the build artifacts in tact after a build which would be nice for some debugging. With the current setup, that wouldn't quite work. We can't run it before configure, because we might have no Makefile to invoke the clean target, and we can't run it after configure, as we run make distclean, which deletes the makefile. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2611 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Curt Hagenlocher [EMAIL PROTECTED] added the comment: I've attached a much better patch as suggested by Guido Added file: http://bugs.python.org/file10032/socket.py.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Changes by Curt Hagenlocher [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10029/socket.py.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
Ralf Schmitt [EMAIL PROTECTED] added the comment: This patch handles the case where the caller has specified the size argument. When size is unspecified, it should be handled as if size was infinite. By the formula from your patch, this should be recv_size = min(self.max_readsize, max(self._rbufsize, left)) (== min(self.max_readsize, inf) == self.max_readsize) and not the current code: if self._rbufsize = 1: recv_size = self.default_bufsize else: recv_size = self._rbufsize while True: data = self._sock.recv(recv_size) BTW, I still think this max_readsize limit should be handled somewhere deeper in the code. at least maybe in the _socketobject class. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2122] mmap.flush does not check for errors on windows
Changes by Martin v. Löwis [EMAIL PROTECTED]: -- keywords: +patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2122 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2635] textwrap: bug in 'fix_sentence_endings' option
New submission from Giuseppe Scelsi [EMAIL PROTECTED]:
textwrap.fill('File stdio.h is nice.',
... fix_sentence_endings=True)
'File stdio.h is nice.'
^-- wrong double space!
The problem is with the compiled regexp 'sentence_end_re' in
'textwrap.py'. A possible fix would be to add the following line after
line 90 in textwrap.py:
r'$' # end of chunk
Giuseppe
--
components: Library (Lib)
messages: 65501
nosy: gscelsi
severity: normal
status: open
title: textwrap: bug in 'fix_sentence_endings' option
type: behavior
versions: Python 2.4
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2635
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2235] __eq__ / __hash__ check doesn't take inheritance into account
Changes by Neal Norwitz [EMAIL PROTECTED]: -- assignee: amaury.forgeotdarc - gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2235 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
