Python is Considered Harmful

[Jerzy Karczmarczuk]

Jegenye 2001 Bt wrote:

Do you mean, implicitly using base 13? I know of no programming
language that lets you set the number base to be used for literals
(except presumably ones with particularly 'powerful' macros...?-)
and I hope I never have to contend with one.

In Icon you can write 13r9 * 13r6. Icon is a decent, although weakly known
language, without any "particularly 'powerful' macros", which permits to
choose the base of literals. Nothing horrible.


Jerzy Karczmarczuk

 

[Alex Martelli]

...
In Icon you can write 13r9 * 13r6. Icon is a decent, although weakly known
language, without any "particularly 'powerful' macros", which permits to
choose the base of literals. Nothing horrible.

Yes, I used to love Icon (the coroutines and backtracking and all, cool!)
but notice it uses EXPLICIT indications of non-10 base. There is, indeed,
nothing at all horrible with that.

Besides, the problem is not with 9 or 6, which happen to have the same
value in either base 10 or 13. The problem is with that result...


Alex

 

[Stefan Axelsson]

Actually, I did work in Forth (it was the in-ROM language of a
neat computer I once bought, called "Jupiter ACE"; and also of a
special-purpose image processing PC card I once used at work),
but never came across that "feature" (assuming those dialects of
Forth in those ROMs supported it, that is). Guess I was lucky
that in those special cases I wasn't sharing code w/others.

Well the Jupiter ACE (of which I'm still a proud owner) suppored it,
it's in the '79 standard after all. E.g. just do '16 base !', for
hexadecimal input for example. Makes writing an assembler in Forth,
or the usual combination of Forth and assembly simpler if nothing else.

As everything Forth, judicious use is key.

Stefan,

 

[Alan Offer]

I believe the behaviour can be fixed rather easily by some directives, say
making it

map(lambda f: f(1), [lambda x: x+(*i) for i in range(3)])

where the * construct would get the reference of i at function definition
time rather than at function invocation time (anyone can point me to an
PEP?).

We can essentially do this by passing i to a function that then returns the
desired function. So to make flist with the functions that mike420 wanted,
we can use:

flist = map(lambda i: (lambda x: x+i), range(3))

Now [f(1) for f in flist] is [1, 2, 3] as he expected.

 

[Marco Antoniotti]

I believe the behaviour can be fixed rather easily by some directives, say
making it

map(lambda f: f(1), [lambda x: x+(*i) for i in range(3)])

where the * construct would get the reference of i at function definition
time rather than at function invocation time (anyone can point me to an
PEP?).

We can essentially do this by passing i to a function that then returns the
desired function. So to make flist with the functions that mike420 wanted,
we can use:

flist = map(lambda i: (lambda x: x+i), range(3))

Now [f(1) for f in flist] is [1, 2, 3] as he expected.

This is good and I stand corrected then. At least you can achieve this
with Python.

Cheers

 

[Isaac To]

>> I believe the behaviour can be fixed rather easily by some
>> directives, say making it
>>
>> map(lambda f: f(1), [lambda x: x+(*i) for i in range(3)])
>>
>> where the * construct would get the reference of i at function
>> definition time rather than at function invocation time (anyone can
>> point me to an PEP?).

Alan> We can essentially do this by passing i to a function that then
Alan> returns the desired function. So to make flist with the functions
Alan> that mike420 wanted, we can use:

Alan> flist = map(lambda i: (lambda x: x+i), range(3))

Alan> Now [f(1) for f in flist] is [1, 2, 3] as he expected.

Ah... that means

map(lambda f: f(1), [(lambda i: lambda x: x+i)(i) for i in range(3)])

Seems make sense to me.

Regards,
Isaac.