len() should always return something

[Hendrik van Rooyen]

Nah. 7 contains three bits, so len(7) should *clearly* return 3.

Almost right - however the first seven that you typed was a string
seven and not an int - so the hex is 37 and that takes at least
six bits...



Now if only someone can figure out a reason why it should
return seven, then it would be perfect!

- Hendrik

 

[Diez B. Roggisch]

Here's a simple-minded example:

def dumbfunc(xs):
for x in xs:
print x

This function works fine if xs is a list of floats, but not if it is single
float. It can be made to work as follows:

def dumbfunc(xs):
if isinstance(xs,(int,float,complex)): xs= [xs]
for x in xs:
print x

Having to put such extra logic into practically every function is one of the
annoying things about Python.

And where comes "len(xs)" into play here? What you want is iteration
over scalars.

I do think that if you frequently have to write code like that, you are
writing errorneous code.

But might that as it is, a simple


def iterable(i):
if isinstance(i, (int, float, complex)):
return
return i


is all you need. So you can write


for x in iterable(xs):


wherever you expect values to be either scalar or iterable.

Diez

 

[Hendrik van Rooyen]

Compressing strings to a single bit is easy. It's the uncompressing that's
tricky.

Not really - all you have to do is to apply the EXACT same sequence
of operations that compressed it, in reverse.

The unfortunate part is that this information is in almost all cases
larger than the original, uncompressed string, so that it kind of defeats
the object of compression.

So yes - tricky!



- Hendrik

 

[Hendrik van Rooyen]

First one to correctly decompress the value 0 into an ASCII character
wins the title of the world's most capable hacker

that is easy.

the xor of 0 and 1 is 1, which is ASCII soh, if I remember right.

soh is start of header.

Burroughs poll select, anyone?

- Hendrik

 

[Rhodri James]

Here's a simple-minded example:

def dumbfunc(xs):
for x in xs:
print x

This function works fine if xs is a list of floats, but not if it is
single
float. It can be made to work as follows:

def dumbfunc(xs):
if isinstance(xs,(int,float,complex)): xs= [xs]
for x in xs:
print x

Having to put such extra logic into practically every function is one of
the
annoying things about Python.

If you persist in treating <language 1> as if it was <language 2>, then
your code will always be ugly, and often buggy. Unless we're talking
natural languages, in which case Yoda-like you will sound.

Fundamentally, your problem is your assertion that it is reasonable to
allow users to treat a single object as if it were wrapped in a list.
In Python, it is not reasonable, for the reasons that you are spending
so much time complaining about.

 

[Robert Kern]

Here's a simple-minded example:

def dumbfunc(xs):
for x in xs:
print x

This function works fine if xs is a list of floats, but not if it is single
float. It can be made to work as follows:

def dumbfunc(xs):
if isinstance(xs,(int,float,complex)): xs= [xs]
for x in xs:
print x

Having to put such extra logic into practically every function is one of the
annoying things about Python.

I have spent the last ten years writing scientific code in Python (i.e. that
which otherwise might be written in Matlab), and I can guarantee you that you do
not need to put such extra logic in practically every function. Even when
naively translating code from Matlab, it's not often necessary.

By the way, are you familiar with numpy? If you are converting code from Matlab,
you will almost certainly need it. We have a number of functions that make these
kinds of operations easy when they are in fact necessary. For example, we have
isscalar() and atleast_1d().

def dumbfunc(xs):
xs = numpy.atleast_1d(xs)
for x in xs:
print x

http://numpy.scipy.org/

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Robert Kern]

Here's a simple-minded example:

def dumbfunc(xs):
for x in xs:
print x

This function works fine if xs is a list of floats, but not if it is
single
float. It can be made to work as follows:

def dumbfunc(xs):
if isinstance(xs,(int,float,complex)): xs= [xs]
for x in xs:
print x

Having to put such extra logic into practically every function is one
of the
annoying things about Python.

And where comes "len(xs)" into play here? What you want is iteration
over scalars.

He explained in another post that iteration is another feature along the same
lines that he would want for scalars.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Chris Rebert]

But it's not "practically every function". It's hardly any function at all
-- in my code, I don't think I've ever wanted this behavior. I would
consider it an error for function(42) and function([42]) to behave the same
way. One is a scalar, and the other is a vector -- they're different things,
it's poor programming practice to treat them identically.

(If Matlab does this, so much the worse for Matlab, in my opinion.)

There's actually good reason to do this in heavily matrix-oriented
specialized languages; there are numerous applications where scalars and 1x1
matrices are mathematically equivalent.

The pertinent issue here being that Python, as a language, is neither
matrix-oriented nor special-purpose.

Cheers,
Chris

 

[Chris Rebert]

Steven D'Aprano wrote:

But it's not "practically every function". It's hardly any function at
all
-- in my code, I don't think I've ever wanted this behavior. I would
consider it an error for function(42) and function([42]) to behave the
same
way. One is a scalar, and the other is a vector -- they're different
things,
it's poor programming practice to treat them identically.

(If Matlab does this, so much the worse for Matlab, in my opinion.)

There's actually good reason to do this in heavily matrix-oriented
specialized languages; there are numerous applications where scalars and
1x1
matrices are mathematically equivalent.

The pertinent issue here being that Python, as a language, is neither
matrix-oriented nor special-purpose.

Yes.  And I was responding to the comment that such a feature of a language
would a priori be poor design.  It _isn't_ poor design for special purpose
languages.  Python isn't one of them, but Matlab _is_.

I was agreeing with your point actually. That was what I was trying to
convey in my post. Apparently I wasn't as successful in that regard as
I'd hoped.

- Chris

 

[Steven D'Aprano]

But it's not "practically every function". It's hardly any function at
all -- in my code, I don't think I've ever wanted this behavior. I
would consider it an error for function(42) and function([42]) to
behave the same way. One is a scalar, and the other is a vector --
they're different things, it's poor programming practice to treat them
identically.

(If Matlab does this, so much the worse for Matlab, in my opinion.)

There's actually good reason to do this in heavily matrix-oriented
specialized languages; there are numerous applications where scalars and
1x1 matrices are mathematically equivalent.

I'm curious what those applications are, because regular multiplication
behaves differently depending on whether you have a 1x1 matrix or a
scalar:

[[2]]*[[1, 2, 3], [2, 3, 4]] is not defined

2*[[1, 2, 3], [2, 3, 4]] = [[2, 4, 6], [2, 6, 8]]


I'm curious as to what these applications are, and what they're actually
doing. Kronecker multiplication perhaps? Do you have some examples of
those applications?

 

[drednot57]

To the best of my recollection, the len() function only applies to
container objects; i. e. tuples, lists, strings, etc. an integer
object is not a container, thus one receives an error when sending an
int as an argument for len().