Mailman 3 September 2007 - Python-Dev

OpenSSL httplib bug
by Richie Ward Oct. 2, 2007

Oct. 2, 2007

I was using httplib to power my xml rpc script. I had problems when I wanted to use SSL and I got this error: File "/usr/lib/python2.5/httplib.py", line 1109, in recv return self._ssl.read(len) socket.sslerror: (8, 'EOF occurred in violation of protocol') I figured out this was because of poor error handling in python. May I suggest this as a fix to this bug: $ diff /usr/lib/python2.5/httplib.py /usr/lib/python2.5/httplib.py~ 1109,1112c1109 < try: < return … [View More]

3 2

building with -Wwrite-strings
by Lisandro Dalcin Oct. 1, 2007

Oct. 1, 2007

I'm trying to build Python (2.6) with GCC the option -Wwrite-strings. 1 - Is there any interest on this? 2 - What should I do for the very common (taken from int_new): static char *kwlist[] = {"x", "base", 0}; I was able to remove all the warning in Objects/*, except those related to (2). -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de … [View More]

3 3

New lines, carriage returns, and Windows
by Dino Viehland Oct. 1, 2007

Oct. 1, 2007

We ran into an interesting user-reported issue w/ IronPython and the way Python writes to files and I thought I'd get python-dev's opinion. When writing a string in text mode that contains \r\n we both write \r\r\n because the default write mode is to replace \n with \r\n. This works great as long as you stay within an entirely Python world. Because Python uses \n for everything internally you'll never end up writing out a \r\n that gets transformed into a \r\r\n. But when interoperating … [View More]

7 16

Re: [Python-Dev] New lines, carriage returns, and Windows
by Nick Maclaren Oct. 1, 2007

Oct. 1, 2007

Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > > I don't see how this is different from Unix/C "\n" being > an atomic newline character. Have you used systems with the I/O models I referred to (or ones with newlines being out-of-bound data)? > If you're saying that BCPL is better because it defines > standard semantics for more control characters than just > "\n", that may be true, but C is doing about the best it > can with "\n" as far as I can see, given all … [View More]

2 1

Re: [Python-Dev] [python] Re: New lines, carriage returns, and Windows
by Nick Maclaren Oct. 1, 2007

Oct. 1, 2007

Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > > > Grrk. That's the problem. You don't get back what you have written > > You do as long as you *don't* use universal newlines mode > for reading. This is the best that can be done, because > universal newlines are inherently ambiguous. I don't know PRECISELY what you mean by "universal newlines mode", and this issue is all about the details, so any response would merely enhance the confusion. > If you want … [View More]

2 1

Re: [Python-Dev] [python] Re: New lines, carriage returns, and Windows
by Nick Maclaren Sept. 30, 2007

Sept. 30, 2007

Michael Foord <fuzzyman(a)voidspace.org.uk> wrote: > skip(a)pobox.com wrote: > > > Michael> Actually, I usually get these strings from Windows UI > > Michael> components. A file containing '\r\n' is read in with '\r\n' > > Michael> being translated to '\n'. New user input is added containing > > Michael> '\r\n' line endings. The file is written out and now contains a > > Michael> mix of '\r\n' and '\r\r\n'. > > … [View More]

1 0

Re: [Python-Dev] New lines, carriage returns, and Windows
by Nick Maclaren Sept. 30, 2007

Sept. 30, 2007

skip(a)pobox.com wrote: > > I've been thinking about this some more (in lieu of actually writing up any > sort of proposal ;-) and I'm not so sure it would be all that useful. If > you've opened a file in text mode you should only be writing newlines as > '\n' anyway. If you want to translate a text file imported from another > system to use the current system's line ending just open both the input and > output files in text mode. I.e. at least \r, \f and \v are … [View More]

1 0

Re: [Python-Dev] New lines, carriage returns, and Windows
by Nick Maclaren Sept. 30, 2007

Sept. 30, 2007

"Guido van Rossum" <guido(a)python.org> wrote: > > Have you looked at Py3k at all, especially PEP 3116 (new I/O)? No. > Python *does* have its own I/O model. There are binary files and text > files. For binary files, you write bytes and the semantic model is > that of an array of bytes; byte indices are seek positions. That is the same model as C and Unix. It is text files that we are discussing. > For text files, the contents is considered to be Unicode, encoded … [View More]as > bytes in a binary file. So text file always has an underlying binary > file. Two translations take place, both of which have defaults varying > by platform. One translation is encoding Unicode text into bytes upon > output, and decoding bytes to Unicode text upon input. This can use > any encoding supported by the encodings package. The character code isn't the issue here, and is almost completely irrelevant. > The other translation deals with line endings. Upon input, any of > \r\n, \r, or \n is translated to a single \n by default (this is nhe > "universal newlines" algorithm from Python 2.x). This can be tweaked > or disabled. Upon output, \n is translated into a platform specific > string chosen from \r\n, \r, or \n. This can also be disabled or > overridden. Note that \r, when written, is never treated specially; if > you want special processing for \r on output, you can write your own > translation layer. Grrk. That's the problem. You don't get back what you have written, for a start, which isn't nice. There are other issues, too. > That's all. There is nothing unimplementable or confusing in these > specifications. Nothing unimplementable, I agree. Nothing confusing? Not in the experience of the users I have dealt with. > Python doesn't care about record I/O on legacy OSes; it does care > about variability found in practice between popular OSes. As a short-term solution, that is fine. But I have seen the wheel turn a couple of times in 40 years, and expect it to continue after I am safely 6' under .... > Note that \r, \n and friends in Python 3000 are either ASCII (in bytes > literals) or Unicode (in text literals). Again, no support for legacy > systems that don't use ASCII or a superset. That's not a problem. I don't see that changing in the forseeable future. > Legacy OSes are called that for a reason. Well, I remember when the text I/O model that C, Unix and Python use WAS a feature of legacy OSs :-) Seriously. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679 [View Less]

2 1

Decimal news
by Facundo Batista Sept. 29, 2007

Sept. 29, 2007

Hi people! After some months, Decimal is now in the trunk again. It's fully updated to the latest Cowlishaw specification, and complying with the latest test cases (from a few days ago, which even take in consideration some feedback from ours). I want to thank so much to Mark Dickinson, who made *a lot* of this work, not only the math part (he's a mathematician himself), but also a lot of cleaning and speeding up. Now we will put our hands in the documentation, for it to be 100% OK way … [View More]

5 9

urllib exception compatibility
by Jim Jewett Sept. 29, 2007

Sept. 29, 2007

urllib goes to goes to some trouble to ensure that it raises IOError, even when the underlying exception comes from another module.[*] I'm wondering if it would make sense to just have those modules' exceptions inherit from IOError. In particular, should socket.error, ftp.Error and httplib.HTTPException (used in Py3K) inherit from IOError? I'm also wondering whether it would be acceptable to change the details of the exceptions. For example, could raise IOError, ('ftp error', … [View More]

9 17