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
Re: [Python-Dev] Python 3.0a documentation
[EMAIL PROTECTED] schrieb: I'd like to help out cleaning up the Python3.0 documentation. There are a lot of little leftovers from 2.x that are no longer true. (mentions of long, callable() etc.) I've applied the first four patches, thank you! Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Adding concat function to itertools
On 9/22/07, Bruce Frederiksen [EMAIL PROTECTED] wrote: I've added a new function to itertools called 'concat'. This function is much like *chain*, but takes all of the iterables as a single argument. I've needed this once or twice, though my implementation was called 'starchain', in line with 'starmap'. I'm not a big fan of either name, though -- 'chainstar' and 'mapstar' are only marginally better (though it makes me want to come up with 'saw' and 'chainsaw' functions). Nor can I comment on the general applicability of such a function, other than to say that it was useful in some of my applications that utilize iterators of iterators of indeterminate length. -Kevin ___ 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] Adding concat function to itertools
On 9/22/07, Bruce Frederiksen [EMAIL PROTECTED] wrote: I've added a new function to itertools called 'concat'. This function is much like chain, but takes all of the iterables as a single argument. Thus concat(some_iterables) is logically equivalent to chain(*some_iterables); the difference being that chain(*some_iterables) results in some_iterables being fully expanded before the call to chain, while concat(some_iterables) only iterates on some_iterables as needed. This makes concat more attractive when some_iterables is either expensive to expand or infinite in length. Thus, concat(iterable) is like: def concat(iterables): for it in iterables: for element in it: yield element I've attached an updated itertoolsmodule.c file to this email with concat added to it. This was based on the 2.5.1 source. I ask that this be considered for adoption into standard python. Thanks in advance! Best thing to do is to put this up on the bug tracker (bugs.python.org) and assign it to Raymond Hettinger as itertools is his baby. -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] Summary of Tracker Issues
ACTIVITY SUMMARY (09/21/07 - 09/28/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1278 open (+16) / 11424 closed (+17) / 12702 total (+33) Open issues with patches: 415 Average duration of open issues: 680 days. Median duration of open issues: 670 days. Open Issues Breakdown open 1273 (+16) pending 5 ( +0) Issues Created Or Reopened (33) ___ pipe fd handling issues in subprocess.py on POSIX09/21/07 http://bugs.python.org/issue1187created anissen patch universal newlines doesn't identify CRLF during tell() 09/22/07 CLOSED http://bugs.python.org/issue1188created pjenvey Documentation for tp_as_number tp_as_sequence tp_as_mapping 09/22/07 CLOSED http://bugs.python.org/issue1189created amaury.forgeotdarc patch Windows rants sugestions. 09/22/07 CLOSED http://bugs.python.org/issue1190created wolfstar359 bsddb does not build with bsddb lib v3.1.09/22/07 http://bugs.python.org/issue1191created giraffedata Python 3 documents crash Firefox 09/24/07 CLOSED http://bugs.python.org/issue1192created rtmq os.system() encoding bug on Windows 09/24/07 http://bugs.python.org/issue1193created r_mosaic The reduce() documentation is lost in Python 3.0a1 09/24/07 CLOSED http://bugs.python.org/issue1194created r_mosaic Problems on Linux with Ctrl-D and Ctrl-C during raw_input09/24/07 http://bugs.python.org/issue1195created Rebecca int() documentation does not specify default radix 09/24/07 CLOSED http://bugs.python.org/issue1196created tcdelaney logging: formatter does not accept %(funcName)s properly 09/24/07 CLOSED http://bugs.python.org/issue1197created CM Test of 2to3 component auditor 09/24/07 CLOSED http://bugs.python.org/issue1198created dubois Documentation for tp_as_number... version 2.609/25/07 http://bugs.python.org/issue1199created amaury.forgeotdarc patch Allow array.array to be parsed by the t# format unit.09/25/07 http://bugs.python.org/issue1200created jyasskin Error in array concept 09/25/07 CLOSED http://bugs.python.org/issue1201created zip zlib.crc32() and adler32() return value 09/25/07 http://bugs.python.org/issue1202created arigo ctypes doesn't work on Mac with --disable-toolbox-glue 09/25/07 http://bugs.python.org/issue1203created janssen readline configuration for shared libs w/o curses dependencies 09/25/07 http://bugs.python.org/issue1204created mbeachy patch urllib fail to read URL contents, urllib2 crash Python 09/26/07 http://bugs.python.org/issue1205created cosoleto logging/__init__.py 09/26/07
Re: [Python-Dev] Decimal news
Thomas Wouters schrieb: 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 -rrevision. 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 think that the 'svnmerge block -rrevision' command should be used. Or not? Thomas ___ 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] Adding concat function to itertools
[Bruce Frederiksen] I've added a new function to itertools called 'concat'. This function is much like chain, but takes all of the iterables as a single argument. Any practical use cases or is this just a theoretical improvement? For Py2.x, I'm not willing to unnecessarily expand the module. However, for Py3k, I'm open to changing the signature for chain(). Raymond ___ 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
On 26/09/2007, Dino Viehland [EMAIL PROTECTED] wrote:
My understanding is that users can write code that uses only \n and Python
will write the
end-of-line character(s) that are appropriate for the platform when writing
to a file. That's
what I meant by uses \n for everything internally.
OK, so far so good - although I'm not *quite* sure there's a
self-consistent definition of code that only uses \n. I'll assume
you mean code that has a concept of lines, that lines never contain
anything other than text (specifically, neither \r or \n can appear in
a line, I'll punt on whether other weird stuff like form feed are
legal), and that whenever your code needs to write data to a file, it
writes lines with \n alone between them.
But if you write \r\n to a file Python completely ignores the presence of the
\r and
transforms the \n into a \r\n anyway, hence the \r\r in the resulting stream.
My last
question is simply does anyone find writing \r\r\n when the original string
contained \r\n a
useful behavior - personally I don't see how it is.
In the above model, lines can't contain \r and between lines you only
ever write \n - so where did the \r\n come from?
If you receive what you think are lines from an outside source, and
they contain \r, then you didn't sanity check your data.
If you receive a block of raw (effectively binary!) data which you
want to translate into your model, it's up to you how you cut it up
into lines.
If you read data using one of Python's text modes, it's up to you to
understand how it works.
But Guido's response makes this sound like it's a problem w/ VC++ stdio
implementation
and not something that Python is explicitly doing.
I'm not sure it's a CRT issue. Certainly the \r\n vs \n confusion
comes from the CRT - the underlying OS (just like Unix) only deals
in files as streams of bytes. But ultimately, lines are an
abstraction in your code. All the CRT (and Python) do is help (or
maybe hinder) you with the normal cases.
Anyway, it'd might be useful to have a text-mode file that you can write
\r\n to and only
get \r\n in the resulting file.
I can't comment on that, other than to say that if you better defined
the semantic model (lines, how things are encoded/decoded to files,
etc, somewhat like I tried to above) it would be more obvious what use
case this was trying to address.
But if the general sentiment is s.replace('\r', '') is the way to go we can
advice our users
of the behavior when interoperating w/ APIs that return \r\n in strings.
I'd say users of the relevant APIs need to understand how the APIs
represent lines, so that they can convert the received data to their
program's model of lines. Of course, that probably corresponds to
something like s.replace('\r','') or likely more correctly data_lines
= s.split('\r\n'). A rule of thumb that doesn't make it clear that
the concept of line has 2 different binary representations in 2
different areas (data back from APIs vs data from files) is likely to
ultimately lead to mistakes and confusion.
If you think this is bad, wait until you have to deal with Unicode
issues like what *encoding* the data is being supplied to you in.
Makes guessing newline conventions seem simple (at least to this
parochial English-speaker :-)) Although as this is IronPython, you may
already have that covered...
Paul.
PS In real life, you often just want a cheap and cheerful answer. For
that, strip out spurious \r characters may be fine.
___
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
Greg Ewing writes: 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. Agree, but I think this is a case where practicality beats purity. +1 for OSerror. ___ 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/28/07, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Greg Ewing writes: 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. Agree, but I think this is a case where practicality beats purity. +1 for OSerror. The OS is a somewhat troublesome abstraction boundary. I/O is a more general concept (and PPBP). +1 for IOError. -- --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] 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?
It might be nice to have, but will certainly come at a cost. So feel
free to try this out; at the end, we might agree that this change is
too intrusive.
2 - What should I do for the very common (taken from int_new):
static char *kwlist[] = {x, base, 0};
What's wrong with
static const char *kwlist[] = {x, base, 0};
Regards,
Martin
___
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] Adding concat function to itertools
On 28-Sep-07, at 10:45 AM, Raymond Hettinger wrote: [Bruce Frederiksen] I've added a new function to itertools called 'concat'. This function is much like chain, but takes all of the iterables as a single argument. Any practical use cases or is this just a theoretical improvement? For Py2.x, I'm not willing to unnecessarily expand the module. However, for Py3k, I'm open to changing the signature for chain(). For me, a fraction of chain() uses are of the * variety: d = defaultdict(list) allvals = chain(*d.values()) return chain(*imap(cache.__getitem__, keylist)) Interestingly, they seem to all have something to do with dictionary values() that are themselves iterable. -Mike ___ 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] Adding concat function to itertools
[Bruce Frederiksen] I've added a new function to itertools called 'concat'. This function is much like chain, but takes all of the iterables as a single argument. [Raymond] Any practical use cases or is this just a theoretical improvement? For Py2.x, I'm not willing to unnecessarily expand the module. However, for Py3k, I'm open to changing the signature for chain(). [Bruce] For me, a fraction of chain() uses are of the * variety: d = defaultdict(list) allvals = chain(*d.values()) return chain(*imap(cache.__getitem__, keylist)) Interestingly, they seem to all have something to do with dictionary values() that are themselves iterable. I see. These are instances of a recurring general use case of chain() as a one-level flattener. Will give consideration to changing the signature of chain() for Py3.0. Besides the concat() variation using a single iterable input, another alternative is the min()/max() style signature where one input is interpreted as iterable and multiple arguments as comprising an input tuple. Raymond ___ 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] Adding concat function to itertools
On Fri, 28 Sep 2007, Raymond Hettinger wrote: Interestingly, they seem to all have something to do with dictionary values() that are themselves iterable. I see. These are instances of a recurring general use case of chain() as a one-level flattener. Will give consideration to changing the signature of chain() for Py3.0. Besides the concat() variation using a single iterable input, another alternative is the min()/max() style signature where one input is interpreted as iterable and multiple arguments as comprising an input tuple. Has anyone considered making the iterator __add__ operator perform something similar to chain? I.e. list(a + b) = [ a0, a1, ... an, b0, b1, bn] (where a and b are iterables) -d ___ 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/28/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 9/28/07, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Greg Ewing writes: 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. Agree, but I think this is a case where practicality beats purity. +1 for OSerror. The OS is a somewhat troublesome abstraction boundary. I/O is a more general concept (and PPBP). +1 for IOError. What is PPBP? -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
Re: [Python-Dev] Adding concat function to itertools
Bruce Frederiksen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A 64K attachment. Please do not do such a worse-than-useless thing again. Especially when only 1K is original. ___ 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/28/07, Brett Cannon [EMAIL PROTECTED] wrote: On 9/28/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 9/28/07, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Greg Ewing writes: 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. Agree, but I think this is a case where practicality beats purity. +1 for OSerror. The OS is a somewhat troublesome abstraction boundary. I/O is a more general concept (and PPBP). +1 for IOError. What is PPBP? Typo for PBP : Practicality Beats Purity. :) -- --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
