Xah Lee, 2010-01-26

Some notes of Wikipedia readings related to Python.

Unladen Swallow, a new project from Google. It is a new python
compiler with the goal of 5 times faster than the de facto standand
implementation CPython. Also note Stackless Python, which is already
been used in some major commercial projects.

Was looking into what's new in Python 3. See: http://docs.python.org/dev/3.0/whatsnew/3.0.html.
From a quick reading, i don't really like it. Here's some highlights:

    * Print is now a function. Great, much improvement.
    * Many functions that return lists now returns “Views” or
“Iterators” Instead. A fucking fuck all fucked up shit. A extraneous
“oop engineering” complication. (See: Lambda in Python 3000)
    * The cmp() function used in sort is basically gone, users are now
supposed to use the “key” parameter instead. This is a flying-face-
fuck to computer science. This would be the most serious fuckup in
python 3. (See: Sorting in Python and Perl)
    * Integers by default is long. Great!
    * Much more integrated unicode support, rewrite of most its text
or string semantics. Fantastic. Finally.

Am looking because i wonder if i should switch to python 3 for my own
few scripts, and rewrite my Python Tutorial for version 3. Am also
interested to know how python 3 is received by the computing industry.
Apparantly, a little search on the web indicates that vast majority of
python base have not switched, as expected, for many good reasons.
Vast majority of major python modules and tools have not switched.
Most linux distro have not switched, i don't find any large
corporation having adopted Python 3 (Google, Yahoo, Facebook,
NASA,... ). (sources: Source, Source) Basically, such a incompatible
change with trivial, ideological improvements, is too costy to switch.

I wonder, if by 2015, will most large corporate users have switched to
python 3. I give it a maybe. In today's Proliferation of Computing
Languages, such a major antic by Guido can just hurt itself. What is
he thinking? He of course thought himself as a god of lang designer,
who sincerely wants to push towards perfection, all future-looking.
Unfortunately, the tens of other major language designers all think
similarly.

perm archive of this post with possible updates here:
http://xahlee.org/comp/python3.html

Any comment on this?

  Xah
∑ http://xahlee.org/

I have no figures to base this on (just what I have read on the web),
but although the vast majority of comanies with big Python investments
are probably waiting for the 'critical mass' to use Python3 regularly
(oil-tanker effect), I would like to think that smaller operations are
experimenting with it more-and-more.

I think that for beginners who have dived into Python in the last 6-12
months (like me), it doesn't make sense to start with an older version.
I do not want to learn 'old' syntax and functions of a language, only to
have to learn the new versions when most developers upgrade to 3 - I
might as well learn the new syntax now and be ahead-of-the-game ;-) . I
know my choice of related packages (web-framework, ORM,
templating-engine) is very limited at present, but there are enough
branches and beta-versions around to help me with my learning-curve, and
I figure there will be some full-production-releases around by the time
I am 'fluent' with Python (12-18 months?).

Currently I am using Python 3.1 and CherryPy (3.20 rc1) every day, and
have had no serious problems (yet).

I would be interested to hear how other people are using Python 3, and
with what compatible packages.

* Alan Harris-Reid:

Probably there must have been some rationale, but to put it bluntly removing the
comparator is more like moronic than pythonic. If the rationale was efficiency,
then a rational solution could be to provide two sort methods, like 'sort' using
direct comparisions and 'custom_sort' using a specified comparator. Come to
think of it, that door is still open, except for the language spec freeze.

It's possible to work around the removal of 'cmp' in various kludgy ways, but
you shouldn't have to "work around" a library sort routine.

Nothing confuses the newbie or the now-and-then programmer so much as limited
range integers.

Well, perhaps floating point, but...

[snip]

Cheers,

So... many... jokes.....

Ad hominem attacks like you try above, just reflect on the one doing it.

Adding in some obviously false assertions just makes you look even worse.

And posting anonymously, well, that article's got it all.

Such attacks constitute noise and, except for how they reflect on you, only noise.

Cheers & hth.,

--
John Bokma                                                               j3b

Thanks for the heads-up.

Cheers,

--
John Bokma                                                               j3b

 > Am also

Guido never expected that working old apps would all be switched. There
is probably code still being run with 1.5 from 15 years ago. And there
will be 2.7 code running at least that far in the future.

Even before 3.0 was out, he also never expected major uptake until 3.2,
which is a year away. 3.0 was, well, a .0 release with a couple of .0
problems. 3.1 is pretty solid and modules are appearing for it.

 > i don't find any large

Of course there's a bit of a learning curve for those used to the old
ways, but in two years from now, I expect no-one will remember what the
fuss was about. Python 2.6 users will start their script with "from
__future__ import print_function", Python 2.7 users may not even need to
do that, and we'll all pity those stuck with 2.5 or 2.4.

