Why doesn't join() call str() on its arguments?

[Leo Breebaart]

I've tried Googling for this, but practically all discussions on
str.join() focus on the yuck-ugly-shouldn't-it-be-a-list-method?
issue, which is not my problem/question at all.

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.

All I've been able to find is a 1999 python-dev post by Tim
Peters which would seem to indicate he doesn't understand it
either:

"string.join(seq) doesn't currently convert seq elements to
string type, and in my vision it would. At least three of us
admit to mapping str across seq anyway before calling
string.join, and I think it would be a nice convenience
[...]"

But now it's 2005, and both string.join() and str.join() still
explicitly expect a sequence of strings rather than a sequence of
stringifiable objects.

I'm not complaining as such -- sep.join(str(i) for i in seq) is
not *that* ugly, but what annoys me is that I don't understand
*why* this was never changed. Presumably there is some
counter-argument involved, some reason why people preferred the
existing semantics after all. But for the life of me I can't
think what that counter-argument might be...

--
Leo Breebaart <le*@lspace.org>

[Jeff Shannon]

Leo Breebaart wrote:

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments [...] [...] Presumably there is some
counter-argument involved, some reason why people preferred the
existing semantics after all. But for the life of me I can't
think what that counter-argument might be...

One possibility I can think of would be Unicode. I don't think that
implicitly calling str() on Unicode strings is desirable. (But then
again, I know embarrassingly little about unicode, so this may or may
not be a valid concern.)

Of course, one could ensure that unicode.join() used unicode() and
str.join() used str(), but I can conceive of the possibility of
wanting to use a plain-string separator to join a list that might
include unicode strings. Whether this is a realistic use-case is, of
course, a completely different question...

Jeff Shannon
Technician/Programmer
Credit International

[Fredrik Lundh]

Jeff Shannon wrote:

One possibility I can think of would be Unicode. I don't think that implicitly calling str() on
Unicode strings is desirable.
it's not. but you could make an exception for basestring types.
Of course, one could ensure that unicode.join() used unicode() and str.join() used str(), but I
can conceive of the possibility of wanting to use a plain-string separator to join a list that
might include unicode strings.
yes.
Whether this is a realistic use-case

it is. mixing 8-bit ascii strings with unicode works perfectly fine, and is a good
way to keep memory use down in programs that uses ascii in most cases (or
for most strings), but still needs to support non-ascii text.

I've proposed adding a "join" built-in that knows about the available string types,
and does the right thing for non-string objects. unfortunately, the current crop of
py-dev:ers don't seem to use strings much, so they prioritized really important stuff
like sum() and reversed() instead...

</F>

[Aahz]

In article <ma***************************************@python. org>,
Fredrik Lundh <fr*****@pythonware.com> wrote:

I've proposed adding a "join" built-in that knows about the available
string types, and does the right thing for non-string objects.
unfortunately, the current crop of py-dev:ers don't seem to use strings
much, so they prioritized really important stuff like sum() and
reversed() instead...

You know where the patch tracker is.... ;-)
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR

[Steven Bethard]

Leo Breebaart wrote:

I'm not complaining as such -- sep.join(str(i) for i in seq) is
not *that* ugly, but what annoys me is that I don't understand
*why* this was never changed.

py> chars = [u'ä', u'å']
py> ', '.join(chars)
u'\xe4, \xe5'
py> ', '.join(str(c) for c in chars)
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "<interactive input>", line 1, in <generator expression>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in
position 0: ordinal not in range(128)
py> u', '.join(chars)
u'\xe4, \xe5'
py> u', '.join(unicode(c) for c in chars)
u'\xe4, \xe5'

Currently, str.join will return a unicode object if any of the items to
be joined are unicode. That means that str.join accepts unicode objects
as well as str objects. So you couldn't just call str on all the objects...

Maybe you could call str or unicode on each object as appropriate
though... If str.join already determines that it must return a unicode
object, it could call unicode on all the items instead of str... I
don't know the code well enough though to know if this is feasible...

STeVe

[Skip Montanaro]

John> 4. For consistency, would you like "1" + 2 to produce "12"?

No, the correct answer is obviously 3. ;-)

S

[John Machin]

On 16 Feb 2005 18:47:21 GMT, Leo Breebaart <le*@lspace.org> wrote:

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.

For a start, I think you meant ''.join([1,2,4,5]) to yield "1245".

Secondly, concatenating arbitrary types with a null separator doesn't
appear to be a good use case.
E.g.

