Re: [Python-3000] canonicalization [was: On PEP 3116: new I/O base classes]

> Counter-proposal: normalization is provided as library functionality. > Applications are responsible for normalization data when they need it > to be normalized and they can't be sure that it isn't already > normalized. The source parser used by import and a few other places is > an "application"

Re: [Python-3000] canonicalization [was: On PEP 3116: new I/O base classes]

On 6/21/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > Should canonicalization should be an extra feature of the Text IO, on > par with character encoding? > > On 6/20/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: > > On 6/20/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > [For the TextIO, as oppose

Re: [Python-3000] On PEP 3116: new I/O base classes

On 6/21/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: > On 6/21/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > In my mind, seek() and tell() should work like getpos() and setpos() > > in modern C stdio -- tell() returns a "cookie" whose only use is that > > you can later pass it to seek() an

Re: [Python-3000] On PEP 3116: new I/O base classes

On 6/21/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > In my mind, seek() and tell() should work like getpos() and setpos() > in modern C stdio -- tell() returns a "cookie" whose only use is that > you can later pass it to seek() and it will reset the position in the > sequence of code units to

Re: [Python-3000] Python 3000 Status Update (Long!)

Bill Janssen wrote: > It should be > > sum(*operands) That would incur copying of the sequence. It would be justifiable only if the vast majority of use cases involved passing the operands as separate arguments, which I don't think is true. -- Greg _

Re: [Python-3000] Python 3000 Status Update (Long!)

Andrew McNabb wrote: > I think you're technically right, but I frequently find myself using the > phrase "add together a list of strings" when it would be more accurate > to say "concatenate a list of strings." The word "add" has a wider connotation in English than "sum". Consider the following tw

Re: [Python-3000] On PEP 3116: new I/O base classes

On 6/20/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > > TextIOBase: this seems an odd mix of high-level and low-level. I'd > > > remove "seek", "tell", "read", and "write". Remember that in Python, > > > mixins actually work, so that you can provide a file object that > > > combines several dif

Re: [Python-3000] Python 3000 Status Update (Long!)

Steve Howell wrote: > --- Ron Adam <[EMAIL PROTECTED]> wrote: > >> >> Bill Janssen wrote: I think you were missing my point, which is that >> sum doesn't and shouldn't necessarily have the same semantics as map(+). >>> It's not that I don't understand your argument, >> Steve. >>>

Re: [Python-3000] Python 3000 Status Update (Long!)

> > It should amount to "map(+, operands)". > > Or, to be pedantic, this: > > reduce(lambda x, y: x.__add__(y), operands) Don't you mean: reduce(lambda x, y: x.__add__(y), operands[1:], operands[0]) Bill ___ Python-3000 mailing list Python-3

Re: [Python-3000] join vs. add [was: Python 3000 Status Update (Long!)]

On Thursday 21 June 2007, Joel Bender wrote: > I think this is clearer than sum(): > >>> join(['a', 'b', 'c']) > 'abc' > > It wouldn't interfere with ''.join(), and ''.__add__() could be > redirected to ''.__join__(). And then int.__join__ could be defined in confusing ways, too:

Re: [Python-3000] join vs. add [was: Python 3000 Status Update (Long!)]

> My preference would be to limit sum() to value addition only, and never do > concatenation. I would be happy with that, provided there was join function and operator: >>> join = lambda x: reduce(lambda y, z: y.__join__(z), x) I think this is clearer than sum(): >>> join(['a', 'b',

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Ron Adam <[EMAIL PROTECTED]> wrote: > > > Bill Janssen wrote: > >> I think you were missing my point, which is that > sum > >> doesn't and shouldn't necessarily have the same > >> semantics as map(+). > > > > It's not that I don't understand your argument, > Steve. > > > > I just don't fi

Re: [Python-3000] Python 3000 Status Update (Long!)

Bill Janssen wrote: >> I think you were missing my point, which is that sum >> doesn't and shouldn't necessarily have the same >> semantics as map(+). > > It's not that I don't understand your argument, Steve. > > I just don't find it effective. If we are going to distinguish > between "arithm

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Andrew McNabb <[EMAIL PROTECTED]> wrote: > > I agree that on its own, it's not the most natural > method. However, > once you've already used the + operator to join two > strings, you are > much more likely to consider sum() for concatenating > a list of strings. > I remember being confused

Re: [Python-3000] Python 3000 Status Update (Long!)

On Thu, Jun 21, 2007 at 10:33:41AM -0700, Steve Howell wrote: > > Nope, and I wouldn't throw the grammar book at you if you did. But if > you said a compound word is a "sum" of smaller words, I might look at > you a little funny. :) It wouldn't be the first time someone looked at me a little fu

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Bill Janssen <[EMAIL PROTECTED]> wrote: > > My other concern with sum() is just the common > pitfall > > that you do sum(line_of_numbers.split(',')) and > get > > '35' when you intended to write code to get 8. > I'd > > rather have that fail obviously than subtlely. > > Common pitfall? I

Re: [Python-3000] Python 3000 Status Update (Long!)

> I think you were missing my point, which is that sum > doesn't and shouldn't necessarily have the same > semantics as map(+). It's not that I don't understand your argument, Steve. I just don't find it effective. If we are going to distinguish between "arithmetic addition" and "concatenation",

Re: [Python-3000] Python 3000 Status Update (Long!)

> It should be > > sum(*operands) > > not > > sum(operands, initialvalue=?) > > It should amount to "map(+, operands)". Or, to be pedantic, this: reduce(lambda x, y: x.__add__(y), operands) Joel ___ Python-3000 mailing list Python-3000@p

Re: [Python-3000] Python 3000 Status Update (Long!)

> My other concern with sum() is just the common pitfall > that you do sum(line_of_numbers.split(',')) and get > '35' when you intended to write code to get 8. I'd > rather have that fail obviously than subtlely. Common pitfall? I doubt it. Possible pitfall? Sure. Bill __

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Andrew McNabb <[EMAIL PROTECTED]> wrote: > > I think you're technically right, but I frequently > find myself using the > phrase "add together a list of strings" when it > would be more accurate > to say "concatenate a list of strings." I can't say > I feel bad when I > use this terminology

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/21/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > The real problem with "sum", I think, is that the parameter list is > ill-conceived (perhaps because it was added before variable length > parameter lists were?). It should be > sum(*operands) > not > sum(operands, initialvalue=?) Is th

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Bill Janssen <[EMAIL PROTECTED]> wrote: > > Multiple additions (with "+") mean "sum" in > > arithmetic, but you can't generalize that to > strings > > and text processing. The "+" operator for any two > > strings is not about adding--it's about > > joining/concatenating. So multiple applica

Re: [Python-3000] Python 3000 Status Update (Long!)

> Multiple additions (with "+") mean "sum" in > arithmetic, but you can't generalize that to strings > and text processing. The "+" operator for any two > strings is not about adding--it's about > joining/concatenating. So multiple applications of > "+" on strings aren't a sum. They're just a lo

Re: [Python-3000] Python 3000 Status Update (Long!)

On Thu, Jun 21, 2007 at 02:49:46AM -0700, Steve Howell wrote: > > "Sum" should sum stuff. You can't sum strings. It makes no sense in > English. I think you're technically right, but I frequently find myself using the phrase "add together a list of strings" when it would be more accurate to say

[Python-3000] canonicalization [was: On PEP 3116: new I/O base classes]

Should canonicalization should be an extra feature of the Text IO, on par with character encoding? On 6/20/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: > On 6/20/07, Bill Janssen <[EMAIL PROTECTED]> wrote: [For the TextIO, as opposed to the raw IO, Bill originally proposed dropping read(n), be

Re: [Python-3000] Python 3000 Status Update (Long!)

Gareth McCaughan wrote: > That is: if you're writing code that expects sum() to do something > sensible with lists of strings, you'll usually need it to do something > sensible with *empty* lists of strings -- but that isn't possible, > because there's only one empty list and it has to serve as the

Re: [Python-3000] Python 3000 Status Update (Long!)

Thomas Wouters wrote: > > > On 6/20/07, *Nick Coghlan* <[EMAIL PROTECTED] > > wrote: > > Strings are explicitly disallowed (because Guido doesn't want a second > way to spell ''.join(seq), as far as I know): > > > More importantly, because it has positively a

Re: [Python-3000] Python 3000 Status Update (Long!)

--- Bill Janssen <[EMAIL PROTECTED]> wrote: > [...] It's more important to make things work > consistently than to only > have "one way". "sum" should concatenate strings. > "Sum" should sum stuff. You can't sum strings. It makes no sense in English. You can concatenate strings, or you can