[issue4725] reporting file locations in egg (and other package) files
Martin v. Löwis mar...@v.loewis.de added the comment: A use case here is in a stack trace or a debugger where an error occured. For example does this come from an egg? And if so, which one? Perhaps I have missed something in PEP 302, or perhaps this is defined elsewhere. Please elucidate. Please understand that the bug tracker is not a place to ask questions, or get help. If you make a bug report, *ALWAYS* follow this pattern: 1. this is what I did 2. this is what happened 3. this is what I would have expected instead If you want to get help in doing something that you don't know how to do, or need elucidation, use python-l...@python.org. If you are proposing a new feature, and want to discuss the design of it, use python-...@python.org; you might be told to write a PEP if the feature is more complex. I'm going to close this report as invalid. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4725] reporting file locations in egg (and other package) files
Changes by Martin v. Löwis mar...@v.loewis.de: -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4728] Endianness and universal builds problems
Martin v. Löwis mar...@v.loewis.de added the comment: This is related to issue4060. Ronald, what is the status of that? The only reason why BIGENDIAN could be defined in the official binaries is that the build was created on a PPC system. Benjamin, is that the case? -- nosy: +benjamin.peterson, loewis, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4728 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Dmitry Vasiliev d...@hlabs.spb.ru added the comment: OK, I've attached PEP-333 compatible fixes for wsgiref. I think there is only one problem remains: - wsgiref expects io.BytesIO as input and output streams because of http.server module. I didn't find any restrictions on data returned by read() method of the wsgi.input stream in the PEP. Maybe I've missed some details? Added file: http://bugs.python.org/file12431/wsgiref_pep333.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4730] cPickle corrupts high-unicode strings
New submission from Nathaniel Smith n...@pobox.com: cPickle.dump by default does not properly encode unicode characters outside the BMP -- it throws away the high bits: cPickle.loads(cPickle.dumps(u\U00012345)) u'\u2345' The problem is in dump, not load: pickle.dumps(u\U00012345) # works 'V\\U00012345\np0\n.' cPickle.dumps(u\U00012345) # no! 'V\\u2345\n.' It does work correctly when using a more modern pickling protocol: cPickle.loads(cPickle.dumps(u\U00012345, 1)) u'\U00012345' cPickle.loads(cPickle.dumps(u\U00012345, 2)) u'\U00012345' But this is not much comfort for users whose data has been corrupted because they went with the defaults. (Fortunately in my application I knew that all my characters were in the supplementary plane, so I could repair the data after the fact, but...) Above tests are with 2.5.2, but from checking the source, the bug is obviously still present in 2.6.1: cPickle.c:modified_EncodeRawUnicodeEscape has no code to handle 32-bit unicode values. OTOH, it does look like someone noticed the problem and fixed it for 3.0; _pickle.c:raw_unicode_escape handles such characters fine. Guess they just forgot to backport the fixes... but the code is there, and can probably just be copy-pasted back to 2.6. -- components: Library (Lib) messages: 78230 nosy: njs severity: normal status: open title: cPickle corrupts high-unicode strings versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4730 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86
Mark Dickinson dicki...@gmail.com added the comment: Final patch. Skip, could you please give this one a try, and then with any luck this can be fixed for 3.0.1. (Sorry for creating more work; this should be the last time.) I've added a configure test that detects x87 FPU usage, via the double rounding issue associated with the x87. If x87 is detected then _Py_force_double is used via a macro Py_FORCE_DOUBLE; otherwise, Py_FORCE_DOUBLE does nothing. When you configure on a machine that uses x87, you should see: checking for x87-style double rounding... yes in the configure output. Added file: http://bugs.python.org/file12432/force_to_memory5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4575 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Antoine Pitrou pit...@free.fr added the comment: Please read the two paragraphs *after* the one you quoted. I don't see anything forbidding bytes objects in those two paragraphs. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4710] [PATCH] zipfile.ZipFile does not extract directories properly
Kuba Wieczorek faw...@gmail.com added the comment: Here is a revised version of the patch with directories support for write(). It works like UNIX zip program so if a directory path is passed to the function, it stores only the directory itself (without the contents). This time without tests as well because I don't want to mess up with them until I finish my patch completely. Added file: http://bugs.python.org/file12433/zipfile_dirs_support.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4710 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4728] Endianness and universal builds problems
Benjamin Peterson musiccomposit...@gmail.com added the comment: Yes, I made the build on a PPC machine. I'm no expert on this, but maybe we should just get rid of the configure check and use the __LITTLE_ENDIAN__ and __BIG_ENDIAN__ macros. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4728 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Antoine Pitrou pit...@free.fr added the comment: Le mardi 23 décembre 2008 à 11:15 +, Dmitry Vasiliev a écrit : Dmitry Vasiliev d...@hlabs.spb.ru added the comment: OK, I've attached PEP-333 compatible fixes for wsgiref. I may be mistaken, but it seems that your patch forces iso-8859-1 encoding of http bodies. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Dmitry Vasiliev d...@hlabs.spb.ru added the comment: Antoine Pitrou wrote: Le mardi 23 décembre 2008 à 11:15 +, Dmitry Vasiliev a écrit : OK, I've attached PEP-333 compatible fixes for wsgiref. I may be mistaken, but it seems that your patch forces iso-8859-1 encoding of http bodies. No, just as PEP said str used as a container for binary data. For example to return UTF-8 encoded data you can use the following code: def app(environ, start_response): ... return [data.encode(utf-8).decode(iso-8859-1)] I don't like it but I guess it's strictly follow the PEP (actually I didn't notice this sections before): On Python platforms where the str or StringType type is in fact Unicode-based (e.g. Jython, IronPython, Python 3000, etc.), all strings referred to in this specification must contain only code points representable in ISO-8859-1 encoding (\u through \u00FF, inclusive). It is a fatal error for an application to supply strings containing any other Unicode character or code point. Similarly, servers and gateways must not supply strings to an application containing any other Unicode characters. Again, all strings referred to in this specification must be of type str or StringType, and must not be of type unicode or UnicodeType. And, even if a given platform allows for more than 8 bits per character in str/StringType objects, only the lower 8 bits may be used, for any value referred to in this specification as a string. We definitely need to use bytes in the future but it requires PEP update and some migration guide. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Antoine Pitrou pit...@free.fr added the comment: No, just as PEP said str used as a container for binary data. This is clearly the wrong thing to do. The only (immutable) string-like object adequate for binary data in py3k is bytes, not str. I understand the desire to stick to the PEP, but the PEP was devised even before the first py3k alphas, and it clearly wasn't written with py3k in mind. For example the following sentence becomes nonsensical: Again, all strings referred to in this specification must be of type str or StringType, and must not be of type unicode or UnicodeType. since str objects *are* of type UnicodeType in py3k (and the C API is still named PyUnicode_*)... When a legal text becomes nonsensical wrt. reality, one has to adapt his interpretation of the text to reality, not adapt reality to match the nonsense. In other words, wsgiref should accept/expose HTTP bodies as bytes, not str. Confusing binary data with iso-8859-1 text is the kind of mess py3k was designed to avoid. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4730] cPickle corrupts high-unicode strings
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4730 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Martin v. Löwis mar...@v.loewis.de added the comment: I have now reverted the patch in r67914. I won't reject the patch because of Scott's alternative, but leave it open for review. Since Scott's patch is not approved yet, this is not a release blocker anymore. -- assignee: loewis - priority: release blocker - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I've combined Scott's patch with John's (?) test case in issue1706039.diff. Confirmed that the patch fixes the issue on Mac OS X 10.5.6 (Intel). Added file: http://bugs.python.org/file12434/issue1706039.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Maybe not a problem, but an inconsistency: in Py_UniversalNewlineFgets clearerr is added inside univ_newline conditional and then again before the loop over characters, but in Py_UniversalNewlineFread it is added only once before if (!f-f_univ_newline). I am not sure which approach is right, but I don't think there is a reason for the two functions to be different. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Phillip J. Eby p...@telecommunity.com added the comment: Antoine, you have three choices here: 1. Follow the PEP, 2. Take it to the Web-SIG and get the appropriate discussion, consensus, and PEP revision, or 3. Drop wsgiref from the current release of Py3K until #2 can be done. Which would you prefer? Please note that your arguments regarding what revision should take place are irrelevant here; the correct forum for that discussion is the Web-SIG. Personally, I think they are valid arguments; WSGI simply did not have the benefit of having a sane (and standard!) bytes type available, and were we writing the spec today, I would absolutely have specified it in a bytes-oriented way, and treated older Pythons as the special case. However, we have to take into consideration how applications will be *migrated* to Py3K. I am not an expert in this, nor do I personally have huge volumes of code that will be migrated. Therefore, the correct forum for discussing migration impact and how best to write the spec is the Web-SIG. Making the change to bytes is not something to be undertaken on a whim: the spec must include how to handle inadvertent mixing of bytes and unicode, in order to allow unambiguous error handling and migration support. It will not be solved by the fiat of one individual: certainly not by you or I. And it has absolutely nothing to do with what is right in the technical sense, because it is not a technical problem. A specification is a social construct, not a technical one, so changing wsgiref by itself solves nothing. And that's why those three choices are the only available options, so far as I am aware. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
John Smith ebgs...@gmail.com added the comment: Sorry for inconvenience caused with the patch. I should've got more reviews before asking it checked in. I verified eof2.diff-applied-python gets Bus error and Scott Dial's fileobject.diff fixes this. (Test was on 9.6.0 Darwin Kernel Version 9.6.0) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4710] [PATCH] zipfile.ZipFile does not extract directories properly
Changes by Kuba Wieczorek faw...@gmail.com: Removed file: http://bugs.python.org/file12433/zipfile_dirs_support.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4710 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4710] [PATCH] zipfile.ZipFile does not extract directories properly
Changes by Kuba Wieczorek faw...@gmail.com: Added file: http://bugs.python.org/file12435/zipfile_dirs_support.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4710 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial sc...@scottdial.com added the comment: They differ because in Py_UniversalNewlineFgets() there is a call to FLOCKFILE(), and it seemed appropriate to ensure that clearerr() was called after locking the FILE stream. I certainly pondered over whether it made a difference to do it before or after, and it would seem to me that if we are bothering to lock the FILE stream then we would care to ensure that the first GETC() after locking reaps the benefit of having called clearerr(). In the cases that we fall into fread and fgets, we may actually need to be doing: FLOCKFILE(stream) clearerr(stream); result = fgets(buf, n, stream); FUNLOCKFILE(stream); return result; One nitpick is that the testcase was appended to the StdoutTests class instead of OtherFileTests class, which would seem more appropriate. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4602] 2to3 drops executable bit with --write
Adeodato Simó d...@net.com.org.es added the comment: Hello, I see that something akin to my proposed patch was applied, but I think the order of the arguments to shutil.copymode was reversed in the process. This function takes (src, dst) as arguments, and we want permissions to flow backup - newfile, and not the the other way around. Thanks already. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4731] suggest change to Failed to find the necessary bits to build these modules message
New submission from Mike Coleman m...@users.sourceforge.net: I was thrown by the Failed to find the necessary bits to build these modules message at the end of newer Python builds, and thought that this indicated that the Python executable itself was not built. That's arguably stupidity on my part, but I wonder if others will not trip on this, too. Would it be possible to change this wording slightly, to something like Python built, but failed to find the necessary bits to build these modules ? -- components: Build messages: 78245 nosy: mkc severity: normal status: open title: suggest change to Failed to find the necessary bits to build these modules message type: feature request versions: Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1068268] subprocess is not EINTR-safe
Matteo Bertini matt...@naufraghi.net added the comment: Please have a look at the proposed patch: http://bugs.python.org/file11511/subprocess-eintr-safety-25maint- r65475.patch the list is more or less the patch itself. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1068268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4728] Endianness and universal builds problems
Martin v. Löwis mar...@v.loewis.de added the comment: Yes, I made the build on a PPC machine. Hmm. Ronald's instructions say that the build machine must be x86 for the build to work. I don't know what other consequences using PPC would have; I recommend that we follow these instructions until we understand them enough to change them. I'm no expert on this, but maybe we should just get rid of the configure check and use the __LITTLE_ENDIAN__ and __BIG_ENDIAN__ macros. That won't work, as not all compilers define these macros. The 2.5 approach works fine (use the macros on OSX, and use the configure test elsewhere). Unfortunately, that support got removed in r63955. The patch in issue4060 looks fine; I'm unsure why it hasn't been applied yet. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4728 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4602] 2to3 drops executable bit with --write
Benjamin Peterson musiccomposit...@gmail.com added the comment: Thanks for pointing that out! Fixed in r67919. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4732] Object allocation stress leads to segfault on RHEL
New submission from Andrew Gillis fbsd...@gmail.com: Allocating large numbers of strings objects has been causing Python to segfault on RHEL. Originally detected when sending large data structures over XMLRPC, but also happens when appending large numbers of small strings to a list and calling join in the list. -- Crash is always a segmentation fault when accessing the free list to allocate a python object (obmalloc.c) or an invalid pointer when accessing a string object during a join operation (stringobject.c) -- Happens on RHEL with latest updates and no modified RPMs. -- Also happens with Python built from source on RHEL machine. -- Crash happens on RHEL machines running on different hardware. -- Reproducible with Python 2.4, 2.5, 2.6 and RHEL 5.1 and 5.2. -- Problem not seed on FreeBSD 6.2 or 7.0. Attached to the bug report is a script that is capable of recreating the problem on various RHEL and Python versions. If running three instances of the script, usually one of them will segfault within 30 minutes. Below is a backtrace from the crash. This is in a call to join(), concatenating a very long sequence of strings. While iterating over the sequence of string objects to get the memory needed, one of the string objects appears to be located in invalid memory, resulting in segfault. #0 string_join (self=0xb7ee3098, orig=0xb08696c) at Objects/stringobject.c:1776 #1 0x008d3749 in PyEval_EvalFrameEx (f=0xb29499c, throwflag=0) at Python/ceval.c:3561 #2 0x008d4922 in PyEval_EvalCodeEx (co=0xb7c690b0, globals=0xb7edcdfc, locals=0x0, args=0x9dc29dc, argcount=2, kws=0x9dc29e4, kwcount=0, defs=0xb7c6cb78, defcount=1, closure=0x0) at Python/ceval.c:2836 #3 0x008d284c in PyEval_EvalFrameEx (f=0x9dc2884, throwflag=0) at Python/ceval.c:3669 #4 0x008d32bd in PyEval_EvalFrameEx (f=0xaef0414, throwflag=0) at Python/ceval.c:3659 #5 0x008d4922 in PyEval_EvalCodeEx (co=0xa2f2920, globals=0xa2d90b4, locals=0x0, args=0xab29710, argcount=1, kws=0xab29714, kwcount=3, defs=0xa2f3420, defcount=4, closure=0x0) at Python/ceval.c:2836 #6 0x008d284c in PyEval_EvalFrameEx (f=0xab295ac, throwflag=0) at Python/ceval.c:3669 #7 0x008d32bd in PyEval_EvalFrameEx (f=0xa936f614, throwflag=0) at Python/ceval.c:3659 #8 0x008d4922 in PyEval_EvalCodeEx (co=0x8f1b218, globals=0x8f1546c, locals=0x0, args=0xb347338, argcount=1, kws=0xb34733c, kwcount=0, defs=0x8f17c98, defcount=1, closure=0x0) at Python/ceval.c:2836 #9 0x008d284c in PyEval_EvalFrameEx (f=0xb3471ec, throwflag=0) at Python/ceval.c:3669 #10 0x008d32bd in PyEval_EvalFrameEx (f=0xaa322eac, throwflag=0) at Python/ceval.c:3659 #11 0x008d32bd in PyEval_EvalFrameEx (f=0xad9c8b4, throwflag=0) at Python/ceval.c:3659 #12 0x008d32bd in PyEval_EvalFrameEx (f=0xaa3e62c, throwflag=0) at Python/ceval.c:3659 #13 0x008d32bd in PyEval_EvalFrameEx (f=0xa93ef14, throwflag=0) at Python/ceval.c:3659 #14 0x008d32bd in PyEval_EvalFrameEx (f=0xa6422c4, throwflag=0) at Python/ceval.c:3659 #15 0x008d4922 in PyEval_EvalCodeEx (co=0x8f28e30, globals=0x8f23604, locals=0x0, args=0xa528cd8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836 #16 0x0087145a in function_call (func=0x8f2bf7c, arg=0xa528ccc, kw=0x0) at Objects/funcobject.c:517 #17 0x0084e917 in PyObject_Call (func=0x13e01, arg=0xa528ccc, kw=0x0) at Objects/abstract.c:1861 #18 0x008561a5 in instancemethod_call (func=0x9694284, arg=0xa528ccc, kw=0x0) at Objects/classobject.c:2519 #19 0x0084e917 in PyObject_Call (func=0x13e01, arg=0xb7ee302c, kw=0x0) at Objects/abstract.c:1861 #20 0x008cc67c in PyEval_CallObjectWithKeywords (func=0x9694284, arg=0xb7ee302c, kw=0x0) at Python/ceval.c:3442 #21 0x00903394 in t_bootstrap (boot_raw=0xaaedf98) at ./Modules/threadmodule.c:424 #22 0x00cf745b in start_thread () from /lib/libpthread.so.0 #23 0x00c2fc4e in clone () from /lib/libc.so.6 Here is the top of another backtrace that occurs when accessing a free list to allocate a Python object: #0 0x0808825b in PyObject_Malloc (nbytes=41) at Objects/obmalloc.c:747 #1 0x0808d998 in PyString_FromStringAndSize (str=0x0, size=17) at Objects/stringobject.c:75 ... -- components: Interpreter Core files: python_memtest.tbz messages: 78249 nosy: ajg severity: normal status: open title: Object allocation stress leads to segfault on RHEL type: crash versions: Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file12436/python_memtest.tbz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4733] Add a decode to declared encoding version of urlopen to urllib
New submission from Daniel Diniz aja...@gmail.com: This patch adds a version of urlopen that uses available encoding information to return strings instead of bytes. The main goal is to provide a shortcut for users that don't want to handle the decoding in the easy cases[1]. One added benefit it that the failures of such a function would be make it clear why 2.x style str is either bytes or text is flawed for network IO. Currently, charset detection simply uses addinfourl.get_charset(), but optionally checking for HTTP headers might be more robust. [1] http://groups.google.com/group/comp.lang.python/browse_thread/thread/b88239182f368505 [Executive summary] Glenn G. Chappell wrote: 2to3 doesn't catch it, and, in any case, why should read() return bytes, not string? Carl Banks wrote: It returns bytes because it doesn't know what encoding to use. [...] HOWEVER... [...] It's reasonable that IF a url request's Content-type is text, and/or the Content-encoding is given, for urllib to have an option to automatically decode and return a string instead of bytes. Christian Heimes wrote: There is no generic and simple way to detect the encoding of a remote site. Sometimes the encoding is mentioned in the HTTP header, sometimes it's embedded in the head section of the HTML document. Daniel Diniz wrote: [... A] decode to declared HTTP header encoding version of urlopen could be useful to give some users the output they want (text from network io) or to make it clear why bytes is the safe way. [/Executive summary] -- components: Library (Lib) files: urlopen_text.diff keywords: patch messages: 78250 nosy: ajaksu2 severity: normal status: open title: Add a decode to declared encoding version of urlopen to urllib type: feature request versions: Python 3.1 Added file: http://bugs.python.org/file12437/urlopen_text.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Graham Dumpleton graham.dumple...@gmail.com added the comment: Note that the page: http://www.wsgi.org/wsgi/Amendments_1.0 contains clarifications for WSGI PEP in respect of Python 3.0. This list was previously come up with on WEB-SIG list. As another reference implementation for Python 3.0, you might look at mod_wsgi (source code from subversion trunk), as that has been updated to support Python 3.0 in line with those list of proposed clarifications for WSGI PEP. -- nosy: +grahamd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4734] broken link for 2.5.3 doc download
New submission from George Yoshida qui...@users.sourceforge.net: Download page for 2.5.3 documantation is not ready. --- Go to Documentation top page: http://docs.python.org/ click Previous versions click Python 2.5.3 click Download all these documents But this URL, http://www.python.org/doc/2.5.3/download/ , gives 404 NOT FOUND ERROR. -- assignee: georg.brandl components: Documentation messages: 78252 nosy: georg.brandl, quiver severity: normal status: open title: broken link for 2.5.3 doc download versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4734 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1068268] subprocess is not EINTR-safe
STINNER Victor victor.stin...@haypocalc.com added the comment: Instead of define a method for each syscall, you can write a generic function that retry at OSError(EINTR): def no_intr(self, func, *args, **kw): while True: try: return func(*args, **kw) except OSError, e: if e.errno == errno.EINTR: continue else: raise x=_waitpid_no_intr(pid, options) becomes x=no_intr(os.waitpid, pid, options). ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1068268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1068268] subprocess is not EINTR-safe
STINNER Victor victor.stin...@haypocalc.com added the comment: Oh, the new patch (subprocess-retry-on-EINTR-std-in-out-err.diff) has already a generic function (_no_intr) which is a little bit different than mine (looks like a decorator). Can you delete your old patch? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1068268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4733] Add a decode to declared encoding version of urlopen to urllib
Christian Heimes li...@cheimes.de added the comment: Thx, I'll review the patch after Christmas. -- nosy: +christian.heimes priority: - normal stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4735] An error occurred during the installation of assembly
New submission from Rodney rwpj...@comcast.net: An error occurred during the installation of assembly 'Microsoft.VC90.CRT, version=9.0.21022.8,publicKey Token=1fc8b3b9a1e18e3b,processorArchitecture=x86,type=win32. Please refer to Help and Support for more information. -- components: Installation messages: 78256 nosy: rwpjr66 severity: normal status: open title: An error occurred during the installation of assembly type: crash versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