There may be a handful of rare applications where there is no obvious way
to convert a cmp function to a key, but they are vanishingly rare. I
think, if you search the archives, Paul Rubin may have come up with one
example. There are a number of recipes for easily converting cmp sorts to
key sorts.

I think, in my perfect world, list.sort() and sorted() should continue
being key based, while the standard library contained (perhaps in the
functools module?) a sort function that contains all the bells and
whistles. You want cmp, it's there, and you can pay the extra cost if you
need it. You want to sort multiple lists by the contents of one? One
import away. But keep the general sort() function lean and super-fast.

    print (timestamp, 'transmogrified', blob)

for, while, if, try, break, yield, return

are all used for flow control, and should remain as statements. But print
is not -- it's a function disguised as a statement. print, after all, is
just sugar for stdout.write, which is fine as far as it goes, but when
you want to do something slightly different from what the sugar does, it
becomes terribly inconvenient.

A consequence of print being a statement is that my modules are often
filled with functions and methods called "print_". Suppose I want to
print the type of each argument as well as it's value. I would like to do
this:

def decorator(pr):
    def inner(*args, **kwargs):
         args = [(type(a), a) for a in args]
         pr(*args, **kwargs)
    return inner

print = decorator(print)

and then use print as normal, but of course I can't. So instead I do
something like this:

def print_(*args, **kwargs):
    args = [(type(a), a) for a in args]
    kw = {'file': sys.stdout, 'sep': ' ', 'end': '\n'}
    kw.update(kwargs)
    if len(kw) != 3:
        raise TypeError('invalid keyword argument')
    file = kw['file']
    sep = kw['sep']
    end = kw['end']
    for arg in args:
        print >>file, (str(arg) + sep),  # Don't forget the comma.
    print >>file, end,  # Another comma.

And then, I have to remember to call print_ instead of print.

    #include <stdio.h>

    main()
    {
      int i, x, p=0;
      x = ({ for (i=1; i<=10; i++) p += i; p;});
      printf ("x=%d\n", x);
    }

and C is certainly not a purely functional language.

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

Cheers,
Daniel

• DreamHost.com and A Incidence of Harassment
  http://xahlee.org/Periodic_dosage_dir/t2/harassment.html

• Why Can't You Be Normal?
  http://xahlee.org/Netiquette_dir/why_cant_you_be_normal.html

 Xah

On Jan 26, 7:12 pm, "Alf P. Steinbach" <al...@start.no> wrote:

“Iterators: Signs of Weakness in Object-Oriented Languages” (1992) By
Henry G Baker. http://home.pipeline.com/~hbaker1/Iterator.html

• Sorting in Python and Perl
  http://xahlee.org/perl-python/sort_list.html

the python lang, by the very nature of being a dynamic lang, makes it
hard for compiler analize and optimize a sort function call with cmp
argument that is equivalent to a key.

So, for practical reasons, i think a “key” parameter is fine. But
chopping off “cmp” is damaging. When your data structure is complex,
its order is not embedded in some “key”. Taking out “cmp” makes it
impossible to sort your data structure.

in the essay, i also gave a few examples of data structures where you
need a general means to specify the ordering function in order to
sort. Without a cmp, you'll need to munge your data by some decorate-
sort-dedecorate technique.

From another perspective, often it is considered a good principle of
design that the lang be a bit flexible to let programers do what they
want, instead of force them into one way. Python, being a loosely
typed lang, with so-called “duck typing”, in contrast to Java or OCaml
in different ways, certainly is more on the lose extreme of the lang
spectrum with respect to code construction. So, i don't see how python
3 people made the decision to removed cmp. (am pretty sure, at least
part of the reason, is a ill attitude towards functional programing
and lambda, lead by Guido.)

  Xah
∑ http://xahlee.org/

But 'print' calls that technically execute fine with both versions may and will
in general produce different results.

I.e. not just the syntax but also the semantics have changed:

 >>> import sys
 >>> sys.version
'2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
 >>>
 >>> print( "2+2 =", 2+2 )
('2+2 =', 4)
 >>> _

 >>> import sys
 >>> sys.version
'3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
 >>>
 >>> print( "2+2 =", 2+2 )
2+2 = 4
 >>> _

Cheers & hth.,

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

So again, what sort of an incompatibility are you talking about
concerning 'print' between 2.6 and 3.x?

Cheers,
Daniel

For example, it doesn't fix up 2.x code that prints tuples: incompatible, it
will still execute but no longer do what it was supposed to do.

But lest you focus down on that rare case, consider 2.x code that contains

   print "2+2", 2

All such statements need to be fixed up in a 2->3 transition. Adding __future__
just makes the code invalid, it doesn't give you any shred of compatibility for
this. A code rewrite can be partially automated like 2to3 but the
incompatibility needlessly introduces an additional set of things that Can Go
Wrong(TM), and with Murphy present, as He always is, well.

Cheers & hth.,