''.join([str(x) for x in [1,2,1./3,4]])

'120.3333333333334'

Some possible explanations:

1. Explicit is better than implicit.
2. It would only be a good "trick" IMHO with a non-null separator and
types with a 'clean' str() result (unlike float) -- like int; I can't
think of more at the moment.
3. It would be one step on the slippery downwards path to perlishness.
4. For consistency, would you like "1" + 2 to produce "12"?

[Leo Breebaart]

John Machin <sj******@lexicon.net> writes:

On 16 Feb 2005 18:47:21 GMT, Leo Breebaart <le*@lspace.org> wrote:

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.
For a start, I think you meant ''.join([1,2,4,5]) to yield
"1245".

Yep. Sorry. Bad example.

Secondly, concatenating arbitrary types with a null separator doesn't
appear to be a good use case.
E.g.

''.join([str(x) for x in [1,2,1./3,4]]) '120.3333333333334'
Okay:

', '.join(str(x) for x in [1,2,1./3,4])

'1, 2, 0.333333333333, 4'

Isn't that better?

I am not claiming that *all* uses of calling join() on arbitrary
types are useful. But then neither are *all* uses of calling
join() on actual strings, or all uses of adding arbitrarily typed
elements to a list, or...

It's just that in my experience so far, whenever I have felt a
need for the 'join()' function, it has *always* been in a
situation where I also have to do the str(x) thing. That suggests
to me an "obvious default" of the kind that exists elsewhere in
Python as well.

It is entirely possible that my experience is not shared (or not
to the same extent) by others, but part of my reason for asking
this question here is investigating precisely that.

Some possible explanations:

1. Explicit is better than implicit.
Sure. But it's always a tradeoff -- list comprehensions are more
implicit than for loops...

2. It would only be a good "trick" IMHO with a non-null
separator and types with a 'clean' str() result (unlike float)
-- like int; I can't think of more at the moment.
I don't agree that the str() result for a float isn't clean.
Sometimes it can be exactly what you need, or even just
sufficient. If you want more control, then pure join() isn't what
you need, anyway. Right?

3. It would be one step on the slippery downwards path to
perlishness.
I think you're exaggerating, and I really would prefer to have
this discussion without gratuitous swipes against other
languages, please?

4. For consistency, would you like "1" + 2 to produce "12"?

No. A foolish consistency etc. etc. I sincerely do like the fact
that Python does not try to second-guess the programmer, I do
value explicit over implicit, and I have no desire to open the
can of worms that would be the changing the semantics of +.
I think my main dissatisfaction with your four possible
explanations stems from the fact that a join() function that
would be a bit more type-agnostic strikes me as *more* Pythonic,
not *less*. Isn't that what duck typing is about? Why does join()
care that its arguments should be actual strings only? If the
function of join() is to produce a string, why isn't it
sufficient for its arguments to have a string representation --
why do they have to *be* strings? Isn't that sort of thing
exactly how we are taught *not* to write our own argument
handling when we learn Python?

--
Leo Breebaart <le*@lspace.org>

[Thomas Heller]

Skip Montanaro <sk**@pobox.com> writes:

John> 4. For consistency, would you like "1" + 2 to produce "12"?

No, the correct answer is obviously 3. ;-)

S

No, '"1"2' is correct. Or '"1"+2'.

[John Roth]

"Leo Breebaart" <le*@lspace.org> wrote in message
news:37*************@individual.net...

I've tried Googling for this, but practically all discussions on
str.join() focus on the yuck-ugly-shouldn't-it-be-a-list-method?
issue, which is not my problem/question at all.

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.

All I've been able to find is a 1999 python-dev post by Tim
Peters which would seem to indicate he doesn't understand it
either:

"string.join(seq) doesn't currently convert seq elements to
string type, and in my vision it would. At least three of us
admit to mapping str across seq anyway before calling
string.join, and I think it would be a nice convenience
[...]"

But now it's 2005, and both string.join() and str.join() still
explicitly expect a sequence of strings rather than a sequence of
stringifiable objects.

I'm not complaining as such -- sep.join(str(i) for i in seq) is
not *that* ugly, but what annoys me is that I don't understand
*why* this was never changed. Presumably there is some
counter-argument involved, some reason why people preferred the
existing semantics after all. But for the life of me I can't
think what that counter-argument might be...

--
Leo Breebaart <le*@lspace.org>

[John Roth]

"Leo Breebaart" <le*@lspace.org> wrote in message
news:37*************@individual.net...

