reduce() anomaly?

[Andrew Dalke]

Re: reduce()--what is it good for? (was: Re: reduce() anomaly?)

Georgy Pruss:[color=blue]
> I NEVER wondered which of constructions should I
> use in any particular case. I just solved the problem and wrote its[/color]
solution[color=blue]
> in that language and the language HELPED me to express myself clearly.[/color]

While I, when writing Perl code, also NEVER had a problem. I
ignored just about all of its variations
if ($cond) {$a++}
$a++ if $cond;
$a++ unless !($cond);
unless (!($cond)) {$a++};

I almost only used the first of these, and when other variations
in structure came up I again had a strong preference for the one
closest to C in feel. I did this not because it was the most expressive
but because I wanted to write code that others could follow,
and indeed one of the praises I got was "wow! It's Perl code I
can actually understand!"
[color=blue]
> Half of all the conditions in real Python programs are 1 or True. :-)[/color]

Cute as a joke, but in real-life it omits while loops, wherein
the conditionals usually end up being true. ;)

x = 1
while x < 1000:
print x
x = x + random.random(1 0)

Andrew
dalke@dalkescie ntific.com

[Ville Vainio]

Re: Too much builtins (was Re: Python's simplicity philosophy

"Andrew Dalke" <adalke@mindspr ing.com> writes:
[color=blue]
> Georgy Pruss:[color=green]
> > Maybe, it's worth to have str(x,8) and str(x,16) instead of oct(x) and[/color]
> hex(x)[color=green]
> > and make str() a true inverse function to int()?[/color]
>
> What then are the results of
> str(30+44j, 16)
> str(3.1415926, 8)
> str([9, 8, 7], 8)
> str("A", 16)
> str({"A": 20}, 16)
> ?[/color]

TypeError?

--
Ville Vainio http://www.students.tut.fi/~vainio24

[Georgy Pruss]

Re: Too much builtins (was Re: Python's simplicity philosophy


"Andrew Dalke" <adalke@mindspr ing.com> wrote in message news:lJjub.4602 $sb4.2551@newsr ead2.news.pas.e arthlink.net...
| Georgy Pruss:
| > Maybe, it's worth to have str(x,8) and str(x,16) instead of oct(x) and
| hex(x)
| > and make str() a true inverse function to int()?
|
| What then are the results of
| str(30+44j, 16)
| str(3.1415926, 8)
| str([9, 8, 7], 8)
| str("A", 16)
| str({"A": 20}, 16)
| ?
|
| Andrew
| dalke@dalkescie ntific.com

I guess, the same as for
hex(30+44j)
oct(3.1415926)
oct([9, 8, 7])
hex("A")
hex({"A": 20})

G-:

[Steve Lamb]

Re: reduce()--what is it good for? (was: Re: reduce() anomaly?)

On 2003-11-18, Andrew Dalke <adalke@mindspr ing.com> wrote:[color=blue]
> While I, when writing Perl code, also NEVER had a problem. I
> ignored just about all of its variations
> if ($cond) {$a++}
> $a++ if $cond;
> $a++ unless !($cond);
> unless (!($cond)) {$a++};[/color]

Exactly the case I was thinking of when I wrote my message. 4 ways to
express an if. After getting over the neatness factor I wrote if in exactly
one way. if ($cond) { block }. I found that by doing so my code was not only
far more readable to other people in general it was readable by *ME* just a
few weeks later.

I think the same thing every time we get someone asking for do...until or
do...while. We have while. If I want exactly 1 run before the condition is
tested I can do that. It seems far clearer to me when I see...

x = 1
while x < 2:
x = foo()
print "done"

...what is going on than having to deal with someone putting:

do:
x = foo()
while x < 2:
print "done"

...or having to deal with people who will read my code and tell me "Ya
know, you should use a do...while here." "Why? It's just another form of
while." "Well, yeah, but it guarentees the loop performs once." "So?
Initilizing your variables does that, too."
[color=blue]
> I did this not because it was the most expressive but because I wanted to
> write code that others could follow, and indeed one of the praises I got was
> "wow! It's Perl code I can actually understand!"[/color]

Same here. The latest compliment was that upon seeing an example of
Python and PHP code that did the same thing that my code was "concise and
clear". It is because I code with consistent structure, not with expressive
structure.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Andrew Dalke]

Re: Too much builtins (was Re: Python's simplicity philosophy

Georgy Pruss:[color=blue]
> I guess, the same as for
> hex(30+44j)
> oct(3.1415926)[/color]
...

Which means you want
str(obj) -> result as usual; takes any object, returns a string, all
numbers
are represented in base 10
str(obj, [base=10]) -> converts integer objects (only!) to the given base,
defaults to base 10.

That feels wrong to me. Base conversion is enough of a special
case that it doesn't warrant being part of the standard str constructor.
As an 'int.to_base' method or class method, perhaps, but not in str.

Andrew
dalke@dalkescie ntific.com

[Donn Cave]

Re: Python's simplicity philosophy

In article <du765hi40vb.fs f@amadeus.cc.tu t.fi>,
Ville Vainio <ville.spammeha rdvainio@spamtu t.fi> wrote:
[color=blue]
> Lisp is too verbose for my tastes (I don't want to write 'let' ot
> 'setq'), doesn't have much in the way of libs and generally doesn't
> feel as 'right' as Python (I do use Emacs Lisp occasionally,
> though.. and will try out some CL one of these days). Dylan, OTOH,
> doesn't seem to be all that active a project, at least the last time I
> checked.[/color]

The current version of Gwydion Dylan http://www.gwydiondylan.org/
is a whole 2 months old, with a fairly good selection of supported
platforms.

Donn Cave, donn@u.washingt on.edu

[Gerrit Holl]

Re: Too much builtins (was Re: Python's simplicity philosophy

Andrew Dalke wrote:[color=blue]
> str(obj, [base=10]) -> converts integer objects (only!) to the given base,
> defaults to base 10.[/color]

Well, str could be defined as follows:

def str(obj, **kwargs):
return obj.__str__(**k wargs)

That doesn't feel too wrong to me.

yours,
Gerrit.

--
39. He may, however, assign a field, garden, or house which he has
bought, and holds as property, to his wife or daughter or give it for
debt.
-- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:

http://people.nl.linux.org/~gerrit/

Kom in verzet tegen dit kabinet:

http://www.sp.nl/

[Georgy Pruss]

Re: Too much builtins (was Re: Python's simplicity philosophy


"Andrew Dalke" <adalke@mindspr ing.com> wrote in message news:J4tub.4889 $sb4.2295@newsr ead2.news.pas.e arthlink.net...
| Georgy Pruss:
| > I guess, the same as for
| > hex(30+44j)
| > oct(3.1415926)
| ...
|
| Which means you want
| str(obj) -> result as usual; takes any object, returns a string, all
| numbers
| are represented in base 10
| str(obj, [base=10]) -> converts integer objects (only!) to the given base,
| defaults to base 10.
|
| That feels wrong to me. Base conversion is enough of a special
| case that it doesn't warrant being part of the standard str constructor.
| As an 'int.to_base' method or class method, perhaps, but not in str.
|
| Andrew
| dalke@dalkescie ntific.com

To me, it's very wrong that you can read any radix numbers, but can't
print them. If str(int(s)) == s and int(str(n)) == n (with some limits), I don't
see why str(n,radix) can't be symmetrical to int(s,radix).

BTW there's no symmetry for str() and list()/tuple()/dict() etc.

--
Georgy Pruss
E^mail: 'ZDAwMTEyMHQwMz MwQGhvdG1haWwuY 29t\n'.decode(' base64')

[Andrew Dalke]

Re: Too much builtins (was Re: Python's simplicity philosophy

Georgy Pruss:[color=blue]
> To me, it's very wrong that you can read any radix numbers, but can't
> print them. If str(int(s)) == s and int(str(n)) == n (with some limits), I[/color]
don't[color=blue]
> see why str(n,radix) can't be symmetrical to int(s,radix).[/color]

But your objection would also be handled with a special-case function
which only took an int/long and a base and returned the string
representation for that base, no? This could be a method or a class
method of int, or a new function in math. What makes it special enough
to warrant being part of the string constructor?
[color=blue]
> BTW there's no symmetry for str() and list()/tuple()/dict() etc.[/color]

There is a symmetry for str(float(s)) == s and str(complex(s)) == s.
Why shouldn't those take a base?

Well, almost symmetry. str(float("1.1" )) != "1.1"

Andrew
dalke@dalkescie ntific.com

[Georgy Pruss]

Re: Too much builtins (was Re: Python's simplicity philosophy


"Andrew Dalke" <adalke@mindspr ing.com> wrote in message news:eAxub.5080 $sb4.3591@newsr ead2.news.pas.e arthlink.net...
| Georgy Pruss:
| > To me, it's very wrong that you can read any radix numbers, but can't
| > print them. If str(int(s)) == s and int(str(n)) == n (with some limits), I
| don't
| > see why str(n,radix) can't be symmetrical to int(s,radix).
|
| But your objection would also be handled with a special-case function
| which only took an int/long and a base and returned the string
| representation for that base, no? This could be a method or a class
| method of int, or a new function in math.

I have such function already. :)

| What makes it special enough
| to warrant being part of the string constructor?

Just wanted to get rid of some useless builtin functions and make the
language prettier.

I wouldn't mind if Python had some analog of scanf() as an opposite
operator to '%'.

BTW is there some Python's equivalents to C's strspn, strcspn, strpbrk,
which return a leading sub-string, entirely [not] consisting of characters
of some char.set; and something like strtoul which parses the string and
returns the number and the position where the scan ended?

| > BTW there's no symmetry for str() and list()/tuple()/dict() etc.
|
| There is a symmetry for str(float(s)) == s and str(complex(s)) == s.
| Why shouldn't those take a base?
|
| Well, almost symmetry. str(float("1.1" )) != "1.1"

Fortunatelly, str() here is a bit wiser than repr().[color=blue][color=green][color=darkred]
>>> str(float("1.1" )) == "1.1"[/color][/color][/color]
True

Regarding the complex numbers, I guess the inconsistency with them
is to some extent the consequence of the fact that Python has no
complex literals (contrary to e.g. J) and the str(cmplx) returns some
expression in parenthesis instead of one complex number. So this
case is the same as with lists and other compound objects.

Georgy

| Andrew
| dalke@dalkescie ntific.com
|

[Andrew Dalke]

Re: Too much builtins (was Re: Python's simplicity philosophy

Georgy Pruss:[color=blue]
> Just wanted to get rid of some useless builtin functions and make the
> language prettier.[/color]

But I don't think that functions with special cases (and the special
case of 'takes a base but only if the first arg is an integer) is pretty.
As I've mentioned, I've not problems if hex/oct are moved to some
module in some future version of Python.
[color=blue]
> BTW is there some Python's equivalents to C's strspn, strcspn, strpbrk,
> which return a leading sub-string, entirely [not] consisting of characters
> of some char.set; and something like strtoul which parses the string and
> returns the number and the position where the scan ended?[/color]

Not directly. In Python those are most often done with regexps.
Eg,

import re
def strspn(s, t):
# kinda slow way to construct the pattern, but it does correctly
# handle the '-' and ']' cases. Usually one would write the regexp
# directly and not try to get close to the C API.
pat = re.compile("(" + "|".join(map(re .escape, t) + ")*")
m = pat.match(s)
if not m:
return 0
return m.end()

[color=blue]
> Fortunatelly, str() here is a bit wiser than repr().[color=green][color=darkred]
> >>> str(float("1.1" )) == "1.1"[/color][/color]
> True[/color]

Wiser? Or more approximate? IEE 754 math cannot explicitly
store the value "1.1".
[color=blue][color=green][color=darkred]
>>> str(1.100000000 0000001)[/color][/color][/color]
'1.1'[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]
[color=blue]
> Regarding the complex numbers, I guess the inconsistency with them
> is to some extent the consequence of the fact that Python has no
> complex literals (contrary to e.g. J) and the str(cmplx) returns some
> expression in parenthesis instead of one complex number. So this
> case is the same as with lists and other compound objects.[/color]

In some sense you are correct. Python doesn't have a complex
literal -- it only has an imaginary literal, so '1+2j' is implemented as

0 LOAD_CONST 1 (1)
3 LOAD_CONST 2 (2j)
6 BINARY_ADD

So I'll change my statement and point out that

str(complex("3j ")) == "3j"

(note the lack of parens) so the same symmetry you argue for
str/int should work for str/complex (though complex assumes
floats for the real and imaginary values, so it's more akin to the
str/float relationship.)

Andrew
dalke@dalkescie ntific.com

[Georgy Pruss]

Re: Too much builtins (was Re: Python's simplicity philosophy


"Andrew Dalke" <adalke@mindspr ing.com> wrote in message news:HdDub.5445 $sb4.4376@newsr ead2.news.pas.e arthlink.net...
| Georgy Pruss:
| > BTW is there some Python's equivalents to C's strspn, strcspn, strpbrk,
| > which return a leading sub-string, entirely [not] consisting of characters
| > of some char.set; and something like strtoul which parses the string and
| > returns the number and the position where the scan ended?
|
| Not directly. In Python those are most often done with regexps.
| Eg,
|
| import re
| def strspn(s, t):
| # kinda slow way to construct the pattern, but it does correctly
| # handle the '-' and ']' cases. Usually one would write the regexp
| # directly and not try to get close to the C API.
| pat = re.compile("(" + "|".join(map(re .escape, t) + ")*")
| m = pat.match(s)
| if not m:
| return 0
| return m.end()

Yes, thanks. Especially with regex'es it's just a matter of a minute or two.
I miss those C functions though.

G-:

| <...>
| Andrew
| dalke@dalkescie ntific.com

[Paul Rubin]

Re: Python's simplicity philosophy

"Andrew Dalke" <adalke@mindspr ing.com> writes:[color=blue]
> The 'against' side says, as you do, that having list.sort required
> to be stable now places an extra barrier to anyone else who
> implements a list-alike sort, because that sort should now also
> be stable.[/color]

It's also a barrier to anyone who implements list sort, not just
listalike sort. Of course that doesn't affect CPython or Jython
users, who already have a built-in stable list sort. But what about
PyPy or maybe someone trying to reimplement Python from scratch in C?
[color=blue]
> What mollifies the latter view is that some user-defined sorts
> won't have ties, so there will never be a problem.[/color]

I'm not a sorting whiz but my feeling is that if an application needs
sort to be stable, that's already a sign that something isn't really
right about it. Sorting is supposed to mean turning an unordered
permutation into an ordered one. So if list.sort gives you a useable
answer (i.e. one that satisfies your application's needs), then
randomizing the list and then sorting it should also give you a
useable answer. The way to do that is make your comparison function
look at every part of the record that you care about, not just select
some single field and count on stability to take care of the rest. If
at all possible, design the comparison function so that there are
never any ties. To do otherwise has in my experience been a source of
bugs that don't become evident til much later.

[Paul Rubin]

Re: Python's simplicity philosophy

"Andrew Dalke" <adalke@mindspr ing.com> writes:[color=blue]
> Do you want unix-style unique where repeats are merged into
> one, so that 1 2 2 1 -> 1 2 1 or do you want it to return[/color]

That list is not already sorted and so uniqing it should throw an
exception. Uniq should only have to work on sorted lists.

[Andrew Dalke]

Re: Python's simplicity philosophy

Paul Rubin:[color=blue]
> It's also a barrier to anyone who implements list sort, not just
> listalike sort. Of course that doesn't affect CPython or Jython
> users, who already have a built-in stable list sort. But what about
> PyPy or maybe someone trying to reimplement Python from scratch in C?[/color]

My recent statement on this hasn't changed -- this will affect
very few people, and the code to do a simple (perhaps not optimally
efficient for Python) sort is available in many books and libraries, so
should have very little influence on this decision.
[color=blue]
> I'm not a sorting whiz but my feeling is that if an application needs
> sort to be stable, that's already a sign that something isn't really
> right about it.[/color]

The standard example for stable sorts is in a spreadsheet-like
grid display where the ordering of the rows can be changed based
on the values in a given column (eg, by clicking on the column
header). Rows with column entries with the same value should
keep the same relative order, because that's what people expect.

Why? Because that lets the user define the sort order -- first
sort on tertiary key, then sort on secondary key, then sort on
primary key.
[color=blue]
> The way to do that is make your comparison function
> look at every part of the record that you care about, not just select
> some single field and count on stability to take care of the rest.[/color]

There are two answers to that. All non-stable sorts can be
turned into a stable sort by tacking on a final comparison based
on the original position. My spreadsheet example doesn't require
having a stable sort because I create my own. But then there's
the inelegance of creating a new list to store the original position,
and the extra dispatch needed to check that new field.

And if there isn't a stable sort, nor one induced by creating
an extra list, then what is the interface for creating the correct
comparison function? It could keep track of all the column
clicks, to know which ones are used as primary, secondary,
etc. sorts keys... but at some point it ends up with a tie
which cannot be resolved (in which case there's no problem)
or resolved by assuming the datatype of a given column.

For example, suppose I click on the 2nd column in

alpha 1
beta 2
beta 3
gamma 2
delta 2

There are ties with the three values of 2. The first column
can break the tie, but only by assuming that the first column
can be sorted alphabetically, to create

alpha 1
beta 2
delta 2
gamma 2
beta 3

I argue that the correct order should preserve the original
sort order, to create

alpha 1
beta 2
gamma 2
delta 2
beta 3

because the user's order is actually the alphabetical order of the
original greek alphabet, implicit in the original order of the data
file. (The user could click on the column header to resort for
that field, which would likely be done alphabetically, but at that
point that's the same as telling the computer to treat those fields
as english words, so sorting alphabetically is fine.)
[color=blue]
> If at all possible, design the comparison function so that there are
> never any ties. To do otherwise has in my experience been a source of
> bugs that don't become evident til much later.[/color]

I agree with that. But what to do when there are ties? I believe
people expect a stable sort (even without knowing what 'stable'
means) so it's helpful that Python's native sort be stable.

This is obviously a hard decision to make -- Python's sort has
been around for 10 years before this new requirement -- but I
don't think it's a poor one, and I've only seen theoretical
arguments for otherwise.

Andrew
dalke@dalkescie ntific.com