Re: [Python-Dev] urllib exception compatibility
How about making IOError, OSError and EnvironmentError all aliases for the same thing? The distinction is really worthless historical baggage. On 9/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Jim Jewett wrote: > > In particular, should socket.error, ftp.Error and > > httplib.HTTPException (used in Py3K) inherit from IOError? > > I'd say that if they incorporate a C library result code they > should inherit from IOError, or if they incorporate a system > call result code they should inherit from OSError. Otherwise > they should inherit from EnvironmentError. > > I don't think there's any point in simply catching one of > these and re-wrapping it in the library's own exeption > class, but if such wrapping is done, it should inherit > from EnvironmentError as well. > > It's convenient to be able to catch EnvironmentError and > get anything that is caused by circumstances outside the > program's control. > > -- > Greg Ewing, Computer Science Dept, +--+ > University of Canterbury, | Carpe post meridiem! | > Christchurch, New Zealand | (I'm not a morning person.) | > [EMAIL PROTECTED]+--+ > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New lines, carriage returns, and Windows
> This I don't understand. Why don't you just use binary mode then? > At least for Python 2.x, the *only* difference between text and > binary mode is the treatment of line endings. That just flips the problem to the other side. Now if I have a Python library that I'm mixing w/ .NET code I need to be sure to transform the line endings, but now from \n -> \r\n (and hopefully they'd detect the new-line style they should use so it works correctly on Mono on *nix or Silverlight on OS X as well). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New lines, carriage returns, and Windows
[moving to python-3000]
The symmetry isn't as strong as you suggest, but I agree it would be a
useful feature. Would you mind filing a Py3k feature request so we
don't forget?
A proposal for an API given the existing newlines=... parameter
(described in detail in PEP 3116) would be even better.
And a patch would be best, but you know that. :-)
--Guido
On 9/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Greg> Maybe there should be a universal newlines mode defined for output
> Greg> as well as input, which translates any of "\r", "\n" or "\r\n"
> Greg> into the platform line ending.
>
> I thought that's the way it was supposed to work, but it clearly doesn't:
>
> >>> f = open("test.txt", "wt")
> >>> f.write("a\rb\rnc\n")
> 7
> >>> f.close()
> >>> open("test.txt", "rb").read()
> b'a\rb\rnc\n'
>
> I'd be open to such a change. Principle of least surprise?
>
> Skip
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
On 9/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > How about making IOError, OSError and EnvironmentError all aliases for > the same thing? The distinction is really worthless historical > baggage. > +1 on that. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
On 9/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > How about making IOError, OSError and EnvironmentError all aliases for > the same thing? The distinction is really worthless historical > baggage. > +1 from me. Should OSError and IOError become aliases to EnvironmentError? I assume WindowsError and VMSError will just directly subclass which ever exception sticks around. And should we bother with a PendingDeprecationWarning for IOError or OSError? Or just have a Py3K warning for them and not worry about their removal in the 2.x series and just let 2to3 handle the transition? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] building with -Wwrite-strings
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 Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
On 27 Sep 2007, 21:23:58, Brett Cannon wrote: > Should OSError and IOError become aliases to EnvironmentError? I > assume WindowsError and VMSError will just directly subclass which > ever exception sticks around. > > And should we bother with a PendingDeprecationWarning for IOError or > OSError? Or just have a Py3K warning for them and not worry about > their removal in the 2.x series and just let 2to3 handle the > transition? Am I missing something, as I thought Py2K was supposed to throw backwards compatability to the wind in favor of doing the "Right Thing"? If so, can't we lose the proposed OSError and IOError aliases altogether, and just keep EnvironmentError? Perhaps "EnvironmentError" is a bit long to type in all the places OSError and IOError are used, I personally like the look of OSError and IOError better in my code. I vote for a shorter name for EnvironmentError, e.g. EMError. just my 2c, Graham > > -Brett > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/graham.horler%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
I'd be happy to make them all IOError. 2to3 can clean this up. On 9/27/07, Graham Horler <[EMAIL PROTECTED]> wrote: > On 27 Sep 2007, 21:23:58, Brett Cannon wrote: > > Should OSError and IOError become aliases to EnvironmentError? I > > assume WindowsError and VMSError will just directly subclass which > > ever exception sticks around. > > > > And should we bother with a PendingDeprecationWarning for IOError or > > OSError? Or just have a Py3K warning for them and not worry about > > their removal in the 2.x series and just let 2to3 handle the > > transition? > > Am I missing something, as I thought Py2K was supposed to throw backwards > compatability to the wind in favor of doing the "Right Thing"? > > If so, can't we lose the proposed OSError and IOError aliases altogether, > and just keep EnvironmentError? > > Perhaps "EnvironmentError" is a bit long to type in all the places OSError > and IOError are used, I personally like the look of OSError and IOError better > in my code. I vote for a shorter name for EnvironmentError, e.g. EMError. > > just my 2c, Graham > > > > > -Brett > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/graham.horler%40gmail.com > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
On 9/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > How about making IOError, OSError and EnvironmentError all aliases for > the same thing? The distinction is really worthless historical > baggage. Wouldn't it also be nice to have some subclasses of IOError like FileNotFoundError, IOPermissionError and EOFError? Often that would be easier than having to use the errno attribute to find out the exact cause. -- mvh Björn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal news
Thomas Wouters wrote: > Unfortunately, that's not how it works :-) If you check something into > the trunk, it will be merged into Py3k sooner or later. I may ask the > original submitter for assistance if it's incredibly hard to figure out > the changes, but so far, I only had to do that with the SSL changes. The > decimal changes are being merged as I write this (tests running now.) Is > there anything in particular that needs to be done for decimal in Py3k, > besides renaming __div__ to __truediv__? > > If you re-eally need to check something into the trunk that re-eally > must not be merged into py3k, but you're afraid it's not going to be > obvious to the merger, please record the change as 'merged' using > "svnmerge merge -M -r". Please take care when picking the > revision ;) You can also just email me or someone else you see doing > merges, as I doubt this will be a common occurance. I'm getting ready to port my PEP 3101 implementation (str.format() and friends) from py3k back to 2.6. How do I make it obvious that this is something that doesn't need to be ported to py3k? I'm not sure what "obvious to the merger" means. Is a "backported" checkin comment good enough? With any luck this will be done with a single checkin to the trunk, and another checkin to py3k so that the implementations can remain identical. I just want to make sure I don't make life more difficult than necessary for the folks doing the very valuable merge process. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New lines, carriage returns, and Windows
Dino Viehland wrote: >>Why don't you just use binary mode then? > > That just flips the problem to the other side. Seems to me that IronPython really needs two string types, "Python string" and ".NET string", with automatic conversion when crossing a boundary between Python code and .NET code. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal news
On 9/27/07, Eric Smith <[EMAIL PROTECTED]> wrote: > > Thomas Wouters wrote: > > > Unfortunately, that's not how it works :-) If you check something into > > the trunk, it will be merged into Py3k sooner or later. I may ask the > > original submitter for assistance if it's incredibly hard to figure out > > the changes, but so far, I only had to do that with the SSL changes. The > > decimal changes are being merged as I write this (tests running now.) Is > > there anything in particular that needs to be done for decimal in Py3k, > > besides renaming __div__ to __truediv__? > > > > If you re-eally need to check something into the trunk that re-eally > > must not be merged into py3k, but you're afraid it's not going to be > > obvious to the merger, please record the change as 'merged' using > > "svnmerge merge -M -r". Please take care when picking the > > revision ;) You can also just email me or someone else you see doing > > merges, as I doubt this will be a common occurance. > > I'm getting ready to port my PEP 3101 implementation (str.format() and > friends) from py3k back to 2.6. How do I make it obvious that this is > something that doesn't need to be ported to py3k? I'm not sure what > "obvious to the merger" means. Is a "backported" checkin comment good > enough? With any luck this will be done with a single checkin to the > trunk, and another checkin to py3k so that the implementations can > remain identical. Funny, just a few hours ago Guido mentioned we (meaning I) should write this up in a PEP :) I'll do that in the next few weeks. Obvious to the merger means whatever the merger expects it to mean ;) Yes, checkin comments are good. If an automatic merge fails, and the code isn't straightforward to merge from just looking at the files, looking at the actual changes in both branches is the next step. If the comment says 'backport from py3k' (preferably with which version was backported), that makes it easy to ignore the whole change (but perhaps not later checkins.) After you backport, maintenance should be done in the trunk, not the py3k branch (except of course, for parts that don't apply to the trunk.) I just want to make sure I don't make life more difficult than necessary > for the folks doing the very valuable merge process. As long as you commit any given thing only once, it's pretty easy to work out. As soon as you find yourself (more than once) committing things to py3k and then realizing it should go to the trunk, you may be making life harder. I appreciate that you're careful about this though, thanks :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
I suspect that the use case for those errors is far less than you think. On 9/27/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > On 9/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > How about making IOError, OSError and EnvironmentError all aliases for > > the same thing? The distinction is really worthless historical > > baggage. > > Wouldn't it also be nice to have some subclasses of IOError like > FileNotFoundError, IOPermissionError and EOFError? Often that would be > easier than having to use the errno attribute to find out the exact > cause. > > -- > mvh Björn > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
Guido van Rossum wrote: > How about making IOError, OSError and EnvironmentError all aliases for > the same thing? The distinction is really worthless historical > baggage. To my mind, the distinction is that IOError and OSError have an attribute for the error code, and the code found there has a well-defined meaning (C library error code and system call error code respectively), whereas EnvironmentError is more general. While it might be possible to merge them all together on Unix-like systems, that wouldn't necessarily be true on all platforms -- the IOError and OSError codes might belong to different domains. Although I suppose you could have another attribute to distinguish them if necessary. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
Is IOError is the right name to use? OSError is raised for things that are not IO such as subprocess, dlopen, system. Nobody likes typing out EnvironmentError and dislike the suggestion of EMError, should it just be OSError? errno values are after all OS specific. -gps On 9/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I'd be happy to make them all IOError. 2to3 can clean this up. > > On 9/27/07, Graham Horler <[EMAIL PROTECTED]> wrote: > > On 27 Sep 2007, 21:23:58, Brett Cannon wrote: > > > Should OSError and IOError become aliases to EnvironmentError? I > > > assume WindowsError and VMSError will just directly subclass which > > > ever exception sticks around. > > > > > > And should we bother with a PendingDeprecationWarning for IOError or > > > OSError? Or just have a Py3K warning for them and not worry about > > > their removal in the 2.x series and just let 2to3 handle the > > > transition? > > > > Am I missing something, as I thought Py2K was supposed to throw > backwards > > compatability to the wind in favor of doing the "Right Thing"? > > > > If so, can't we lose the proposed OSError and IOError aliases > altogether, > > and just keep EnvironmentError? > > > > Perhaps "EnvironmentError" is a bit long to type in all the places > OSError > > and IOError are used, I personally like the look of OSError and IOError > better > > in my code. I vote for a shorter name for EnvironmentError, e.g. > EMError. > > > > just my 2c, Graham > > > > > > > > -Brett > > > ___ > > > Python-Dev mailing list > > > Python-Dev@python.org > > > http://mail.python.org/mailman/listinfo/python-dev > > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/graham.horler%40gmail.com > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
Gregory P. Smith wrote: > Is IOError is the right name to use? OSError is raised for things that > are not IO such as subprocess, dlopen, system. The trouble with either of these is that the class of errors we're talking about don't necessarily come directly from the OS or I/O library. Often I raise my own EnvironmentError instances for things which don't have any associated OS error code but are nonetheless environment-related, such as an error in a file format. I don't reuse IOError or OSError because I feel as though I ought to supply an errno with these, but there isn't any. I suppose we could pick one of these and make it official that it's okay to instantiate it without an errno. But it's hard to decide which one, because they both sound too narrow in scope. I don't like EMError either, btw. Maybe EnvError? Although that sounds like it has something to do with the unix environment variables. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib exception compatibility
On 9/27/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Gregory P. Smith wrote: > > Is IOError is the right name to use? OSError is raised for things that > > are not IO such as subprocess, dlopen, system. > > The trouble with either of these is that the class > of errors we're talking about don't necessarily come > directly from the OS or I/O library. > > Often I raise my own EnvironmentError instances for > things which don't have any associated OS error code > but are nonetheless environment-related, such as an > error in a file format. > > I don't reuse IOError or OSError because I feel as > though I ought to supply an errno with these, but > there isn't any. > > I suppose we could pick one of these and make it > official that it's okay to instantiate it without > an errno. But it's hard to decide which one, > because they both sound too narrow in scope. > > I don't like EMError either, btw. Maybe EnvError? > Although that sounds like it has something to do > with the unix environment variables. ExternalError? Pretty vague though. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