I've tried Googling for this, but practically all discussions on
str.join() focus on the yuck-ugly-shouldn't-it-be-a-list-method?
issue, which is not my problem/question at all.

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.

All I've been able to find is a 1999 python-dev post by Tim
Peters which would seem to indicate he doesn't understand it
either:

"string.join(seq) doesn't currently convert seq elements to
string type, and in my vision it would. At least three of us
admit to mapping str across seq anyway before calling
string.join, and I think it would be a nice convenience
[...]"

But now it's 2005, and both string.join() and str.join() still
explicitly expect a sequence of strings rather than a sequence of
stringifiable objects.

I'm not complaining as such -- sep.join(str(i) for i in seq) is
not *that* ugly, but what annoys me is that I don't understand
*why* this was never changed. Presumably there is some
counter-argument involved, some reason why people preferred the
existing semantics after all. But for the life of me I can't
think what that counter-argument might be...
I was originally going to say performance, but I don't think
that's all that much of an issue.

For me, at least, I've already got a way of taking just about
anything and turning it into a string: the % operator. It's
powerful enough that there have been attempts to make
a less powerful and simpler to understand version.

The limitation here is that you have to know how many
elements you want to join, although even that isn't the
world's hardest issue. Consider:

(untested)
result = ("%s" * len(list)) % list

Not the most obvious code in the world, but it might
work.

And as someone else (you?) pointed out, this will
also work:

(untested)
result = "".join([str(x) for x in list])

and it's got the advantage that it will handle separators
properly.

John Roth

--
Leo Breebaart <le*@lspace.org>

[Nick Vargish]

Leo Breebaart <le*@lspace.org> writes:

That suggests
to me an "obvious default" of the kind that exists elsewhere in
Python as well.

I feel pretty much the opposite... If a non-string-type has managed to
get into my list-of-strings, then something has gone wrong and I would
like to know about this potential problem.

If you want to do force a conversion before the join, you can use a
list comp:

', '.join([str(x) for x in l])
Nick "Explicit is better than Implicit"

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')

[David Eppstein]

In article <37*************@individual.net>,
Leo Breebaart <le*@lspace.org> wrote:

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.

That would be the wrong thing to do when the arguments are unicodes.

--
David Eppstein
Computer Science Dept., Univ. of California, Irvine
http://www.ics.uci.edu/~eppstein/

[John Machin]

On Wed, 16 Feb 2005 14:24:02 -0600, Skip Montanaro <sk**@pobox.com>
wrote:

John> 4. For consistency, would you like "1" + 2 to produce "12"?

No, the correct answer is obviously 3. ;-)

Obviously, in awk. Bletch! I once had to help out some users of a
system where software development had been outsourced and upstuffed
and they needed some data file fixups done but their system was so
locked down even the manufacturer-supplied free pre-ANSI C compiler
had been deleted and one couldn't download stuff off the net but the
thought police had overlooked awk ... I even had to implement proper
CSV-reading routines in awk. No thanks for reminding me :-(

[Michael Hoffman]

Fredrik Lundh wrote:

I've proposed adding a "join" built-in that knows about the available string types,
and does the right thing for non-string objects.

That would be *so* useful. I frequently have to use the

"".join(map(str, mylist))

idiom, which is a wart.
--
Michael Hoffman

[Roy Smith]

In article <ep****************************@news.service.uci.e du>,
David Eppstein <ep******@ics.uci.edu> wrote:

In article <37*************@individual.net>,
Leo Breebaart <le*@lspace.org> wrote:

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.

That would be the wrong thing to do when the arguments are unicodes.

Why would it be wrong? I ask this with honest naivete, being quite
ignorant of unicode issues.

[Jeff Shannon]

Roy Smith wrote:

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.

That would be the wrong thing to do when the arguments are unicodes.

Why would it be wrong? I ask this with honest naivete, being quite
ignorant of unicode issues.

As someone else demonstrated earlier...

str(u'ü') Traceback (most recent call last):
File "<interactive input>", line 1, in ?
UnicodeError: ASCII encoding error: ordinal not in range(128)

Using str() on a unicode object works... IF all of the unicode
characters are also in the ASCII charset. But if you're using
non-ASCII unicode characters (and there's no point to using Unicode
unless you are, or might be), then str() will throw an exception.

The Effbot mentioned a join() implementation that would be smart
enough to do the right thing in this case, but it's not as simple as
just implicitly calling str().

Jeff Shannon
Technician/Programmer
Credit International

[news.sydney.pipenetworks.com]

Nick Vargish wrote:

Leo Breebaart <le*@lspace.org> writes:

That suggests
to me an "obvious default" of the kind that exists elsewhere in
Python as well.

I feel pretty much the opposite... If a non-string-type has managed to
get into my list-of-strings, then something has gone wrong and I would
like to know about this potential problem.

If you want to do force a conversion before the join, you can use a
list comp:

', '.join([str(x) for x in l])
Nick "Explicit is better than Implicit"

Really ? Then why are you using python. Python or most dynamic languages
are are so great because of their common sense towards the "implicit".
You must have heard of "never say never" but "never say always" (as in
"always better") is more appropriate here. There are many cases of
python's implicitness.

What about

a = "string"
b = 2
c = "%s%s" % (a, b)

There is an implicit str(b) here.

''.join(["string", 2]) to me is no different then the example above.
Huy

[Fredrik Lundh]

"news.sydney.pipenetworks.com" wrote:

Nick "Explicit is better than Implicit"
Really ? Then why are you using python. Python or most dynamic languages are are so great because
of their common sense towards the "implicit". You must have heard of "never say never" but "never
say always" (as in "always better") is more appropriate here. There are many cases of python's
implicitness.

a certain "princess bride" quote would fit here, I think.
What about

a = "string"
b = 2
c = "%s%s" % (a, b)

There is an implicit str(b) here.
nope. it's explicit: %s means "convert using str()".

from the documentation:

%s String (converts any python object using str()).

''.join(["string", 2]) to me is no different then the example above.

so where's the "%s" in your second example?

</F>

[Nick Craig-Wood]

Nick Vargish <na*******@bandersnatch.org> wrote:

I feel pretty much the opposite... If a non-string-type has managed to
get into my list-of-strings, then something has gone wrong and I would
like to know about this potential problem.
This is a good argument.

Why not have another method to do this? I propose joinany which will
join any type of object together, not just strings

That way it becomes less of a poke in the eye to backwards
compatibility too.
Nick "Explicit is better than Implicit"

Aye!

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick

[Max M]

Nick Craig-Wood wrote:

Nick Vargish <na*******@bandersnatch.org> wrote: Why not have another method to do this? I propose joinany which will
join any type of object together, not just strings

l = [1,2,3,'four']
','.join(map(str, l))

'1,2,3,four'

Is this really that hard to do, that you want it in the library?

--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

[Michael Hoffman]

Nick Craig-Wood wrote:

Why not have another method to do this? I propose joinany which will
join any type of object together, not just strings

I think that's what Frederik was proposing. Except that it would be
called join and be a built-in (not a str method).
--
Michael Hoffman

[Michael Hoffman]

Max M wrote:

>>> ','.join(map(str, l))

'1,2,3,four'

Is this really that hard to do, that you want it in the library?

I think it's a sufficiently common use case that having to do that
is a wart.
--
Michael Hoffman

[Nick Coghlan]

Leo Breebaart wrote:

All I've been able to find is a 1999 python-dev post by Tim
Peters which would seem to indicate he doesn't understand it
either:

"string.join(seq) doesn't currently convert seq elements to
string type, and in my vision it would. At least three of us
admit to mapping str across seq anyway before calling
string.join, and I think it would be a nice convenience
[...]"

But now it's 2005, and both string.join() and str.join() still
explicitly expect a sequence of strings rather than a sequence of
stringifiable objects.

There's a more recent discussion than that, because I tried to change it shortly
after I offered a patch to fix a corner case for string subclasses.

This seems to be the last relevant message in the thread:
http://mail.python.org/pipermail/pyt...st/048516.html

So it was tried, but we found too many weird corner cases we weren't quite sure
what to do with. At that point, "explicit is better than implicit" kicked in :)

A shame, since it was both faster and more convenient than using a list comp.
But the convenience wasn't worth the ambiguity of the semantics.

Cheers,
Nick.

P.S. For anyone else that uses Firefox:

Linking the pydev keyword to
"http://www.google.com/search?q=site:mail.python.org+inurl:python-dev+%s"

and the pylist keyword to
"http://www.google.com/search?q=site:mail.python.org+inurl:python-list+%s"

makes searching the archives on python.org really easy. Of course, knowing what
you're looking for because you were a participant in the discussion helps, too ;)

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Leif K-Brooks]

Leo Breebaart wrote:

What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments

I don't really like that idea for the reasons others have stated. But a
related and (IMHO) more Pythonic idea would be to allow arbitrary
objects to be str.join()ed if they use __radd__ to allow concatenation
with strings. This would be consistent with how the + operator behaves:

Python 2.4 (#2, Jan 8 2005, 20:18:03)
[GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

class Foo(object): .... def __radd__(self, other):
.... if isinstance(other, basestring):
.... return other + str(self)
.... def __str__(self):
.... return 'Foo()'
.... 'foo:' + Foo() 'foo:Foo()' ''.join(['foo', Foo()])

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: sequence item 1: expected string, Foo found

[Nick Vargish]

"news.sydney.pipenetworks.com" <ny*****@swiftdsl.com.au> writes:

Really ? Then why are you using python.
Try "import this" at a Python prompt. I didn't invent "Explicit is
better than implicit."
Python or most dynamic languages are are so great because of their
common sense towards the "implicit".
Python is not "most dynamic languages", and does not seem to
implicitly "cast" objects into other types. Python may be "dynamic",
but it's also "strongly typed", a feature I consider a benefit, though
you are of course free to disagree.
c = "%s%s" % (a, b)
There is an implicit str(b) here.
Not if you read the docs, as another poster has pointed out.
''.join(["string", 2]) to me is no different then the example above.

TypeError: sequence item 1: expected string, int found

Which pretty much supports my initial argument -- if a non-string got
into the list, something needs to be fixed, and it isn't the behavior
of the join() method!

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')

[news.sydney.pipenetworks.com]

Fredrik Lundh wrote:

"news.sydney.pipenetworks.com" wrote:

Nick "Explicit is better than Implicit"
Really ? Then why are you using python. Python or most dynamic languages are are so great because
of their common sense towards the "implicit". You must have heard of "never say never" but "never
say always" (as in "always better") is more appropriate here. There are many cases of python's
implicitness.

a certain "princess bride" quote would fit here, I think.

I'm not really familiar with it, can you enlighten please.

What about

a = "string"
b = 2
c = "%s%s" % (a, b)

There is an implicit str(b) here.

nope. it's explicit: %s means "convert using str()".

ok you got me there, although it must be bad practice compared to

c = "%s%d" % (a, b)

because this is much more explicit and will tell you if b is ever
anything other then an integer even though you may not care.
from the documentation:

%s String (converts any python object using str()).

''.join(["string", 2]) to me is no different then the example above.

so where's the "%s" in your second example?

</F>

I'm not sure if this has been raised in the thread but I sure as heck
always convert my join arguments using str(). When does someone use
..join() and not want all arguments to be strings ? Any examples ?

Regards,

Huy

[news.sydney.pipenetworks.com]

Fredrik Lundh wrote:

"news.sydney.pipenetworks.com" wrote:

Nick "Explicit is better than Implicit"
Really ? Then why are you using python. Python or most dynamic languages are are so great because
of their common sense towards the "implicit". You must have heard of "never say never" but "never
say always" (as in "always better") is more appropriate here. There are many cases of python's
implicitness.

a certain "princess bride" quote would fit here, I think.

I'm not really familiar with it, can you enlighten please.

What about

a = "string"
b = 2
c = "%s%s" % (a, b)

There is an implicit str(b) here.

nope. it's explicit: %s means "convert using str()".

ok you got me there, although it must be bad practice compared to

c = "%s%d" % (a, b)

because this is much more explicit and will tell you if b is ever
anything other then an integer even though you may not care.
from the documentation:

%s String (converts any python object using str()).

''.join(["string", 2]) to me is no different then the example above.

so where's the "%s" in your second example?

</F>

I'm not sure if this has been raised in the thread but I sure as heck
always convert my join arguments using str(). When does someone use
..join() and not want all arguments to be strings ? Any examples ?

Regards,

Huy

[Nick Coghlan]

news.sydney.pipenetworks.com wrote:

I'm not sure if this has been raised in the thread but I sure as heck
always convert my join arguments using str(). When does someone use
.join() and not want all arguments to be strings ? Any examples ?

When the list argument already contains only strings, conversion is redundant.

Anyway, automatic conversion of the argument list elements *was* tried around
August of last year, despite some concerns about it being too magical. However,
the interaction between string, unicode, subclasses of same, __str__, __repr__,
__unicode__ and everything else made it impossible to come up with behaviour
that was clearly 'better' than the status quo (every idea we considered ended up
resulting in quirky behaviour at some point), so things never progressed to a
formal patch.

The explicit use of map() or LC was kept as the least bad of the available options.

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[news.sydney.pipenetworks.com]

Nick Vargish wrote:

"news.sydney.pipenetworks.com" <ny*****@swiftdsl.com.au> writes:

Really ? Then why are you using python.

Try "import this" at a Python prompt. I didn't invent "Explicit is
better than implicit."

Thanks for the pointer. Let's see how many zen points are for the OP's
idea vs against

Against
Explicit is better than implicit.
Special cases aren't special enough to break the rules.

On the wall
Errors should never pass silently.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
Namespaces are one honking great idea -- let's do more of those!

For
Beautiful is better than ugly.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Although practicality beats purity. Unless explicitly silenced.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.

Well this is clearly a goer ;-)

Python or most dynamic languages are are so great because of their
common sense towards the "implicit".

Python is not "most dynamic languages", and does not seem to
implicitly "cast" objects into other types. Python may be "dynamic",
but it's also "strongly typed", a feature I consider a benefit, though
you are of course free to disagree.

c = "%s%s" % (a, b)
There is an implicit str(b) here.

Not if you read the docs, as another poster has pointed out.

''.join(["string", 2]) to me is no different then the example above.

TypeError: sequence item 1: expected string, int found

Which pretty much supports my initial argument -- if a non-string got
into the list, something needs to be fixed, and it isn't the behavior
of the join() method!

Nick

[Nick Coghlan]

news.sydney.pipenetworks.com wrote:

Nick Vargish wrote:

"news.sydney.pipenetworks.com" <ny*****@swiftdsl.com.au> writes:

Really ? Then why are you using python.

Try "import this" at a Python prompt. I didn't invent "Explicit is
better than implicit."

Thanks for the pointer. Let's see how many zen points are for the OP's
idea vs against

Against
Explicit is better than implicit.
Special cases aren't special enough to break the rules.

On the wall
Errors should never pass silently.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
Namespaces are one honking great idea -- let's do more of those!

For
Beautiful is better than ugly.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Although practicality beats purity. Unless explicitly silenced.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.

From the point of view of someone who actually *tried* doing this to the
relevant method, while maintaining backward compatibility. . .

Against:

Explicit is better than implicit
Special cases aren't special enough to break the rules

In the face of ambiguity, refuse the temptation to guess
- there are plenty of ambiguious cases to handle
Simple is better than complex (Semantics & C code)
- and much complexity in dealing with the ambiguities
Errors should never pass silently. Unless explicitly silenced.
- and a bunch of them are likely to indicate errors. Maybe.
Readability counts (C code)
- This makes the implemenation hard to read
If the implementation is hard to explain, it's a bad idea.
- or explain to anyone, too

For:

Beautiful is better than ugly.
- the explicit calls to str() aren't that clean.

There should be one-- and preferably only one --obvious way to do it.
- Currently listcomp, genexp, map, string interpolation, etc

IMO, the rest can be used to argue either side, or simply don't weigh heavily
either way.

The things that make it a real cow are the current behaviour of auto-promotion
to the Unicode version when there are any Unicode strings in the list, and the
existence of __str__ and __repr__ methods which actually return instances of
unicode rather than str.

Calling str() explicitly makes the different behaviours unsurprising. Trying to
do the same thing behind the scenes has the potential to make the method behave
*very* suprisingly depending on the objects involved.

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Sion Arrowsmith]

In article <87************@localhost.localdomain.i-did-not-set--mail-host-address--so-tickle-me>,

!

Nick Vargish <na*******@bandersnatch.org> wrote:

If a non-string-type has managed to
get into my list-of-strings, then something has gone wrong and I would
like to know about this potential problem.

Thinking about where I use join(), I agree. If there's something
other than a string in my list, either I know about it and can
explicitly convert it ("Explicit is better than implicit.") or
it's an error, and "Errors should never pass silently."

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Duncan Booth]

news.sydney.pipenetworks.com wrote:

I'm not sure if this has been raised in the thread but I sure as heck
always convert my join arguments using str(). When does someone use
.join() and not want all arguments to be strings ? Any examples ?

This has already been raised, but maybe not in exactly this context. You
don't want to convert your arguments to be strings if some of them are
unicode.

If I do:

res = str.join(', ', [a, b, c])

then res is of type str if, and only if, a, b, and c are of type str.
If any of a, b, or c are of type unicode, then res is unicode.

In effect, this means you don't have to worry about whether you are
manipulating str or unicode at this point in your program (kind of
comparable to not caring whether the integer you are using is int or long).

When you come to output the string you do need to care, as when it is
unicode you may have to encode it, but at least the internal manipulations
can ignore this possibility.

Of course you could just call unicode on everything but for simple
applications you might not want to handle unicode at all. That's not a
decision Python can make for you so it shouldn't guess.

[Jeff Shannon]

news.sydney.pipenetworks.com wrote:

Fredrik Lundh wrote:

a certain "princess bride" quote would fit here, I think.

I'm not really familiar with it, can you enlighten please.

(Taking a guess at which quote /F had in mind...)
Vezzini: "Inconceivable!"
Inigo: "You keep using that word. I do not think that it means
what you think it means."

Jeff Shannon

[Terry Reedy]

"Nick Coghlan" <nc******@iinet.net.au> wrote in message
news:42**************@iinet.net.au...

This seems to be the last relevant message in the thread:
http://mail.python.org/pipermail/pyt...st/048516.html So it was tried, but we found too many weird corner cases we weren't
quite sure
what to do with. At that point, "explicit is better than implicit" kicked
in :)
A shame, since it was both faster and more convenient than using a list
comp. But the convenience wasn't worth the ambiguity of the semantics.

Your experience, where you made an honest go of implementation, and the
error catching argument, convince me that explicit is better for this case.

I was thinking, 'Well, print autoconverts' (as documented). But it
requires that each item be listed. And if there is any ambiguity, no harm
since it is only meant for quick convenience anyway and not exact
char-by-char control. Join, on the other hand, often gets a pre-existing
list. If that is known (thought to be) all strings, then mapping str is a
waste as well as an error mask. In not, map(str,...) is only 9 extra
chars.

Terry J. Reedy

[Jeremy Bowers]

On Fri, 18 Feb 2005 01:19:44 +1100, news.sydney.pipenetworks.com wrote:

Thanks for the pointer. Let's see how many zen points are for the OP's
idea vs against

Along with the fact that I agree with Nick that you've seriously
miscounted (most of your "fors" are simply irrelevant and I think you
added them to bolster your point, at least I *hope* you don't think they
are all relevant... for instance if you really think "Flat is better than
nested" applies here, you don't understand what that one is saying...),
I'd point out that the Zen that can be comprehended by checking off items
in a list is not the true Zen.

[Dave Benjamin]

Jeremy Bowers wrote:

I'd point out that the Zen that can be comprehended by checking off items
in a list is not the true Zen.

The Zen that can be imported is not the eternal Zen. =)

[Jeremy Bowers]

On Thu, 17 Feb 2005 14:00:59 -0700, Dave Benjamin wrote:

Jeremy Bowers wrote:

I'd point out that the Zen that can be comprehended by checking off items
in a list is not the true Zen.

The Zen that can be imported is not the eternal Zen. =)

Yes, there is that too. :-)

[news.sydney.pipenetworks.com]

Duncan Booth wrote:

news.sydney.pipenetworks.com wrote:

I'm not sure if this has been raised in the thread but I sure as heck
always convert my join arguments using str(). When does someone use
.join() and not want all arguments to be strings ? Any examples ?

This has already been raised, but maybe not in exactly this context. You
don't want to convert your arguments to be strings if some of them are
unicode.

If I do:

res = str.join(', ', [a, b, c])

then res is of type str if, and only if, a, b, and c are of type str.
If any of a, b, or c are of type unicode, then res is unicode.

In effect, this means you don't have to worry about whether you are
manipulating str or unicode at this point in your program (kind of
comparable to not caring whether the integer you are using is int or long).

When you come to output the string you do need to care, as when it is
unicode you may have to encode it, but at least the internal manipulations
can ignore this possibility.

Of course you could just call unicode on everything but for simple
applications you might not want to handle unicode at all. That's not a
decision Python can make for you so it shouldn't guess.

I see your point but I'm not totally convinced I don't understand
unicode that well so I'll just be quiet now.

Your point about int and long vs str and unicode is interesting though.
Does it mean str and unicode will some time in the future be unified
once all the differences are sorted out ?

Regards,

Huy

[news.sydney.pipenetworks.com]

Jeremy Bowers wrote:

On Fri, 18 Feb 2005 01:19:44 +1100, news.sydney.pipenetworks.com wrote:

Thanks for the pointer. Let's see how many zen points are for the OP's
idea vs against

Along with the fact that I agree with Nick that you've seriously
miscounted (most of your "fors" are simply irrelevant and I think you
added them to bolster your point, at least I *hope* you don't think they
are all relevant... for instance if you really think "Flat is better than
nested" applies here, you don't understand what that one is saying...),

You're right there. It's my own interpretation :-)
I'd point out that the Zen that can be comprehended by checking off items
in a list is not the true Zen.

Well I didn't create or bring up the list of items originally. I was
"zenning" it out until someone pointed me to the "Python" commandments.

I always wished computer science was more engineering then philosophy.
That way there'd always be an obvious answer.

Regards,

Huy

[Jeremy Bowers]

On Fri, 18 Feb 2005 14:14:55 +1100, news.sydney.pipenetworks.com wrote:

I always wished computer science was more engineering then philosophy.
That way there'd always be an obvious answer.

I hear that!

To be fair, computer *science* is more like mathematics than philosophy;
once a correctly-framed question has been asked there is only one answer,
or at least the answers are definite, or definite in their indefiniteness.
(For the most part.)

We're programming here though, and there we are groping through the
formless void, arguing about whether my infinitesimal is better than your
infinitesimal.

Sorry, I was Zenning it out too, I guess. :-)

By the way, just to be clear, my infinitesimal's dad can beat up your
infinitesimal's dad any day of the week.

(Looks like the Zen mood has passed...)

[Nick Vargish]

"news.sydney.pipenetworks.com" <ny*****@swiftdsl.com.au> writes:

I always wished computer science was more engineering then
philosophy. That way there'd always be an obvious answer.

You don't have a lot of experience with philosophers, do you?

Most of them are quite willing to go on at great length about the
obvious answer to just about any question... You get a dozen obvious
answers with every twelve philosophers.

Nick

p.s. I've been working on a philosophy degree for about... 15 years
now.

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')

[news.sydney.pipenetworks.com]

Jeremy Bowers wrote:

By the way, just to be clear, my infinitesimal's dad can beat up your
infinitesimal's dad any day of the week.
Ouch....it's getting personal :-). Your dad may be infinitesimal but my
dad is a complex number (I'm not joking, he really has a real and
imaginary part).
(Looks like the Zen mood has passed...)

:-)

Huy

[news.sydney.pipenetworks.com]

Nick Vargish wrote:

"news.sydney.pipenetworks.com" <ny*****@swiftdsl.com.au> writes:

I always wished computer science was more engineering then
philosophy. That way there'd always be an obvious answer.

You don't have a lot of experience with philosophers, do you?

No
Most of them are quite willing to go on at great length about the
obvious answer to just about any question... You get a dozen obvious
answers with every twelve philosophers.
Interesting. I guess its obvious once stated, because if it wasn't
obvious, many people wouldn't agree. I'm sure theres got to be a few
copy cats in those 12 though.
Nick

p.s. I've been working on a philosophy degree for about... 15 years
now.

Does that mean you just haven't had time to finish ? or you have been
studying philosophy for 15 years ?

Huy

[Nick Vargish]

"news.sydney.pipenetworks.com" <ny*****@swiftdsl.com.au> writes:

I'm sure theres got to be a few copy cats in those 12 though.
Those that don't come up with original answers alter the existing
ones a bit and call it their own.
Does that mean you just haven't had time to finish ? or you have been
studying philosophy for 15 years ?

Sort of an extended break, really. Every year I plan to finish up, but
then can't find the time and/or money to do it.

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')

[Nick Coghlan]

news.sydney.pipenetworks.com wrote:

I see your point but I'm not totally convinced I don't understand
unicode that well so I'll just be quiet now.
Unicode is horrible, but better than the available alternatives when it comes to
character sets with more than 128 characters :)
Your point about int and long vs str and unicode is interesting though.
Does it mean str and unicode will some time in the future be unified
once all the differences are sorted out ?

Eventually, all Python text strings will be unicode, with a separate type for
manipulating a sequence of bytes. That's a long way away, though.

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Rocco Moretti]

Jeff Shannon wrote:

news.sydney.pipenetworks.com wrote:

Fredrik Lundh wrote:

a certain "princess bride" quote would fit here, I think.

I'm not really familiar with it, can you enlighten please.

(Taking a guess at which quote /F had in mind...)

Vezzini: "Inconceivable!"
Inigo: "You keep using that word. I do not think that it means what
you think it means."

Jeff Shannon

With all the talk about "never"s, my initial thought was:

Vezzini: Haha.. you fool! You fell victim to one of the classic
blunders. The most famous is: Never get involved in a land war in Asia.
Only slightly less well know is this: Never go in against a Sicilian
when death is on the line! Ha ha, Ha ha, Ha <thunk>

I think yours makes more sense in context, though.