[ANN] mlabwrap-1.0.1 released

[Alexander Schmolck]

Mlabwrap allows pythonistas to interface to Matlab(tm) in a very
straightforward fashion:

>>> from mlabwrap import mlab
>>> mlab.eig([[0,1],[1,1]])
array([[-0.61803399],
   [ 1.61803399]])

More at .

Mlabwrap 1.0.1 is just a maintenance release that fixes a few bugs and
simplifies installation (no more LD_LIBRARY_PATH hassles).

'as

--
http://mail.python.org/mailman/listinfo/python-list

Re: Inefficient summing

[Alexander Schmolck]

beginner <[EMAIL PROTECTED]> writes:

> On Oct 9, 3:53 pm, Alexander Schmolck <[EMAIL PROTECTED]> wrote:
>> beginner <[EMAIL PROTECTED]> writes:
>> how about:
>>
>> ratio = (lambda c: c.real/c.imag)(sum(complex(r["F1"], r["F2"] for r in 
>> rec)))
>>
> Neat, but I will have a problem if I am dealing with three fields,
> right?

Sure but then how often do you want to take the ratio of 3 numbers? :) 

More seriously if you often find yourself doing similar operations and are
(legimately) worried about performance, numpy and pytables might be worth a
look. By "legitimately" I mean that I wouldn't be bothered by iterating twice
over rec; it doesn't affect the algorithmic complexity at all and I woudn't be
surprised if sum(imap(itemgetter("F1"),rec))/sum(imap(itemgetter("F2"),rec))
weren't faster than the explicit loop version for the cases you care about
(timeit will tell you). You're right that you loose some generality in not
being able to deal with arbitrary iterables in that case though.

'as
--
http://mail.python.org/mailman/listinfo/python-list

Re: Inefficient summing

[Alexander Schmolck]

beginner <[EMAIL PROTECTED]> writes:

> Hi All,
>
> I have a list of records like below:
>
> rec=[{"F1":1, "F2":2}, {"F1":3, "F2":4} ]
>
> Now I want to write code to find out the ratio of the sums of the two
> fields.
>
> One thing I can do is:
>
> sum(r["F1"] for r in rec)/sum(r["F2"] for r in rec)
>
> But this is slow because I have to iterate through the list twice.
> Also, in the case where rec is an iterator, it does not work.
>

how about:


ratio = (lambda c: c.real/c.imag)(sum(complex(r["F1"], r["F2"] for r in rec)))

? 

:)

--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literal syntax

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> A problem is that '1234' in Python is a string, so using ' in numbers
> looks a bit dangerous to me (and my editor will color those numbers as
> alternated strings, I think).

Yeah, editors, especially those with crummy syntax highlighting (like emacs)
might get it wrong. This should be easy enough to fix though. Indeed unlike
raw and tripplequoted strings which were adopted without major hitches this
new syntax wouldn't have any bearing on what's a valid string.

'as

--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literal syntax

[Alexander Schmolck]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Thu, 04 Sep 2008 01:22:22 +0100, Alexander Schmolck wrote:
>
>> It seems to me that the right choice for thousands seperator is the
>> apostrophe. 
>
> You mean the character already used as a string delimiter?

Yup. No ambiguity or problem here; indeed unlike space seperation or '_' it
would work straighforwardly as a syntax extension in pretty much any
programming language I can think as well as end-user output (I think that
writing e.g. 1'000'000 on a website would be perfectly acceptable; unlike
1_000_000).

'as

--
http://mail.python.org/mailman/listinfo/python-list

Re: Numeric literal syntax

[Alexander Schmolck]

Ben Finney <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] writes:
>
>> For Python 2.7/3.1 I'd now like to write a PEP regarding the
>> underscores into the number literals, like: 0b_0101_, 268_435_456
>> etc.
>
> +1 on such a capability.
>
> -1 on underscore as the separator.
>
> When you proposed this last year, the counter-proposal was made
> http://groups.google.com/group/comp.lang.python/msg/18123d100bba63b8?dmode=source>
> to instead use white space for the separator, exactly as one can now
> do with string literals.
>
> I don't see any good reason (other than your familiarity with the D
> language) to use underscores for this purpose, and much more reason
> (readability, consistency, fewer arbitrary differences in syntax,
> perhaps simpler implementation) to use whitespace just as with string
> literals.

It seems to me that the right choice for thousands seperator is the
apostrophe. It doesn't suffer from brittleness and editing problems as
whitespace does (e.g. consider filling and auto-line breaking). It is already
used in some locales for this function but never for the decimal point (so no
ambiguity, unlike '.' and ','). It also reads well, unlike the underscore
which is visually obstrusive and ugly (compare 123'456'890 to 123_456_789).

Having said that, I'd still have 123_456_789 over 123456789 any day. 

It's amazing that after over half a century of computing we still can't denote
numbers with more than 4 digits readably in the vast majority of contexts.

'as
--
http://mail.python.org/mailman/listinfo/python-list

Re: Programmatically exit the REPL

[Alexander Schmolck]

Without reading your post properly or having tried to do the same thing
myself: I think you might want to have a look at ipython; it gives a better
REPL and "embedding ipython" should give you plenty of hits as well.

Matthew Fitzgibbons <[EMAIL PROTECTED]> writes:

> I've got a pretty complex interactive command line program. Instead of writing
> my own REPL, I'm using the Python interpreter (an infinitely better solution).
> This program has two threads, a background thread and the REPL thread. When
> you call quit() or sys.exit() in the REPL thread, everything is perfectly
> happy. However, the background thread does some long-running jobs, and I want
> it to have the ability to exit the program when the job is complete. When I
> call quit() or sys.exit() from the background thread, the REPL merrily
> continues on its way.
>
> This is a very frustrating problem, so I'm hoping someone can shed some light
> on it. Am I missing something simple? Or is this just impossible? I don't see
> anything about breaking out of interact() in the code module docs.
>
>
> Here's a minimal example:
>
> #!/usr/bin/env python -i
> # You get the same behavior using code.interact()
>
> import sys
> import time
> import threading
>
> def end_the_program():
> # works if you call it from the REPL thread,
> # but not the background thread
> print "called end_the_program()"
> sys.exit()
> # quit() # using quit() rather than sys.exit()
>  # results in identical behavior
>
> keep_going = True
> def runner():
> while keep_going:
> time.sleep(0.1)
> end_the_program()
> threading.Thread(target=runner).start()
>
> # end example
>
>
> Here's the console session (edited for clarity):
>
> Desktop$ ./exit_repl.py
 keep_going = False
> called end_the_program()
> # notice we didn't exit here
 end_the_program()
> called end_the_program()
> # but we did exit here
> Desktop$
>
>
> -Matt

-- 
--
http://mail.python.org/mailman/listinfo/python-list

Re: python-mode is missing the class browser

[Alexander Schmolck]

"Adam Jenkins" <[EMAIL PROTECTED]> writes:

> On Fri, Aug 8, 2008 at 7:32 AM, Michele Simionato
> <[EMAIL PROTECTED]> wrote:
>> On Aug 7, 5:55 pm, Alexander Schmolck <[EMAIL PROTECTED]> wrote:
> ...
>>
>> I have solved by using ipython.el which was already installed. For the
>> sake of
>> future googlers using Ubuntu 8.04, emacs and ipython, it is enough if
>> you just add
>>
>> (setq ipython-command "/usr/bin/ipython")
>> (require 'ipython)
>>
>> to your .emacs. It is nice since I get the occasion to try ipython.el
>> which I am
>> sure I will like ;)
>
> So, I'm looking at the .el, but I'm not sure. What else does
> ipython.el give you than just the ipython shell?

What else could you possibly want? :)

Seriously, ipython.el is a simple kludge whose only function is to make
python-mode work with ipython (rather than python[*]). Despite this certain
primitiveness (c.f. slime), Emacs+ipython makes quite a powerful development
environment, significantly more so than ipython alone or emacs + python. Most
importantly thre is:

1. debug. Try it: write some code that will throw an unhandled exception, and
   just type ``debug``. Type ``u`` and ``d`` to go up and down the stack
   frame, and see the right file and line pop up in emacs. I really find that
   combined with the ability to do arbitrary things with the things I find on
   the stack incredibly useful for development. 

2. ? and ?? as well as ed. To get help on foo you just write ``foo?``. To get
   its source code as well type ``foo??``. Finally to edit the code that
   correspond's to foo's class or function definition (also works on class
   instances)) type ``ed foo`` (IIIRCk the default behavior is autoexecution,
   so you might want to re-alias).

3. Autocompletion with tab.

4. run (including -d and -p options). Try ``run?``

5. Matplotlib and gui stuff works interactively. (-pylab cmdline option)

6. Convenient Shell interaction (ls, !, int) and interpolation from and too
   python

7. Pretty printing.

But there's plenty more stuff. The most useful in terms of added functionality
via emacs is 1, but isearch and emacs editing power make the ipython shell
output also noticably more useful (and thus things like ?, ?? and pretty
printing).

cheers,

'as

[*] Inter alia the prompt parsing stuff needs to be different and the ansi
color formatting needs to be dealt with.
--
http://mail.python.org/mailman/listinfo/python-list

Re: python-mode is missing the class browser

[Alexander Schmolck]

Michele Simionato <[EMAIL PROTECTED]> writes:

> I have noticed that the python-mode for Emacs that comes with the
> latest Ubuntu is missing the class browser. Moreover if works
> differently from the python-mode I was used to (for instance CTRL-c-c
> works as CTRL-c-! whereas CTRL-c-! is missing, etc). How can I go back
> to the old python-mode
> or at least how do I get back the class browser?

There are two different and independently developedpython-modes. The
politically correct one that comes with emacs (IIRC python.el) that had pretty
limited functionality last time I looked, and the original but not FSF blessed
python-mode.el (http://sourceforge.net/projects/python-mode/), which should
come with install instructions. If you use ipython you might additionally
want to install ipython.el, which comes with the ipython tar ball.

cheers

'as
--
http://mail.python.org/mailman/listinfo/python-list

Re: how to indent/dedent a region in emacs?

[Alexander Schmolck]

Grant Edwards <[EMAIL PROTECTED]> writes:

> I've recently switched from Jed to Emacs for editing python
> source, and I'm still stumped as to how one indents or dedents
> a region of code.  In Jed it's 'C-c <' or 'C-c >'.  Google has
> found several answers, but none of them work, for example I've
> tried bot "C-c tab" and "C-c C-r" based on postings Google has
> found, but neither appears to actually _do_ anyting.

In python-mode C-c > and C-c <  should work as well.

(note that you have to download python-mode.el; I don't know if the above also
works with python.el which comes with emacs; C-h m will tell you which mode
you're using)

Outside python-mode, you can use string-rectangle and kill-rectangle, but
that's inconvenient, so I've globally bound the below functions to these keys
(you can just use the plain py-shift-region{-left,right} if you like them
better).


(defun my-py-shift-region-left (start end &optional count)
  "Like `py-shift-region-left', but COUNT applies the command repeatedly,
  instead of specifying the columns to shift."
  (interactive
   (let ((p (point))
(m (mark))
 (arg (* py-indent-offset (or current-prefix-arg 1
 (if m
  (list (min p m) (max p m) arg)
   (list p (save-excursion (forward-line 1) (point)) arg
  ;; if any line is at column zero, don't shift the region
  (save-excursion
(goto-char start)
(while (< (point) end)
  (back-to-indentation)
  (when (and (< (current-column) count)
 (not (looking-at "\\s *$")))
(error "Not enough left margin"))
  (forward-line 1)))
  (py-shift-region start end (- (prefix-numeric-value
  (or count
  (py-keep-region-active))


(defun my-py-shift-region-right (start end &optional count)
  "Like `py-shift-region-right', but COUNT applies the command repeatedly,
  instead of specifying the columns to shift." 
  (interactive
   (let ((p (point))
(m (mark))
 (arg current-prefix-arg))
 (if m
  (list (min p m) (max p m) arg)
   (list p (save-excursion (forward-line 1) (point)) arg
  (py-shift-region start end (prefix-numeric-value
   (or count py-indent-offset)))
  (py-keep-region-active))
  

'as
--
http://mail.python.org/mailman/listinfo/python-list

Re: Separators inside a var name

[Alexander Schmolck]

Rainy <[EMAIL PROTECTED]> writes:

> I have a stylistic question. In most languages words in var. name are
> separated by underscores or cap letters, resulting in var names like
> var_name, VarName and varName. I don't like that very much because all
> 3 ways of naming look bad and/or hard to type. From what I understand,
> scheme can have variables like var-name. I'm curious about reasons
> that python chose to disallow this. 

Legacy -- mathematical notation is broken and conflates negation and
subtraction (causing all sorts of annoyances including this one). Thus if you
want to be able to name a variable ``a-b`` you either have to write ``a - b``
to disambiguate subtracton from the variable name ``a-b`` or you need to chose
a different symbol for subtraction (writing "a ~ b" would likely be the best
choice).

> Another question I have is what other languages allow this naming scheme?

All lisps. Dylan. Rebol. Postscript. Forth. I'm sure there are a few others.

> Were there any languages that allowed space as a separator? 

Sure.

> What would be a practical way to separate variables from keywords in that
> case?

Lisp allows you to use pretty much anything in a variable name, you just have
to quote it, either 

 like\ this 

or

 |like this|


> "some long variable name", 'just a string', or maybe using 2 spaces: one var
> + other var + third var ? I think being able to easy have very long names
> for vars that are easy to type would be a fairly significant advantage.

I assume you haven't programmed too much? The problem with long names is that
they obscure structure, so they are only worthwhile for rarely used and fairly
obscure concepts where the added descriptiveness yields a net advantage.

> I know I'm probably being too obsessive about this, but that didn't stop me
> from posting. Comments?

I think you're right -- the common naming convention's suck and "python's" is
particularly bad (HtmlFrob HTMLFrob htmlFrob html_frob htmlfrob HTML_FROB
HTMLFROB -- which one will it be? No way to know without looking at the rest
of the code, the only consistency is that the last two are mostly used for
constants; everything else is completely up for grabs). You'd better get used
to it though, it's become "standardized".

'as
--
http://mail.python.org/mailman/listinfo/python-list

Re: is +=1 thread safe

[Alexander Schmolck]

Gary Herron <[EMAIL PROTECTED]> writes:

> The test was meant to simulate the OP's problem, but even with your suggestion
> of using numpy, it *still* fails!  

Well, although I haven't tested it extensively, it doesn't appear to fail for
me, with numpy 1.02 and an AMD Athlon(tm) XP 2800+ under linux 2.6, so it is
possible that numpy's implementation has changed wrt. to GIL usage (or that
the platform makes a difference, but that seems less likely):

In [26]: run ~/tmp/t.py
final count: 200
  should be: 200

In [27]: run ~/tmp/t.py
final count: 200
  should be: 200

In [28]: run ~/tmp/t.py
final count: 200
  should be: 200

In [29]: run ~/tmp/t.py
final count: 200
  should be: 200

In [30]: run ~/tmp/t.py
final count: 1000
  should be: 1000

I don't claim to have deep knowledge of threading/GIL issues under python, but
my understanding is that you can certainly write an extension that does this
atomically if required (although the bytecode for immutable and mutable is the
same, I think the problem in the immutable case is that the rebinding that
occurs after the inplaceadd step is to a new object, and hence not a no-op).
This isn't to distract from your and Aahz point downthread: this is inherently
a very brittle way to go about things. On the other hand if you have some
already dodgy legacy code (as the OP indicated) that you want to make work
with a minimum of fuzz, it might still be a reasonable option.

'as
--
http://mail.python.org/mailman/listinfo/python-list

Re: is +=1 thread safe

[Alexander Schmolck]

Gary Herron <[EMAIL PROTECTED]> writes:

> But... It's not!  
>
> A simple test shows that.   I've attached a tiny test program that shows this
> extremely clearly.  Please run it and watch it fail.

In [7]: run ~/tmp/t.py
final count: 200
  should be: 200

(I took the liberty to correct your test to actually do what I said, namely
use a numpy.array; just replace ``count = 0`` with ``import numpy; count =
numpy.array(0)``).


'as

p.s. please don't send me copies to on-list replies, at least not without
explicitly mentioning the fact -- I've got better things to do then guessing
whether something was meant to be off-list or not.
--
http://mail.python.org/mailman/listinfo/python-list

Re: is +=1 thread safe

[Alexander Schmolck]

AlFire <[EMAIL PROTECTED]> writes:

>> The threading module already has a function to return the number of Thread
>> objects currently alive.
>
> I have threads within threads - so it does not suit me :-(.

How about using a scalar numpy array? They are mutable, so I assume that x +=
1 should be atomic.

'as
--
http://mail.python.org/mailman/listinfo/python-list

Re: Calling a matlab script from python

[Alexander Schmolck]

n o s p a m p l e a s e <[EMAIL PROTECTED]> writes:

> Suppose I have a matlab script mymatlab.m. How can I call this script
> from a python script?

You could use .

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: best GUI library for vector drawing program

[Alexander Schmolck]

[x-posts removed]
chewie54 <[EMAIL PROTECTED]> writes:
> I should have also mentioned that is for a commercial application. That
> doesn't rule Qt or PyQt out, but this is a startup company with very little
> income so my first choice would be to use some GUI library that is free to
> use for commercial apps.

Check out the trolltech webpage: IIRC although it normally costs a few k$, you
can get it much cheaper if you are a startup (you yearly revenue must be lower
than 200k$ or something; this also only works once and maybe up to 2 licenses
or so etc). 

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fatest standard way to sum bytes (and their squares)?

[Alexander Schmolck]

Alexander Schmolck <[EMAIL PROTECTED]> writes:

> Erik Max Francis <[EMAIL PROTECTED]> writes:
>
>> Alexander Schmolck wrote:
>>
>>> Is this any faster?
>>>
>>>  ordSum, orsSumSq = (lambda c:c.real,c.imag)(sum(complex(ord(x),ord(x)<<1)
>>> for x in data))
>>
>> That's pretty clever, but I neglected to mention that I need to accumulate 
>> the
>> sums as ints/longs to avoid losing precision, so converting to floating point
>> isn't an optional.
>
> I think you can safely use this trick (provided it really makes things faster)
> provided you sum blocks no larger than 2**(53-8) bytes; 

Forgot about the squares; make this 2**(53-16); still pretty big.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: decorators - more than just syntactic sugar

[Alexander Schmolck]

Michele Simionato <[EMAIL PROTECTED]> writes:

> On Aug 11, 8:30 pm, Helmut Jarausch <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> are decorators more than just syntactic sugar in python 2.x and what
>> about python 3k ?
>
> Well, I argued may times that syntactic sugar is important (all Turing
> complete languages differs by syntactic sugar only)

Although I agree that "mere" syntactic sugar matters, I think you're
overstating the point. I would argue that most people would understand
syntactic sugar as equivalent to a (very) localized program transformation.
Things like first class continuations clearly aren't syntactic sugar in that
sense.



'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fatest standard way to sum bytes (and their squares)?

[Alexander Schmolck]

Erik Max Francis <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
>
>> Is this any faster?
>>
>>  ordSum, orsSumSq = (lambda c:c.real,c.imag)(sum(complex(ord(x),ord(x)<<1)
>> for x in data))
>
> That's pretty clever, but I neglected to mention that I need to accumulate the
> sums as ints/longs to avoid losing precision, so converting to floating point
> isn't an optional.

I think you can safely use this trick (provided it really makes things faster)
provided you sum blocks no larger than 2**(53-8) bytes; if your files are
really that big you'd certainly want to split summing into several blocks
anyway, because otherwise you'll be doing *lots* of extra bignum arithmetic
instead of int32/int64 addition (I'd assume this will slow things noticably
down even in python). Another trick you could try, again using table-lookup:
work on words (i.e. 2bytes) instead of single bytes again using a table (from
word->(byte-sum,sq-byte-sum) tuples) ; this will half the function calls and
the table size of is hopefully still small enough to not to ruin your
cache-hit rate (you might want to try array).

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fatest standard way to sum bytes (and their squares)?

[Alexander Schmolck]

Erik Max Francis <[EMAIL PROTECTED]> writes:

> For a file hashing system (finding similar files, rather than identical ones),
> I need to be able to efficiently and quickly sum the ordinals of the bytes of
> a file and their squares.  Because of the nature of the application, it's a
> requirement that I do it in Python, or only with standard library modules (if
> such facilities exist) that might assist.
>
> So far the fastest way I've found is using the `sum` builtin and generators::
>
>   ordinalSum = sum(ord(x) for x in data)
>   ordinalSumSquared = sum(ord(x)**2 for x in data)
>
> This is about twice as fast as an explicit loop, but since it's going to be
> processing massive amounts of data, the faster the better.  Are there any
> tricks I'm not thinking of, or perhaps helper functions in other modules that
> I'm not thinking of?

Is this any faster?

 ordSum, orsSumSq = (lambda c:c.real,c.imag)(sum(complex(ord(x),ord(x)<<1) 
 for x in data))

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the "functional" way of doing this?

[Alexander Schmolck]

beginner <[EMAIL PROTECTED]> writes:

> Hi,
>
> If I have a number n and want to generate a list based on like the
> following:
>
> def f(n):
>  l=[]
>  while n>0:
>  l.append(n%26)
>  n /=26
> return l
>
> I am wondering what is the 'functional' way to do the same.

This is very 'functional' (and also quite concise):

f = compose(list,partial(unfold, divmod(_,26)))

The definitions of compose, unfold, and _ are left as excercises (of
increasing difficulty) for the reader.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: bool behavior in Python 3000?

[Alexander Schmolck]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> Expressions like (i == j) used to return 0 and 1, and it was to avoid
> breaking hacks like the above that bools were implemented as a subclass of
> int, not because being able to write the above was a specific feature
> requested. In the hypothetical bright new world of Python with bools that
> are actually bools, the above are good cases for explicit being better than
> implicit:
>
> int(x < b) * f(x)
> -1 ** int(i == j)
>
> It makes more sense to explicitly cast bools to ints when you want to
> do integer arithmetic on them, rather than explicitly casting bools to
> bools to do boolean arithmetic! I feel strongly enough about this that I
> believe that being able to write (x < b) * f(x) is a DISADVANTAGE -- it
> gives me a real WTF moment to look at the code.

Just because it looks funny to you doesn't mean it is a hack. It turns out
that many mathemtical formulas can be written more clearly using this notation
(see e.g. at knuth et al's "concrete mathematics"), and in mathematics limited
and often ambiguous ad hoc notation that is neatly subsumed by this scheme is
widely established.

And I don't think adding int is an improvement: ``(x < b) * f(x)`` is plenty
clear (not easily misread as something else and, I believe, not even
particularly difficult to figure out even for mediocre python programmers) but
adding padding just obscures formula structure. Of course it doesn't in the
above examples with less than half a dozen terms, but IMO for something longer
the int-litter, even it may be soothing the psyches of the anally retentive,
is counterproductive.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tuple vs List: Whats the difference?

[Alexander Schmolck]

Shafik <[EMAIL PROTECTED]> writes:

> Hello folks,
>
> I am an experienced programmer, but very new to python (2 days). I
> wanted to ask: what exactly is the difference between a tuple and a
> list? I'm sure there are some, but I can't seem to find a situation
> where I can use one but not the other.

Try mutating the tuple or using the list as a hashkey.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: bool behavior in Python 3000?

[Alexander Schmolck]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> I mean, really, does anyone *expect* True+True to give 2, or that 2**True
> even works, without having learnt that Python bools are ints? I doubt it.

Sure, why not? It's pretty damn useful. Ever heard of things like "indicator
functions", "Iverson brackets" etc.? Mathematicians have long been using
broken and cumbersome ad hoc notations to be able to do stuff like
``(x> true+true

ans =

 2

so certainly people coming from matlab to scipy *will* often expect True+True
== 2.

I'd claim that even if it weren't for backwards compatibility, python bools
should behave exactly as they are -- for a language that assigns a truth value
to instances of any type, this is the right behavior. 

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Alexander Schmolck]

Douglas Alan <[EMAIL PROTECTED]> writes:

>> Python has built-in abstractions for a few container types like
>> lists and dicts, and now a new and more general one (iterators), so
>> it's the next level up.
>
> Common Lisp has had all these things for ages.

Rubbish. Do you actually know any common lisp?

There is precisely no way to express

for x in xs:
blah(x)

or
x = xs[key]

in either scheme or CL, which is a major defect of both language (although
there has been a recent and limited proposal for sequence iteration by c.
rhodes which is implemented as an experimental extension in sbcl). This is
stuff even C++, which is about the lowest-level language anyone uses for
general purpose programming these days has been able to express for decades
(modulo foreach syntax).

In a decent scheme it's easy enough to define your own collection
class/iteration protocol, which does allow you to do something like the above,
but of course only for container abstractions that you have some control over
yourself. Even in this limited sense you can forget about doing this in CL in
a way that meshes nicely with the existing primitives (inter alia because of
spurious inconsistencies between e.g. sequence and hash-access and
under-specification of the exception hierachy) and anything as expressive as
generators/coroutines in CL with reasonable effort and performance which won't
even allow you to write LOOPs over custom container types (the nonstandard
ITERATE package has limited support for this).

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Alexander Schmolck]

"Anders J. Munch" <[EMAIL PROTECTED]> writes:

> Like Steven said, tail-call optimisation is not necessary as you can always
> hand-optimise it yourself.

Care to demonstrate on some code written in CPS (a compiler or parser, say)?

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Alexander Schmolck]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Mon, 11 Jun 2007 01:28:09 +0100, Alexander Schmolck wrote:
>
>> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>> 
>>> On Sat, 09 Jun 2007 22:42:17 +0100, Alexander Schmolck wrote:
>>>
>>>>> As for why tail calls are not optimized out, it was decided that being 
>>>>> able
>>>>> to have the stack traces (with variable information, etc.) was more useful
>>>>> than offering tail call optimization
>>>> 
>>>> I don't buy this. 
>>>
>>> Do you mean you don't believe the decision was made, or you don't agree
>>> with the decision?
>> 
>> Neither. I don't believe the rationale stated in this thread to be the true
>> reason.
>
>
> Don't keep us in suspense. What do you believe is the true reason?

It's easier to spot that some rationalization is bogus than to unconver the
true underlying causes; I'm pretty sure it's more a Gestalt thing than a
compelling technical reason (I guess Guido's distaste for scheme also plays a
role). Not that I discount that out of hand -- maybe all that's great about
python is due to Guido being exceptionally good at making such judgements.



>>> Are you volunteering? If you are, I'm sure your suggestion will be welcomed
>>> gratefully.
>> 
>> I rather doubt it. Guido has stated quite clearly that his not
>> interested in incorporating this feature.
>
> He's not the only one who gets to make these decisions. 

This is news to me. Who else does?

> But even if he uses his veto to prevent tail-recursion optimization from
> being put into the main branch, there are other options.

That don't involve abducting his kids?

>>>>> (do what I say).
>>>> 
>>>> Where did you say run out of memory and fail? More importantly how do
>>>> you say "don't run out of memory and fail"?
>>>
>>> If we can live with a certain amount of "arbitrary failures" in simple
>>> arithmetic,
>> 
>> I prefer not too, and thus when possible avoid to use languages where
>> ``a + b`` is liable to fail arbitrarily (such as C, where the behavior
>> will often be undefined).
>
> That's not the sort of arbitrary failure I was discussing, but for that
> matter Python is one of those languages. 

Apart from floating point arithmetic, simple arithmetic doesn't tend to fail
arbitrarily in python, as far as I'm aware. You can of course create your very
own classes specifically to get broken arithmetic but that doesn't strike me
as "simple" arithmetic anymore.

> Perhaps Python is not the language for you?

Do you also happen to know what would be?

> Correct me if I'm wrong, but surely it is C++ that can have arbitrary
> behaviour for "a + b", not C?

``INT_MAX + 1`` can do precisely anything in C.

>>> You can always hand-optimize it yourself.
>> 
>> Not tail calls, in general, no.
>
> Sorry, how does that work? You're suggesting that there is an algorithm
> which the compiler could follow to optimize away tail-recursion, but human
> beings can't follow the same algorithm? Now I'm confused.

Does it also confuse you that if I give you a 500x500 matrix A you won't be
able to figure out a single element in A^-1 by doing mental arithmetic (or
using pen and paper), although my computer manages just fine and I'm happy to
give you the algorithm it uses?

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Alexander Schmolck]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Sat, 09 Jun 2007 22:42:17 +0100, Alexander Schmolck wrote:
>
>>> As for why tail calls are not optimized out, it was decided that being able
>>> to have the stack traces (with variable information, etc.) was more useful
>>> than offering tail call optimization
>> 
>> I don't buy this. 
>
> Do you mean you don't believe the decision was made, or you don't agree
> with the decision?

Neither. I don't believe the rationale stated in this thread to be the true
reason.

> Are you volunteering? If you are, I'm sure your suggestion will be welcomed
> gratefully.

I rather doubt it. Guido has stated quite clearly that his not interested in
incorporating this feature.
  
>>> (do what I say).
>> 
>> Where did you say run out of memory and fail? More importantly how do
>> you say "don't run out of memory and fail"?
>
> If we can live with a certain amount of "arbitrary failures" in simple
> arithmetic,

I prefer not too, and thus when possible avoid to use languages where ``a +
b`` is liable to fail arbitrarily (such as C, where the behavior will often be
undefined).

> then the world won't end if tail recursion isn't optimized away by the
> compiler.

I'd personally much rather have arithmetic working properly. Unfortunately
this is not an option at the moment, although quite a few smart people are
working on it and although it is an immensely costly problem.

> You can always hand-optimize it yourself.

Not tail calls, in general, no.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Alexander Schmolck]

Josiah Carlson <[EMAIL PROTECTED]> writes:

> James Stroud wrote:
>> Terry Reedy wrote:
>>> In Python, you have a choice of recursion (normal or tail)
>>
>> Please explain this. I remember reading on this newsgroup that an advantage
>> of ruby (wrt python) is that ruby has tail recursion, implying that python
>> does not. Does python have fully optimized tail recursion as described in
>> the tail recursion Wikipedia entry? Under what circumstances can one count
>> on the python interpreter recognizing the possibility for optimized tail
>> recursion?
>
> Note that Terry said that you could do normal or tail recursion, he didn't
> claim that either were optimized.  

Well yeah, but without the implication how do the two words "or tail" add to
the information content of the sentence?

> As for why tail calls are not optimized out, it was decided that being able
> to have the stack traces (with variable information, etc.) was more useful
> than offering tail call optimization

I don't buy this. What's more important, making code not fail arbitrarily (and
thus making approaches to certain problems feasible that otherwise wouldn't
be) or making it a be a bit easier to debug code that will fail arbitrarily?
Why not only do tail-call optimization in .pyo files and get the best of both
worlds?

> (do what I say).

Where did you say run out of memory and fail? More importantly how do you say
"don't run out of memory and fail"?

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: matplotlib, usetex

[Alexander Schmolck]

Bill Jackson <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote the following on 05/25/2007 02:33 PM:
>> I have no idea whether this will resolve your problem, but you could try
>> updating to 0.90 (BTW what happens if you do axis([0,128,0,128])).
>
> The problem appears to be with a matplotlibrc file.  If I delete the
> matplotlibrc file, then I am able to plot perfectly.  Thus, it appears that I
> am unable to specify usetex from my configuration file.  Why is this
> happening?
>
>  ~/.matplotlib/matplotlibrc 
> text.usetex   : True
>
>  test.py 
> import matplotlib
> import pylab
> matplotlib.rc('text', usetex=True)

I think it might be a good habit to develop to call ``rc`` before ``import
pylab`` -- some things won't take effect otherwise (this doesn't affect all
parameters and will likely be eventually fixed in general, but notably it does
currently affect some latex-related stuff, such as font choice).

> pylab.plot(range(10))
> pylab.show()
>
>
> Running 'python test.py' with the above matplotlibrc causes the errors in my
> original post.  Deleting matplotlibrc resolves the problem.

I can't see any problem with you matplotlibrc; what happens if you swap around
the lines as I suggested above? Maybe it just appears to work, because the
usetex really does have no affect above, and you really are not using latex?

I have been using matplotlib with latex for fonts handling for some time now
(and I've even submitted a patch to ameliorate the rc problem mentioned
above), but the latex stuff has changed somewhat over time, and still has some
rough edges -- so for not immediately obvious problems with the latex handling
of an older version of matplotlib you're much more likely to find someone who
has the relevant details mentally available on the matplotlib-disc list are
much better than here; so I'd recommend you give it a try again (yeah sf is a
pain).

cheers,

'as



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: matplotlib, usetex

[Alexander Schmolck]

Bill Jackson <[EMAIL PROTECTED]> writes:

>
> The problem does not exist when text.usetex is False.  Ideas?

I have no idea whether this will resolve your problem, but you could try
updating to 0.90 (BTW what happens if you do axis([0,128,0,128])).

cheers,

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lists vs tuples (newbie)

[Alexander Schmolck]

Szabolcs <[EMAIL PROTECTED]> writes:

> Thanks for all the replies!
>
> Phoe6 wrote:
>> 1) Return values from a function.  When you return multiple values
>> from a function. You store them as a tuple and access them
>> individually rather then in the list, which bear the danger of being
>> modified.
>> Look up the standard library itself and you will find many instances.
>>
>> (cin, cout, cerr) = os.popen3('man man')
>>
>> If you had the above as list, then you might end up spoiling things
>> knowingly/unknowingly.
>
> Could you please elaborate on this (or give an explicit example how might one
> do something bad unknowingly when returning multiple values in a list)?


def f(input, defaultAnswer=[1,2,3]):
if input == 1: return (4,5,6)
else: return defaultAnswer

print f(0).pop(), f(0).pop(), f(0).pop(), f(0)


But that's a pretty pathological; just using unstructuring as in the open
example above nothing bad can happen.

>
> Should I think of tuples simply as a safeguard and reminder (because I
> consciously use them for different thing than lists, as the faq suggests)?

Use them for hetoerogeneous data or when you need the immutability (so that
people can't screw)

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Alexander Schmolck]

Neil Hodgson <[EMAIL PROTECTED]> writes:

> Paul Rubin wrote:
>>> Plenty of programming languages already support unicode identifiers, 
>>
>> Could you name a few?  Thanks.
>
>C#, Java, Ecmascript, Visual Basic.

(i.e. everything that isn't a legacy or niche language)

scheme (major implementations such as PLT and the upcoming standard), the most
popular common lisp implementations, haskell[1], fortress[2], perl 6 and I 
should
imagine (but haven't checked) all new java or .NET based languages (F#,
IronPython, JavaFX, Groovy, etc.) as well -- the same goes for XML-based
languages.

(i.e. everything that's up and coming, too)

So as Neil said, I don't think keeping python ASCII and interoperable is an
option. I don't happen to think the anti-unicode arguments that have been
advanced so far terribly convincing so far[3], but even if they were it
wouldn't matter much -- the ability of functioning as a painless glue language
has always been absolutely vital for python.

cheers

'as

Footnotes: 
[1]  

[2]  

[3]  Although I do agree that mechanisms to avoid spoofing and similar
 problems (what normalization scheme and constraints unicode identifiers
 should be subjected to) merit careful discussion.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Alexander Schmolck]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments
> to the PEP included below, either here (comp.lang.python), or to
> [EMAIL PROTECTED]
>
> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").
>
> I believe this PEP differs from other Py3k PEPs in that it really
> requires feedback from people with different cultural background
> to evaluate it fully - most other PEPs are culture-neutral.
>
> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? 

Yes.

> why?

Because not everyone speaks English, not all languages can losslessly
transliterated ASCII and because it's unreasonable to drastically restrict the
domain of things that can be conveniently expressed for a language that's also
targeted at a non-professional programmer audience.

I'm also not aware of any horror stories from languages which do already allow
unicode identifiers.

> - would you use them if it was possible to do so? 

Possibly.

> in what cases?

Maybe mathematical code (greek letters) or code that is very culture and
domain specific (say code doing Japanese tax forms).

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Alexander Schmolck]

Jarek Zgoda <[EMAIL PROTECTED]> writes:

> Martin v. Löwis napisał(a):
>
>> So, please provide feedback, e.g. perhaps by answering these
>> questions:
>> - should non-ASCII identifiers be supported? why?
>
> No, because "programs must be written for people to read, and only
> incidentally for machines to execute". Using anything other than "lowest
> common denominator" (ASCII) will restrict accessibility of code. This is
> not a literature, that requires qualified translators to get the text
> from Hindi (or Persian, or Chinese, or Georgian, or...) to Polish.
>
> While I can read the code with Hebrew, Russian or Greek names
> transliterated to ASCII, I would not be able to read such code in native.

Who or what would force you to? Do you currently have to deal with hebrew,
russian or greek names transliterated into ASCII? I don't and I suspect this
whole panic about everyone suddenly having to deal with code written in kanji,
klingon and hieroglyphs etc. is unfounded -- such code would drastically
reduce its own "fitness" (much more so than the ASCII-transliterated chinese,
hebrew and greek code I never seem to come across), so I think the chances
that it will be thrust upon you (or anyone else in this thread) are minuscule.


Plenty of programming languages already support unicode identifiers, so if
there is any rational basis for this fear it shouldn't be hard to come up with
-- where is it?

'as

BTW, I'm not sure if you don't underestimate your own intellectual faculties
if you think couldn't cope with greek or russian characters. On the other hand
I wonder if you don't overestimate your ability to reasonably deal with code
written in a completely foreign language, as long as its ASCII -- for anything
of nontrivial length, surely doing anything with such code would already be
orders of magnitude harder?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Emacs and pdb after upgrading to Ubuntu Feisty

[Alexander Schmolck]

levander <[EMAIL PROTECTED]> writes:

> Okay, thanks Alexander and Bernstein.  I'll lookinto Emacs 23, but I'm
> worried about compatibility with modes.  Does all the stuff that works
> in Emacs 21 work in 23?  

I've switched from 21 to 23 a few weeks ago and don't recall any particular
issues (and I'm a fairly hardcore emacs user with pretty complex configuration
and many third-party packages -- my emacs config has 182 matches for
require\|autoload).

> Like even that ipython.el file, does it work in Emacs 23? 

I think as the author I would have noticed by now if it didn't :)

> And, I probably will report a bug to either Ubuntu's Launchpad or to
> Debian's package maintainer for pdb mode (which apparently has been
> integrated into just the gud mode stuff, at least that's how it looks from
> looking around on my system). Does Debian have a web site for reporting bugs
> like Ubuntu does? Or, do I just email the package maintainer?
>
> I'm messing around with ipython.el and ipython now.  It looks like if
> you just want to step through some code that isn't throwing any
> execption, you have to modify the source code of your script to tell
> ipython to stop on this line and start debugging here? 

Nope. Try  ``run -d myscript`` (and ``?run`` for more info). 

I must admit that this doesn't work properly for me though -- I don't get
stepping through the corresponding source in emacs. ``M-x pdb`` works with pdb
as debugger but not with pydb; maybe the problem is missing pydb support in
the relevant regexps?

I can't devote any time to this at the moment, but I'd be pretty interested in
having this working -- so I'd appreciate a note if someone figures out what's
going on (and if a change to ipython.el is needed I'll make sure it gets in).

> With all the raving about ipython, I'm sure it's a great product. But, this
> thing about having to modify your source code really sounds like it sucks.
> I'd be surprised if it were difficult to implement a command line option for
> ipython that tells it to open this file and then start debugging it from the
> top. 

It's already there -- I'm using 0.7.4 svn (which is the ubuntu feisty
package), so I think it should also work for you.

> And, have the emacs mode operate much like it does with pdb, where emacs
> remembers your command line when you invoked pdb, so you just hit "M-x pdb
> RET RET RET ..." to open up your file. But, maybe I just haven't foud it
> yet?

I'd type something like ``run -+`` (with M-p bound
to `comint-previous-matching-input-from-input') or M-r, which is even fewer
keystrokes.

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Emacs and pdb after upgrading to Ubuntu Feisty

[Alexander Schmolck]

levander <[EMAIL PROTECTED]> writes:

> Anybody can tell me who to get pdb working under emacs on Ubuntu
> Feisty?

This is not a direct answer to your question, but I'd recommend you try
ipython (apt-get'able) and ipython.el; (manual install). Just enter ``pdb on``
in the interactive shell to end up in the debugger on errors and the
corresponding file and line is opened in emacs.

BTW, I'd also suggest to upgrade to emacs-snapshot (23 alpha -- but don't be
overly worried -- seems more stable than 21. to me so far), for one thing you
get decent (ttf) fonts:



'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: List objects are un-hashable

[Alexander Schmolck]

Andy <[EMAIL PROTECTED]> writes:

> Hi, I'm trying to search and print any no# of Python keywords present
> in a text file (say - foo.txt), and getting the above error. Sad for
> not being able to decipher such a simple problem (I can come up with

Without looking at the docs, it seems save to assume keywords.iskeyword would
expect a string. You pass it a list.

> other ways - but want to fix this one FFS). Any help is appreciated.
> Thanks!!
>
> import keyword, re, sys, string
> inp = open("foo.txt", "r")
  words = sum(1 for line in inp for w in line.split() if keyword.iskeyword(w))

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] mlabwrap-1.0final

[Alexander Schmolck]

Stef Mientki <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> > I'm pleased to finally announce mlabwrap-1.0:
> > Project website
> 
> > ---
> > <http://mlabwrap.sourceforge.net/>
> > Description
> 
> > ---
> > Mlabwrap-1.0 is a high-level python to matlab(tm) bridge that makes calling
> 
> > matlab functions from python almost as convenient as using a normal python
> > library. It is available under a very liberal license (BSD/MIT) and should
> > work on all major platforms and (non-ancient) python and matlab versions and
> > either numpy or Numeric (Numeric support will be dropped in the future).
> >
> 
> 
> Probably quit a large and nice job, to embed MatLab in Python.

Actually, it's not much code -- mlabwrap.py is less than 500 lines of code.

> But, I've the idea I'm missing something ... ... coming from MatLab, a few
> months ago I tried Python, ... and at the moment I've decided to move
> completely from MatLab to Python. All new programs will be written in Python
> and the old programs will be translated.
> 
> Is my decision wrong ?

Depends on your circumstances, but in many cases just switching to a different
language and rewriting everything from scratch (possibly even at a single go,
if there are many interdependencies) isn't practical. Mlabwrap help here,
because it allows you to either migrate piecemeal or mix and match (i.e.
mostly use python, resorting to matlab libraries where necessary).
 
> What can do MatLab, that can't be done in Python (SciPy) ?
> (Ok I accept there's no SimuLink/PowerSim).

There are plenty of commercial and free libraries and environments for matlab
that have seen considerable development by domain experts don't have a
comparable python equivalent. I'm currently sitting in a cafe in Berkeley,
because researchers at the universities of Berkeley and Cambridge are
interested in doing their neuroimaging analysis in python, but still need to
interface to existing matlab packages like SPM.

> Both environments can create any program you like.

Not really.

> If MatLab is your standard / favorite why not stick to MatLab ?

Because matlab is much limited as a programming language once you stray
outside linear algebra. Many people also seem to be unhappy about licencing
issues . Finally, how often did matlab crash on you? And python?
 
> Please enlighten me.

My pleasure.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] mlabwrap-1.0final

[Alexander Schmolck]

I'm pleased to finally announce mlabwrap-1.0:

Project website
---
<http://mlabwrap.sourceforge.net/>


Description
---

Mlabwrap-1.0 is a high-level python to matlab(tm) bridge that makes calling
matlab functions from python almost as convenient as using a normal python
library. It is available under a very liberal license (BSD/MIT) and should
work on all major platforms and (non-ancient) python and matlab versions and
either numpy or Numeric (Numeric support will be dropped in the future).


Examples


Creating a simple line plot:

>>> from mlabwrap import mlab; mlab.plot([1,2,3],'-o')

Creating a surface plot:

>>> from mlabwrap import mlab; from numpy import *
>>> xx = arange(-2*pi, 2*pi, 0.2)
>>> mlab.surf(subtract.outer(sin(xx),cos(xx)))

Creating a neural network and training it on the xor problem (requires netlab)

>>> net = mlab.mlp(2,3,1,'logistic')
>>> net = mlab.mlptrain(net, [[1,1], [0,0], [1,0], [0,1]], [0,0,1,1], 1000)

What the future holds
-

Please note that mlabwrap-1.0 will be the last non-bugfix release with Numeric
support. Future versions of mlabwrap will require numpy be a part of scipy's
scikits infrastructure (so the package name will be ``scikits.mlabwrap``) and
use setuptools rather than distutils so that it should be possible to
automatically download and install via EasyInstall.

The next major version of mlabwrap should also bring more powerful proxying
and marshalling facilities, but the default conversion behavior might be
changed to reflect the fact that matlab is becoming increasingly less
``double`` (-matrix) centric; although wrappers for old-style behavior will be
provided if backwards-incompatible interface changes are introduced, for
upwards compatibility it is recommended to explicitly pass in float64 arrays
rather than e.g. lists of ints if the desired input type that matlab should
see is a double array (i.e. use ``mlab.sin(array([1., 2., 3.])`` rather than
``mlab.sin([1,2,3])`` for production code in order to be on the safe side)).
Please have a look at <http://www.scipy.org/Mlabwrap> if you're interested in
the ongoing development of mlabwrap and planned features.


Feedback and support


The preferred formum for users to request help and offer feedback and keep
informed about new releases is mlabwrap-user:

 <https://lists.sourceforge.net/lists/listinfo/mlabwrap-user>

the list is low-volume and subscription is recommended.

Discussion of mlabwrap development takes place on the scipy-dev (please
mention mlabwrap in the subject line):

 <http://projects.scipy.org/mailman/listinfo/scipy-dev> 

cheers,

Alexander Schmolck, mlabwrap author and maintainer
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: itertools, functools, file enhancement ideas

[Alexander Schmolck]

[EMAIL PROTECTED] (Alex Martelli) writes:

> > 4. functools enhancements (Haskell-inspired):
> >Let f be a function with 2 inputs.  Then:
> >   a) def flip(f): return lambda x,y: f(y,x)
> >   b) def lsect(x,f): return partial(f,x)
> >   c) def rsect(f,x): return partial(flip(f), x)
> > 
> >lsect and rsect allow making what Haskell calls "sections".  Example:
> >   # sequence of all squares less than 100
> >   from operator import lt
> >   s100 = takewhile(rsect(lt, 100), (x*x for x in count()))
> 
> Looks like they'd be useful, but I'm not sure about limiting them to
> working with 2-argument functions only.

How's

from mysterymodule import resect
from operator import lt
takewhile(rsect(lt, 100), (x*x for x in count()))

better than 

takewhile(lambda x:x<100, (x*x for x in count()))

Apart from boiler-plate creation and code-obfuscation purposes?

'as




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: block scope?

[Alexander Schmolck]

Neal Becker <[EMAIL PROTECTED]> writes:

> One thing I sometimes miss, which is common in some other languages (c++),
> is idea of block scope.  It would be useful to have variables that did not
> outlive their block, primarily to avoid name clashes.  This also leads to
> more readable code.  

I have on occassion used lambda as a poor-man's let, but only if I needed to
avoid multiple evaluation:

 res = (lambda x=blah(...), y=blahz(...):  f(x*y,x+y))()

I'm sure most people would debate it's more readable, but it's IMO superior to
cleaning up manually with ``del``. I sometimes also find it useful to avoid
cluttering up the interactive shell.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: String manipulation

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> On 4 Apr, 21:47, Alexander Schmolck <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] writes:
> > > Thank you very much, your code works perfectly!
> >
> > One thing I forgot: you might want to make the whitespace handling a bit 
> > more
> > robust/general e.g. by using something along the lines of
> >
> >   set_phrase.replace(' ', r'\w+')

Oops, sorry I meant r'\s+'.

> >
> > 'as
> 
> Hi!
> Thanks again... But where must I insert this instruction?

If you're sure the code already does what you want you can forget about my
remark; I was thinking of transforming individual patterns like so: 'kindest
regard' -> r'kindest\w+regard', but it really depends on the details of your
spec, which I'm not familiar with.

For example you clearly want to do some amount of whitespace normalization
(because you use ``.strip()``), but how much? The most extreme you could go is

 input = " ".join(file.read().split()) # all newlines, tabs, multiple spaces -> 
" "

In which case you don't need to worry about modifying the patterns to take
care of possible whitespace variations. Another possibility is that you
specify the patterns you want to replace as regexps in the file e.g. 

 \bkind(?:est)?\b\s+regard(?:s)?\b
 \byours,\b
 ...

In any case I'd suggest the following: think about what possible edge cases
your input can contain and how you'd like to handle then; then write them up
as unittests (use doctest or unittest and StringIO) and finally modify your
code until it passes all the tests. Here are some examples of possible test
patterns:


- """kindest regard,"""
- """kindest regard"""
- """kindest\tregard"""
- """kind regards"
- """mankind regards other species as inferior"""
- """... and please send your wife my kindest
  regards,"""

Finally, if you're looking for a programming excercise you could try the
following: rather than working on strings and using regexps, work on a
"stream" of words (i.e. ["kindest", "regards", ...]) and write your own code
to match sequences of words.

'as

p.s. BTW, I overlooked the ``.readlines()`` before, but you don't need it --
files are iterable and you also want to hang on to the openend file object so
that you can close it when you're done.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: String manipulation

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> Thank you very much, your code works perfectly!

One thing I forgot: you might want to make the whitespace handling a bit more
robust/general e.g. by using something along the lines of

  set_phrase.replace(' ', r'\w+')

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: String manipulation

[Alexander Schmolck]

Alexander Schmolck <[EMAIL PROTECTED]> writes:

> That doesn't work. What about "kindest\nregard"? I think you're best of
> reading the whole file in (don't forget to close the files, BTW).

I should have written "that may not always work, depending of whether the set
phrases you're interested in can also span lines". If in doubt, it's better
to assume they can.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: String manipulation

[Alexander Schmolck]

All the code is untested, but should give you the idea. 

[EMAIL PROTECTED] writes:

> Hi all!
> 
> I have a file in which there are some expressions such as "kindest
> regard" and "yours sincerely". I must create a phyton script that
> checks if a text contains one or more of these expressions and, in
> this case, replaces the spaces in the expression with the character
> "_". For example, the text
> 
> Yours sincerely, Marco.
> 
> Must be transformated in:
> 
> Yours_sincerely, Marco.
> 
> Now I have written this code:
> 
> filemw = codecs.open(sys.argv[1], "r", "iso-8859-1").readlines()
> filein = codecs.open(sys.argv[2], "r", "iso-8859-1").readlines()
> 
> mw = ""
> for line in filemw:
>   mw = mw + line.strip() + "|"

One "|" too many. Generally, use join instead of many individual string +s.

mwfind_re_string = "(%s)" % "|".join(line.strip() for line in filemw)

> mwfind_re = re.compile(r"^(" + mw + ")",re.IGNORECASE|re.VERBOSE)


mwfind_re = re.compile(mwfind_re_string),re.IGNORECASE)
 
> mwfind_subst = r"_"
> 
> for line in filein:

That doesn't work. What about "kindest\nregard"? I think you're best of
reading the whole file in (don't forget to close the files, BTW).


>   line = line.strip()
>   if (line != ""):
>   line = mwfind_re.sub(mwfind_subst, line)
>   print line
> 
> It correctly identifies the expressions, but doesn't replace the
> character in the right way. How can I do what I want?

Use the fact that you can also use a function as a substitution.

print mwfind_re.sub(lambda match: match.group().replace(' ','_'), 
"".join(line.strip() for line in filein))

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: zip list with different length

[Alexander Schmolck]

MC <[EMAIL PROTECTED]> writes:

> Hi!
> 
> Brutal, not exact answer, but:
> 
> a = range(5)
> b = range(3)
> print zip(a+[None]*(len(b)-len(a)),b+[None]*(len(a)-len(b)))

You reinvented map(None,a,b).

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: zip list with different length

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

C> hi
> suppose i have 2 lists, a, b then have different number of elements,
> say len(a) = 5, len(b) = 3
> >>> a = range(5)
> >>> b = range(3)
> >>> zip(b,a)
> [(0, 0), (1, 1), (2, 2)]
> >>> zip(a,b)
> [(0, 0), (1, 1), (2, 2)]
> 
> I want the results to be
> [(0, 0), (1, 1), (2, 2) , (3) , (4) ]
> can it be done?

map(lambda *t: filter(lambda x: x is not None,t),a,b)

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed

[Alexander Schmolck]

"Luis M. González" <[EMAIL PROTECTED]> writes:

> On Mar 31, 8:38 am, Bjoern Schliessmann  [EMAIL PROTECTED]> wrote:
> > Mark Dufour wrote:
> > > Shed Skin allows for translation of pure (unmodified), implicitly
> > > statically typed Python programs into optimized C++, and hence,
> >
> >^> highly 
> > optimized machine language.
> >
> >   
> >
> > Wow, I bet all C++ compiler manufacturers would want you to work for
> > them.
> >
> > Regards,
> >
> > Björn
> >
> > --
> > BOFH excuse #23:
> >
> > improperly oriented keyboard
> 
> 
> Mark has been doing an heroic job so far.
> Shedskin is an impressive piece of software and, if pypy hadn't been
> started some time ago, it should have gotten more attention from the
> community.

Regardless of its merrits, it's GPL'ed which I assume is an immediate turn-off
for many in the community.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python equivalents to MATLAB str2func, func2str, ischar, isfunc?

[Alexander Schmolck]

"dmitrey" <[EMAIL PROTECTED]> writes:

> Thank you
> (however in MATLAB ischar is the same as isstr)

Right, sorry.

> but what if I don't know the name of module?
> I.e. I have
> 
> def myfunc(param): ...
> #where param can be both funcName or a function, and I want to obtain
> both name and func, something like
> if isinstance(param, basestring):
>func, funcName = , param
> else: func, funcName = param, param.__name__
> what should I type instead of ?

globals()[param] (I assume you don't want a local function, should one exist?)

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python equivalents to MATLAB str2func, func2str, ischar, isfunc?

[Alexander Schmolck]

"dmitrey" <[EMAIL PROTECTED]> writes:

> I can't find these via web serch
> 
> thank you in advance,
> Dmitrey


str2func: getattr(some_module, 'f')
func2str: f.__name__
ischar: isinstance(x, basestring) and len(x) == 1
isfunc: callable(x) # is most likely to be what you want

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Try to get help on pymat

[Alexander Schmolck]

"CHRIS CHEW" <[EMAIL PROTECTED]> writes:

> I am trying to get my pymat to work. The Python script did not interface to
> matlab yet. What are the required script to get the interface to work? Please
> send me email at [EMAIL PROTECTED]

You might want to have a look at .

cheers,

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] mlabrap-1.0b: a high level python to matlab bridge

[Alexander Schmolck]

URL
---


Description
---

Mlabwrap-1.0 is a high-level python to matlab(tm) bridge that makes calling
matlab functions from python almost as convenient as using a normal python
library. It is available under a very liberal license (BSD/MIT) and should
work on all major platforms and (non-ancient) python and matlab versions and
either numpy or Numeric (Numeric support will be dropped in the future).

News


version 1.0b brings python 2.5 compatibility and various small fixes (improved
error handling for 7.3, improvements to setup.py etc.). Provided I don't get
any bug reports within the next two weeks or so the only difference between
this version and 1.0 final will be cheeseshop support. Since mlabwrap 1.0 will
be the last version that offers Numeric support anyone who wants to put off
the switch to numpy a bit longer and is interested in using mlabwrap is
strongly encouraged to download, test and possibly submit a bug report now.


Examples


Creating a simple line plot:

>>> from mlabwrap import mlab; mlab.plot([1,2,3],'-o')

Creating a surface plot:

>>> from mlabwrap import mlab; from numpy import *
>>> xx = arange(-2*pi, 2*pi, 0.2)
>>> mlab.surf(subtract.outer(sin(xx),cos(xx)))

Creating a neural network and training it on the xor problem (requires netlab)

>>> net = mlab.mlp(2,3,1,'logistic')
>>> net = mlab.mlptrain(net, [[1,1], [0,0], [1,0], [0,1]], [0,0,1,1], 1000)

Thanks go to Taylor Berg and many others who tested and provided feedback for
the upcoming 1.0 release; more acknowledgements can be found on the website.

cheers,

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling J from Python

[Alexander Schmolck]

[restoring context]
"Ant" <[EMAIL PROTECTED]> writes:
> > On Feb 6, 12:21 am, greg <[EMAIL PROTECTED]> wrote:
> >
> > Alexander Schmolck wrote:
> > > For example I once wrote this (slow) code to display
> > > part of a mandelbrot fractal:
> > > load'viewmat'
> > > viewmat+/2&>:|((j.~/~(%~i:)99)&+@:*:)^:(i.32)0
> > > It'll likely require you more typing in python,
> >
> > Yes, but with Python you wouldn't have to spend a
> > couple of weeks sitting and thinking before starting
> > to type that line...

(it's actually reasonably straightforward, if someone really cares I might
post a translation)

> 
> This is a good point often overlooked. 

There is of course some truth in Greg's statement -- J code will likely have a
higher thought/character ratio (even after adjusting for differences in
average token-length) -- but I don't think that is in itself terribly
interesting.

What is in my opinion of interest is how much of the additional thought you
need to put in in order to achieve higher terseness is spent

a) on more pentrating insight on the problem as such, encouraged by the
   mind-set and abstractions associated with a language (let's call this
   expressiveness)

and how much of it is spent

b) on perl-golf style geek masturbation that focuses on recalling and
   exploiting the language's various behavioral oddities that are only of
   coincidental or low-level relevance to the problem (let's call this
   golf-syndrome)

I'm not claiming that the boundaries between the two are always unambigious,
but I think the distinction is pretty important when discussing pros and cons
of differences in terseness between languages.

Apart from scaling better, one reason that a), expressiveness, is much more
interesting than b), golf-syndrome, is that it translates to some extent even
to writing code in other languages as it enriches the programmer's reservoir
of metaphors and abstractions. Typically this also has a beneficial effect
for coding even in languages that offer no direct support for these
abstractions (I bet a programmer with, say extensive python, J and prolog
experience and just a little bit of C background is in many cases likely to
come up with a superior C solutions to challenging problems than someone who's
got the same amount of experience in C only).

Therefore...

> You often get these threads on c.l.python about "How can I do this in one
> line", usually with some example of how it is done in only 13 characters in
> Perl. Yes you may spend less time typing - but unless you are a true expert
> in (J, Perl, other terse language) the time you spend actually working out
> how to type it, and in debugging it far outweighs the time you'd spend on
> all of that typing in a clean but more verbose language such as Python.

... I also don't think your pairing of J and Perl is particularly helpful. As
long as no one can point me to some resonable examples demonstrating otherwise
I flattly deny that Perl is more concise than python in an *interesting* way,
i.e. by encouraging or enabling a)

(BTW "not interesting" != "not practically relevant"; harking back to my
previous posts, typing effort *does matter* in some contexts, such as
command-line one-liners; IMO the only thing perl is useful for.)

J, on the other hand, whilst also suffering somewhat from golf-syndrome, does
in my opinion also enable a)-style terseness. Let me give an example:

Before reading further, how would you code a program that gives the following
output ('skewed' sierpinski-triangle) in python? I'll give some remarkably
concise and IMO lucid J code and a python translation below.


*   
**  
* * 

*   *   
**  **  
* * * * 

*   *   
**  **  
* * * * 

*   *   *   *   
**  **  **  **  
* * * * * * * * 









SPOILERS AHEAD

































J solution
--

I can think of two nice ways in J, 13 and 16 characters long respectively and
each expressing something essential and non-trival about the problem in a way
that would be more cumbersome in python.

Here's the first one:

(,,.~)^:4,'*'  NB. due to Cliff Reiter, slightly adapted


Possible Python translation
---

Here's a python transiteration attempt:

# ^: ,   ~,.
print rep(hook(vertcat, self(horzcat)),4)('*')

or slightly more idiomatic:

def sierpinski(x):
return vertcat(x,horzcat(x,x))

print rep(sierpinsky,4)('*')

With:

def identity(x): return x
def rep(f,n): # f^:n
if   n < 0: return lambda 

Re: Calling J from Python

[Alexander Schmolck]

Bruno Desthuilliers <[EMAIL PROTECTED]> writes:

> No, thanks. But hopefully we have Python :
> 
> Python 2.4.1 (#1, Jul 23 2005, 00:37:37)
> [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2
> 
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> 3 + 4
> 7
>  >>>

My calculuator even gives a pretty good answer if I divide them (without
importing anything from the __future__).

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling J from Python

[Alexander Schmolck]

Bjoern Schliessmann <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> 
> > Apart from being less to type 
> 
> Cool. Less to type.

Yes. Readability is more important in many context, but for something designed
for interactive experimentation and exploration little typing is absolutely
essential. Would you use a calculator that would require Java-style
boilerplate to add two numbers?

I'd also venture that readability and typing ease are typically closely
positively correlated (compare python to C++) and although I would not claim
that J is particularly readable I'm also not an expert user (I doubt I would
even then, but I'm sure it *does* make a difference).
 
> > and it is superior in that it's 
> > generalizes much better, e.g:
> > 
> > avg&.^.   NB. geomtric mean
> > avg&.%NB. harmonic mean
> > avg M NB. column mean of matrix M
> > avg"1 M   NB. row mean of matrix M
> 
> Is there any regularity in this? If it is, it's not obvious at all.

Sure. ``f&.g`` is like ``(f o g) o g^-1`` in common mathemetical notation.
``^.`` is log and ``%`` is inversion/division. Making ``&.`` (it's called
"under") available as a convenient abstraction is IMO one really useful
innovation of J.

As for the remaing two: it's similar to numpy in that one and the same
function can normally operate on arrays of different dimensions (including
scalars). In numpy you'd also write stuff like ``mean(M, axis=1)``, it's not
exactly the same, although the axis abstraction comes from APL (another cool
idea), J introduces a slightly different approach. The ``"1`` means "operate
on cells of rank 1" (i.e. vectors), rather than "operate along a certain
axis". For dyadic (2-argument) functions you can also specify different left
and right rank, so you could write the outerproduct v'w thus: ``v *"0 1 w``
(multiply each 0-cell (i.e scalar) of v with each 1-cell (i.e. vector, there
is only one) of w). Unlike the linear algebra notation this readily
generalizes to more than 1 dimensional objects.

BTW I don't think J is an ideal language, not even for numerical computing --
there are plenty of things I'd do differently and that includes measures that
would IMO greatly aid readability (like getting rid of "ambivalence"[1]). But
I have little doubt that, no matter what its flaws may be, APL (and J is
really just an updated, ASCII-based APL) is one of the most innovative and
important programming languages ever conceived. Anyone interested in the
design of programming language for scientific computing ought to take a look
at at least a look at it or one of its descendants.

'as

Footnotes: 
[1]  Basically almost every J function has a completely different meaning
 depending on whether you use it as a unary or binary function (just as
 conventionally "-" is abusively used for both substraction and negation).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling J from Python

[Alexander Schmolck]

Larry Bates <[EMAIL PROTECTED]> writes:

> And why is that superior to this:
> 
> def avg(l):
> return float(sum(l))/len(l)
> 
> >>>avg([1,2,3,4])
> 2.5

Apart from being less to type and it is superior in that it's generalizes much
better, e.g:

avg&.^.   NB. geomtric mean
avg&.%NB. harmonic mean
avg M NB. column mean of matrix M
avg"1 M   NB. row mean of matrix M

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling J from Python

[Alexander Schmolck]

Robin Becker <[EMAIL PROTECTED]> writes:

> Dennis Lee Bieber wrote:
> > On Mon, 05 Feb 2007 17:52:27 +0100, Bjoern Schliessmann
> > <[EMAIL PROTECTED]> declaimed the following
> > in comp.lang.python:
> >
> 
> >> Mh, just looking at some "advanced" J source taken from
> >> wikipedia.org makes me feel sick:
> >>
> >> | Here's a J program to calculate the average of a list of numbers:
> >> |avg=: +/ % #
> >> |avg 1 2 3 4
> >> | 2.5
> >>
> > That looks like some variation of APL
> 
> my colleague informs me that it is indeed associated with some of the same
> people if not with Mr Iverson.

The late Ken Iverson designed both J and APL (he has also written an number of
freely downloadable math books using J, see jsoftware.com).

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling J from Python

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> Gosi> J is in many ways similar to Python.
> 
> Gosi> J has very many advanced operations.
> 
> Gosi> http://www.jsoftware.com/
> 
> Doesn't look like open source of any variety.  If a person uses Python with
> various add-ons (RPy, numpy, matplotlib, etc) why would they want to switch
> to a closed source product?

You wouldn't, if for nothing else because python has far better scientific
libraries. If you've got an interest in programming languages as such J (or
some other APL) is worth a look though; it's also handy for quick mathematical
experimentation (J's array primitives are more expressive than what numpy
offers and python doesn't support rationals, so it's not just concise due to
perl-style crypticness). For example I once wrote this (slow) code to display
part of a mandelbrot fractal:

load'viewmat'
viewmat+/2&>:|((j.~/~(%~i:)99)&+@:*:)^:(i.32)0

It'll likely require you more typing in python, but then you'd need to do such
things quite a lot for seeing an amortization in terms of less time spent with
your PC; I think most people will find they need a seizable learning
investment to get anywhere with J and python already is very expressive for
the kind of things J is good at.

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: in place-ness of list.append

[Alexander Schmolck]

Alexander Schmolck <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] writes:
> 
> > >>>>> "Bart" == Bart Van Loon <[EMAIL PROTECTED]> writes:
> > 
> > >> Such an operation will be O(N**2), 
> > 
> > Bart> why is that?
> > 
> > The a[:] operation makes a copy of a (as will the x = a + [n] idiom).
> 
> I'm pretty confident append itself (and a+[n]) are linear in N=len(a) since

Sorry -- I just see that I missed your other post.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: in place-ness of list.append

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> > "Bart" == Bart Van Loon <[EMAIL PROTECTED]> writes:
> 
> >> Such an operation will be O(N**2), 
> 
> Bart> why is that?
> 
> The a[:] operation makes a copy of a (as will the x = a + [n] idiom).

I'm pretty confident append itself (and a+[n]) are linear in N=len(a) since
the copying is linear and appending a single item in-place is constant time
(OTOH calling append N times to construct a list or tree of length N from
scratch is quadratic; I assume that is what you meant and also what the OP
seems to want to use it for, so not doing it this way is sound advice).
 
> Bart> I am building a binary tree where each node is a list. the two
> Bart> children are the parent list + 1 and the parent list + 2.
> 
> You might consider creating each node as
> 
> left = [parent, 1]
> right = [parent, 2]

Or, if you don't need to mutate the tree ``left = (parent, 1)``. Tuples ought
to have a little less memory overhead.
 
'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Very newbie programming

[Alexander Schmolck]

TheSaint <[EMAIL PROTECTED]> writes:

> # Filling the c with the list of devices which are recorded to be mounted
> 
> d = filter((lambda a: a[:2] =='/d'),mnt.readlines()) # non /dev-mounts are
> off
> d = map((lambda a: a.split()[:1]),d) # only the first info column is used

Just focusing one one detail:

1. you don't need the parens around the lambda

2. you can just write the above as

d = [a.split()[:1] for a in mnt if a.startswith('/d')]


'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: string.count issue (i'm stupid?)

[Alexander Schmolck]

"Dirk Hagemann" <[EMAIL PROTECTED]> writes:

> I think I can tell you WHY this happens, but I don't know a work-around
> at the moment.

len(re.findall('_(?=a_)', '_a_a_a_a_'))

# untested
def countWithOverlaps(s, pat):
return len(re.findall("%s(?=%s)" % (re.escape(pat[0]), 
re.escape(pat[1:])),s))

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: round numbers in an array without importing Numeric or Math?

[Alexander Schmolck]

Lance Hoffmeyer <[EMAIL PROTECTED]> writes:

> Is there an easy way to round numbers in an array?
> 
> I have
> Test = [1.1,2.2,3.7]
> 
> and want to round so the values are
> 
> print Test  [1,2,4]

[int(x+0.5) for x in Test]

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Alexander Schmolck]

Ken Tilton <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> > Ken Tilton <[EMAIL PROTECTED]> writes:
> >
> 
> >>In Common Lisp we would have:
> >>
> >>(defvar *x*) ;; makes it special
> >>(setf *x* 1)
> >>(print *x*) ;;-> 1
> >>(let ((*x* 2))
> >>   (print *x*)) ;; -> 2
> >>(print *x*) ;; -> 1
> > You seem to think that conflating special variable binding and lexical
> 
> > variable binding is a feature and not a bug. What's your rationale?
> 
> Transparency. 

That's is circular. You might be right, but you failed to provide a rationale
and not just a restatement.

> That is where power comes from. I did the same things with Cells. Reading a
> slot with the usual Lisp reader method transparently creates a dependency on
> the variable. 

Let me see if I understand it right -- if an instance of class A has a ruled
slot a that reads an instance of class B's slot b then it is noted somewhere
that A's a depends on b?

> To change a variable and have it propagate throughout the datamodel, Just
> Change It.
> 
> 
> Exposed wiring means more work and agonizing refactoring.

Well, you claim that in that instance python suffers from exposed wiring and I
claim that CL suffers from a (minor) booby trap. You can't typically safely
ignore whether a variable is special as a mere wiring detail or your code
won't work reliably (just as you can't typically safely ignore whether
something is rigged or not even if booby-trapness is pretty transparent) --
it's as simple as that (actually its a bit worse because the bug can be hard
to detect as lexical and special variables will result in the same behaviour
in many contexts).

So in the case of booby traps and special variables, I generally prefer some
exposed wiring (or strong visual clues) to transparency.

I'd like to see a demonstration that using the same binding syntax for special
and lexical variables buys you something apart from bugs.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Alexander Schmolck]

jayessay <[EMAIL PROTECTED]> writes:

> > Great -- so can I see some code? Can't be that difficult, it takes about 
> > 10-15
> > lines in python (and less in scheme).
> 
> Do you actually need the code to understand this relatively simple concept???

Yes. I'd be genuinely curious to see how an implementation in Java, Pascal, C,
(or any other language that has little more than dictionaries) compares to
python and CL.

In my limited understanding I have trouble seeing how you'd do without either
unwind-protect/try-finally or reliable finalizers for starters.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Alexander Schmolck]

Duane Rettig <[EMAIL PROTECTED]> writes:

> My reason for responding to you in the first place was due to your poor use
> of the often misused term "bug".  You could have used many other words or
> phrases to describe the situation, and I would have left any of those alone.

I'm happy to accept your terminology of bug (not conforming to a certain
specification) for the remainder of this discussion so that we can stop
quibbling over words.

[...]
> > I'd be even more interested in what you think (seriously; should
> > you consider it a design feature (for reasons other than backwards
> > compatiblity constraints), I'm pretty sure you would also give a 
> > justification
> > that would merrit consideration).
> 
> Well, OK, let's change the conversation away from "bug"-ness and toward any of
> the other negatives we discussed above.  I actually doubt that I can provide
> a justification in a small space without first understanding who you are
> and from what background you are coming, so let me turn it around and ask
> you instead to knock down a straw-man:
> 
> You seem to be saying that pure lexical transparency is always preferable
> to statefulness (e.g. context).

No.

> Can we make that leap? If not, set me straight. 

I think that in most contexts lexical transparency is desirable so that
deviations from lexical transparency ought to be well motivated. I also
believe that a construct that is usually used to establish a lexically
transparent binding shouldn't be equally used for dynamic bindings so that it
isn't syntactically obvious what's going on. I've already provided some
reasons why CL's design wrt. binding special and lexical variables seems bad
to me. I don't think these reasons were terribly forceful but as I'm not aware
of any strong motivation why the current behaviour would be useful I'm
currently considering it a minor wart.

To make things more concrete: What would be the downside of, instead of doing
something like:

(let ((*x* ...)) [(declare (special *x*))] ...) ; where [X] denotes maybe X

doing any of the below:

a) using a different construct e.g. (fluid-let ((*x* ...)) ...) for binding
   special variables
b) having to use *...* (or some other syntax) for special variables
c) using (let ((q (special *x*) (,a ,b ,@c)) (values 1 2 '(3 4 5 6)))
  (list q ((lambda () (incf *x*))) a b c)) ; => (1 3 3 4 (5 6))

(It's getting late, but hopefully this makes some vague sense)

> If so, tell me: how do we programmatically model those situations in life
> which are inherently contextual in nature, where you might get a small piece
> of information and must make sense of it by drawing on information that is
> _not_ given in that information, but is (globally, if you will) "just known"
> by you? How about conversations in English? And, by the way, how do you
> really know I'm writing to you in English, and not some coded language that
> means something entirely different?

We can skip that part.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Alexander Schmolck]

Duane Rettig <[EMAIL PROTECTED]> writes:

> Alexander Schmolck <[EMAIL PROTECTED]> writes:
> 
> > Ken Tilton <[EMAIL PROTECTED]> writes:
> >
> >> In Common Lisp we would have:
> >> 
> >> (defvar *x*) ;; makes it special
> >> (setf *x* 1)
> >> (print *x*) ;;-> 1
> >> (let ((*x* 2))
> >>(print *x*)) ;; -> 2
> >> (print *x*) ;; -> 1
> >
> > You seem to think that conflating special variable binding and lexical
> > variable binding is a feature and not a bug. What's your rationale?
> 
> A bug is a non-conformance to spec. 

There is a world beyond specs, you know. If copies of allegro CL accidently
sent out death-threats to the US president on a weekly basis, because someone
at franz accidently or purposefully left in some pranky debugging code the
fact that this behaviour would likely neither violate the ansi spec nor any
other specs that ACL officially purports to adhere to wouldn't make it any
less of a bug (or help to pacify your customers).

> Kenny's statement was specifically about Common Lisp

No Kenny's statement was about contrasting the way something is done in python
and the way something is done in common lisp (with the implication that the
latter is preferable). Of course the way something is done in common lisp is
almost tautologically in closer agreement with the ansi common lisp spec than
the way it is done in python, so agreement with the clhs is not a useful
criterion when talking about design features and misfeatures when contrasting
languages.

I thought it would have been pretty obvious that I was talking about language
design features and language design misfeatures (Indeed the infamously post
hoc, "It's a feature, not a bug" I was obviously alluding too doesn't make
much sense in a world were everything is tightly specified, because in it
nothing is post-hoc).

>, which has a spec.

Bah -- so does fortran. But scheme also has operational semantics.

> Now, what was your rationale for it _being_ a bug?

I just don't think the way special variable binding (or variable binding in
general[1]) is handled in common lisp is particularly well designed or
elegant.

Special variables and lexical variables have different semantics and using
convention and abusing[2] the declaration mechanism to differentiate between
special and lexical variables doesn't strike me as a great idea.

I can certainly think of problems that can occur because of it (E.g. ignoring
or messing up a special declaration somewhere; setf on a non-declared variable
anyone? There are also inconsistent conventions for naming (local) special
variables within the community (I've seen %x%, *x* and x)).

Thus I don't see having to use syntactically different binding and assignment
forms for special and lexical variables as inherently inferior.

But I might be wrong -- which is why was asking for the rationale of Kenny's
preference. I'd be even more interested in what you think (seriously; should
you consider it a design feature (for reasons other than backwards
compatiblity constraints), I'm pretty sure you would also give a justification
that would merrit consideration).

'as

Footnotes: 
[1] The space of what I see as orthogonal features (parallel vs. serial
binding, single vs. multiple values and destructuring vs non-destructuring
etc.) is sliced in what appear to me pretty arbitrary, non-orthogonal and
annoying (esp. superfluous typing and indentation) ways in CL.

[2] Generally declarations don't change the meaning of an otherwise
well-defined program. The special declaration does. It's also a potential
source of errors as the declaration forces you to repeat yourself and to
pay attention to two places rather than one.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Alexander Schmolck]

Ken Tilton <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> > jayessay <[EMAIL PROTECTED]> writes:
> >
> 
> >>"Michele Simionato" <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>>I was interested in a proof of concept, to show that Python can
> >>>emulate Lisp special variables with no big effort.
> >>
> >>OK, but the sort of "proof of concept" given here is something you can
> >> hack up in pretty much anything.
> 
> > Care to provide e.g. a java equivalent?
> 
> 
> I think the point is that, with the variable actually being just a string and
> with dedicated new explicit functions required as "accessors", well, you could
> hack that up in any language with dictionaries. 

Great -- so can I see some code? Can't be that difficult, it takes about 10-15
lines in python (and less in scheme).

> It is the beginnings of an interpreter, not Python itself even feigning
> special behavior.
> 
> 
> perhaps the way to go is to take the Common Lisp:
> 
>  (DEFVAR *x*)
> 
>  *x* = special_var(v=42) ;; I made this syntax up
> 
> that could make for cleaner code:
> 
>  *x*.v = 1
> 
>  print *x*.v -> 1
> 
> (Can we hide the .v?) 

I'd presumably write special variable access as something like:

with specials('x','y','z'):
 special.x = 3 + 4
 special.y = special.x + 10
 ...

I haven't tested this because I haven't got the python 2.5 alpha and won't go
through the trouble of installing it for this usenet discussion, but I'm
pretty sure this would work fine (I'm sure someone else can post an
implementation or prove me wrong). I also can't see how one could sensibly
claim that this doesn't qualify as an implementation of dynamically scoped
variables. Doesn't look any worse to me than

(let (x y z)
 (declare (special x y z))
 ...)

-- in fact it looks better.

> But there is still the problem of knowing when to revert a value to its
> prior binding when the scope of some WITH block is left.

Can you explain what you mean by this statement? I'm not quite sure but I've
got the impression you're a possibly confused. Have you had a look at
<http://docs.python.org/dev/whatsnew/pep-343.html> or some other explanation
of the with statement?

> Of course that is what indentation is for in Python, so... is that extensible
> by application code? 

The meaning of indentation? No.

> Or would this require Python internals work?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Alexander Schmolck]

Ken Tilton <[EMAIL PROTECTED]> writes:

> In Common Lisp we would have:
> 
> (defvar *x*) ;; makes it special
> (setf *x* 1)
> (print *x*) ;;-> 1
> (let ((*x* 2))
>(print *x*)) ;; -> 2
> (print *x*) ;; -> 1

You seem to think that conflating special variable binding and lexical
variable binding is a feature and not a bug. What's your rationale?

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: New tail recursion decorator

[Alexander Schmolck]

Duncan Booth <[EMAIL PROTECTED]> writes:

> Tim N. van der Leeuw wrote:
> 
> > The other thing I do not understand, due to my limited understanding of
> > what is tail-recursion: factorial2 (Duncan's definition) is not proper
> > tail-recursion. Why not? How does it differ from 'real' tail recursion?
> 
> Tail recursion is when a function calls itself and then immediately returns 
> the result of that call as its own result. 

I think the definition is broader than that so that these two functions would
also be tail-recursive (i.e. the tail call doesn't have to be a self-tail
call; I might be mistaken, don't have a good reference at hand; however
"properly tail recursive" certainly refers to being able to do the below
without exhausting the stack even for large n, not just transforming self-tail
calls to a loop, which is sort of limited usefulness anyway):

def even(n):
return n == 0 or not odd(n-1)

def odd(n):
return n == 1 or not even(n-1)

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Alexander Schmolck]

jayessay <[EMAIL PROTECTED]> writes:

> "Michele Simionato" <[EMAIL PROTECTED]> writes:
> 
> > I was interested in a proof of concept, to show that Python can
> > emulate Lisp special variables with no big effort.
> 
> OK, but the sort of "proof of concept" given here is something you can
> hack up in pretty much anything. 

Care to provide e.g. a java equivalent?

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Matplotlib in Python vs. Matlab, which one has much better graphical pressentation?

[Alexander Schmolck]

N/A <[EMAIL PROTECTED]> writes:

> Hi all,
> 
> Can I have your opinions on Matlab vs. Matplotlib in Python in terms of 2D and
> 3D graphical presentation please.
> 
> 
> Matplotlib in Python vs. Matlab, which one has much better graphical
> pressentation?

As far as 2D plots are concerned I think matplotlib has been superior for some
time now, but 3D plot support is only in the making (other options do exist,
but I haven't tried MayaVi and co).

However, if you've got a license for matlab anyway, you can also fairly easily
use it from python and mix and match as required (see my mlabwrap module at
).

E.g. do do a pretty surface plot from python, try:

  >>> from mlabwrap import mlab; from scipy import *
  >>> xx = arange(-2*pi, 2*pi, 0.2)
  >>> mlab.surf(subtract.outer(sin(xx),cos(xx)))

Once matplotlib is up to the task, it should be easy to get rid of matlab
dependencies in you code.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Alexander Schmolck]

Bill Atkins <[EMAIL PROTECTED]> writes:

> Here's how one of the cells examples might look in corrupted Python
> (this is definitely not executable):
> 
>   class FallingRock:
> def __init__(self, pos):
>   define_slot( 'velocity', lambda: self.accel * self.elapsed )
>   define_slot( 'pos', lambda: self.accel * (self.elapsed ** 2) / 2,
> initial_position = cell_initial_value( 100 ) )
>   self.accel = -9.8
> 
>   rock = FallingRock(100)
>   print rock.accel, rock.velocity, rock.pos
>   # -9.8, 0, 100
> 
>   rock.elapsed = 1
>   print rock.accel, rock.velocity, rock.pos
>   # -9.8, -9.8, -9.8
> 
>   rock.elapsed = 8
>   print rock.accel, rock.velocity, rock.pos
>   # -9.8, -78.4, -627.2
> 
> Make sense?  

No, not at all.

Why do you pass a ``pos`` parameter to the constructor you never use? Did you
mean to write ``cell_initial_value(pos)``?

Why is elapsed never initialized? Is the dependency computation only meant to
start once elapsed is bound? But where does the value '0' for velocity come
from then? Why would it make sense to have ``pos`` initially be completely
independent of everything else but then suddenly reset to something which is
in accordance with the other parameters?

What happens if I add ``rock.pos = -1; print rock.pos ``? Will I get an error?
Will I get -1? Will I get -627.2?

To make this more concrete, here is how I might implement a falling rock:

class FallingRock(object):
velocity = property(lambda self:self.accel * self.elapsed)
pos = property(lambda self: 0.5*self.accel * self.elapsed**2)
def __init__(self, elapsed=0):
self.elapsed = elapsed
self.accel = -9.8

rock =  FallingRock()
print rock.accel, rock.velocity, rock.pos
# => -9.8 -0.0 -0.0
rock.elapsed = 1
print rock.accel, rock.velocity, rock.pos
# => -9.8 -9.8 -4.9
rock.elapsed = 9
print rock.accel, rock.velocity, rock.pos
# => -9.8 -88.2 -396.9

How would you like the behaviour to be different from that (and why)?

> The idea is to declare what a slot's value represents
> (with code) and then to stop worrying about keeping different things
> synchronized.

That's what properties (in python) and accessors (in lisp) are for -- if you
compute the slot-values on-demand (i.e. each time a slot is accessed) then you
don't need to worry about stuff getting out of synch.

So far I haven't understood what cells (in its essence) is meant to offer over
properties/accessors apart from a straightforward efficiency hack (instead of
recomputing the slot-values on each slot-access, you recompute them only when
needed, i.e. when one of the other slots on which a slot-value depends has
changed). So what am I missing?
 
> Here's another of the examples, also translated into my horrific
> rendition of Python (forgive me):
> 
>   class Menu:
> def __init__(self):
>   define_slot( 'enabled', 
>  lambda: focused_object( self ).__class__ == TextEntry and 
>  

OK, now you've lost me completely. How would you like this to be different in
behaviour from:

class Menu(object):
enabled = property(lambda self: isinstance(focused_object(self),TextEntry) \
and focused_object(self).selection)

???
   
> Now whenever the enabled slot is accessed, it will be calculated based
> on what object has the focus.  Again, it frees the programmer from
> having to keep these different dependencies updated.

Again how's that different from the standard property/accessor solution as
above?

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Alexander Schmolck]

[trimmed groups]

Ken Tilton <[EMAIL PROTECTED]> writes:

> yes, but do not feel bad, everyone gets confused by the /analogy/ to
> spreadsheets into thinking Cells /is/ a spreadsheet. In fact, for a brief
> period I swore off the analogy because it was so invariably misunderstood.
> Even Graham misunderstood it.

Count me in.

> 
> But it is such a great analogy! 
> 
> > but what's the big deal about PyCells?
> > Here is 22-lines barebones implementation of spreadsheet in Python,
> > later I create 2 cells "a" and "b", "b" depends on a and evaluate all
> > the cells. The output is
> > a = negate(sin(pi/2)+one) = -2.0
> 
> > b = negate(a)*10 = 20.0
> 
> Very roughly speaking, that is supposed to be the code, not the output. So you
> would start with (just guessing at the Python, it has been years since I did
> half a port to Python):
> 
> 
>v1 = one
>a = determined_by(negate(sin(pi/2)+v1)
>b = determined_by(negate(a)*10)
>print(a) -> -2.0 ;; this and the next are easy
>print(b) -> 20
>v1 = two ;; fun part starts here
>print(b) -> 40 ;; of course a got updated, too
> 

do you mean 30?

I've translated my interpretation of the above to this actual python code:

from math import sin, pi
v1 = cell(lambda: 1)
a = cell(lambda:-(sin(pi/2)+v1.val), dependsOn=[v1])
b = cell(lambda: -a.val*10, dependsOn=[a], 
 onChange=lambda *args: printChangeBlurp(name='b',*args))
print 'v1 is', v1
print 'a is', a # -2.0 ;; this and the next are easy
print 'b is', b # 20
v1.val = 2 # ;; fun part starts here
print 'v1 now is', v1
print 'b now is', b # 30 ;; of course a got updated, too


I get the following printout:

v1 is 1
a is -2.0
b is [cell 'b' changed from <__main__.unbound object at 0xb4e2472c> to 20.0,
it was not bound]20.0
[cell 'b' changed from 20.0 to 30.0, it was bound ] v1 now is 2
b now is 30.0

Does that seem vaguely right?

> The other thing we want is (really inventing syntax here):
> 
>on_change(a,new,old,old-bound?) print(list(new, old, old-bound?)

Is the above what you want (you can also dynamically assign onChange later
on, as required or have a list of procedures instead)?

> 
> Then the print statements Just Happen. ie, It is not as if we are just hiding
> computed variables behind syntax and computations get kicked off when a value
> is read. Instead, an underlying engine propagates any assignment throughout
> the dependency graph before the assignment returns.

Updating on write rather than recalculating on read does in itself not seem
particularly complicated.

> My Cells hack does the above, not with global variables, but with slots (data
> members?) of instances in the CL object system. I have thought about doing it
> with global variables such as a and b above, but never really seen much of
> need, maybe because I like OO and can always think of a class to create of
> which the value should be just one attribute.

OK, so in what way does the quick 35 line hack below also completely miss your
point?


# (NB. for lispers: 'is' == EQ; '==' is sort of like EQUAL)

def printChangeBlurp(someCell, oldVal, newVal, bound, name=''):
print '[cell %r changed from %r to %r, it was %s]' % (
name, oldVal, newVal, ['not bound', 'bound '][bound]),

_unbound = type('unbound', (), {})() # just an unique dummy value
def updateDependents(dependents):
seen = {}
for dependent in dependents:
if dependent not in seen:
seen[dependent] = True
dependent.recalculate()
updateDependents(dependent._dependents)
class cell(object):
def __init__(self, formula, dependsOn=(), onChange=None):
self.formula = formula
self.dependencies = dependsOn
self.onChange = onChange
self._val = _unbound
for dependency in self.dependencies:
if self not in dependency._dependents:
dependency._dependents.append(self)
self._dependents = []
def __str__(self):
return str(self.val)
def recalculate(self):
newVal = self.formula()
if self.onChange is not None:
oldVal = self._val
self.onChange(self, oldVal, newVal, oldVal is not _unbound)
self._val = newVal
def getVal(self):
if self._val is _unbound:
self.recalculate()
return self._val
def setVal(self, value):
self._val = value
updateDependents(self._dependents)
val = property(getVal, setVal)



'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: NaN handling

[Alexander Schmolck]

Felipe Almeida Lessa <[EMAIL PROTECTED]> writes:

> Em Sex, 2006-05-05 às 16:37 -0400, Ivan Vinogradov escreveu:
> > This works to catch NaN on OSX and Linux:
> > 
> > # assuming x is a number
> > if x+1==x or x!=x:
> > #x is NaN
> 
> This works everywhere:
> 
> nan = float('nan')
> 
> .
> .
> .
> 
> if x == nan:
> # x is not a number

No it doesn't.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: NaN handling

[Alexander Schmolck]

Robert Kern <[EMAIL PROTECTED]> writes:

> Ivan Vinogradov wrote:
> 
> > It doesn't seem to be here under OSX either (universal Python install).
> 
> It's not enabled by default. In the source distribution, it is
> Modules/fpectlmodule.c .
> 
> > Since numpy seems to be working on a variety of platforms/hardware,
> > how hard would it be to extract this functionality from it to add to  
> > Python proper?
> 
> Harder than just enabling fpectl.

Last thing I heard fpectl was considered to be completely broken -- it's
likely not disabled by default for no reason. A short google turned up this:


Comment By: Michael Hudson (mwh)
Date: 2006-02-20 12:59

Message:
Logged In: YES 
user_id=6656

Waaa, the correct thing to is to remove the --with-fpectl from configure!
I've 
been meaning to post to python-dev for a while now proposing the ripping 
out 
of this code.  It's just not useful any more.  At any rate, I am actively 
opposed to 
advertising its existence more widely.

And in pep 356 (python 2.5 release schedule) we find:

Possible features for 2.5
[...]
- Remove the fpectl module?

So "just enabling fpectl" doesn't look like a viable long term solution.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling Python from Matlab

[Alexander Schmolck]

"Daniel Nogradi" <[EMAIL PROTECTED]> writes:

> > I am desperately looking for a way to call Python from Matlab. I have become
> > used to Python's rich syntax and large number of libraries, and feel
> > ridiculously clumsy being stuck with Matlab's rather restricted facilities
> > for doing other things than standard mathematical work.
> >
> > Does anyone know of good techniques (or readily available software) for
> > achieving a cross-language support between Python and Matlab?
> >
> > Carl
> 
> Perhaps you will find this useful:
> 
> http://claymore.engineer.gvsu.edu/~steriana/Python/pymat.html

I'd recommend looking at



instead (but then I'm the author). It's based on pymat but contains several
critical bugfixes and a high-level interface from python to matlab (e.g. you
can just do mlab.plot([1,2,3]) or x = mlab.sin(3)). I'll need to update a
couple of things, but on the whole it appears quite stable -- people have
succefully used it under windows, linux and os x.

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Automated Graph Plotting in Python

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> 1. Which is the best graph plotting utility in python or linux. 

matplotlib (provided it does the type of graphs you need, which is likely)

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dice probability problem

[Alexander Schmolck]

Tomi Lindberg <[EMAIL PROTECTED]> writes:

> # Adds another die to results.
> def add_dice(sums, die):
>  # If first die, all values appear once

I'd add something like

   sums = sums or {}

because otherwise your function will sometimes mutate sums and sometimes
return a fresh object, which usually is a very bad thing as it can easily lead
to quite nasty bugs.

>  if not sums:
>  for face in die:
>  sums[face] = 1
>  # Calculating the number of appearances for additional
>  # dice
>  else:
>  new_sums = {}
>  for k in sums.keys():
>  for f in die:
>  if new_sums.has_key(k+f):
>  new_sums[k+f] += sums[k]
>  else:
>  new_sums[k+f] = sums[k]
>  sums = new_sums
>  return sums

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dice probability problem

[Alexander Schmolck]

Alexander Schmolck <[EMAIL PROTECTED]> writes:

> addDice(resultFor1, pool[1])
> addDice(pool[0], pool[1])


sorry should have spelled out that successive lines are meant to be
equivalent, i.e.

 addDice(resultFor1, pool[1])
==   addDice(pool[0], pool[1])

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dice probability problem

[Alexander Schmolck]

Tomi Lindberg <[EMAIL PROTECTED]> writes:

> I'm trying to find a way to calculate a distribution of outcomes with any
> combination of dice. I have the basics done, but I'm a bit unsure how to
> continue. My main concern is how to make this accept any number of dice,
> without having to write a new list comprehension for each case?

You need to think about the right way to break the problem down into some
operation that can be repeated one fewer times than there are dice (if you
just have a single dice, nothing needs to be done) and then repeat it.

An obvious candidate is adding a single dice to the sums computed so far:

def addDice(sums, dice):
return [x+y for x in dice for y in sums]

If you have less than 1 dice the answer is 
# len(pool) == 1
pool[0]

After that, each time you add a dice you need to call addDice on the sum
computed for all the previous dice and the new dice:

# len(pool) == 2
addDice(resultFor1, pool[1])
addDice(pool[0], pool[1])

then

# len(pool) == 3
addDice(resultFor2, pool[2])
addDice(addDice(resultFor1, pool[1]), pool[2])
addDice(addDice(pool[0], pool[1]), pool[2])

finally you get

# len(pool) == n
addDice(addDice(addDice(..., pool[n-3]), pool[n-2]) pool[n-1])

OK, so how do we get the repetition?

Conveniently the pattern f(...f(f(x[0],x[1]),x[2])...,x[n-1]) or equivalently,
if we write the infix operator * for f: x[0]*x[1]*...*x[n-1], can just be 
written as
reduce(f, x) in python. So we get:

reduce(addDice, pool)
== reduce(lambda sums, dice: [x+y for x in dice for y in sums], pool)

You should presumably also try writing this out as a single function, without
using reduce (but recognizing the (left) reduction pattern is useful, even if
you don't use python's reduce).

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming challenge: wildcard exclusion in cartesian products

[Alexander Schmolck]

Mark Carter <[EMAIL PROTECTED]> writes:
> A programmers mindset is usually geared towards "writing applications". What
> I'm currently doing in Lisp is building up functions as I need them. Using
> emacs, I can just C-x C-e to make my functions "live", and when it's time to
> stop for the day, save my working image so that I can use it the next day.
> 
> 
> It seems to me that only Forth or Scheme really matches this capability. 

Not really. I'd say matlab's and squeak's (and presumably most smalltalks')
interactive environment is quite superior to cl+slime. Emacs lisp is also
better and I'd also suspect erlang to be better in some ways, but I haven't
used it yet. APL and descendants (J and K) also tend to have quite reasonable
interactive facilities and so do CAS systems.

> Ruby and Python come kinda close - they do have a REPL, but it's kinda
> clunky to try to create functions on the fly, plus of course they don't
> support the idea of an image.

I don't think interactively creating functions is much harder in python but
changing module and class definitions is.

Actually although cl+slime is rather nice it is inferior to the much less
sophisticated and capable ipython+emacs combo in some regards (runtime error
reporting in CL tends to be pretty crap; (i)python docstrings, ease of
interactive testing and shell integration are superior). It's also much
easier to serialize stuff in python than it is in common lisp (never mind
pickle; you can't even readably print hashtables -- and unless I'm missing
something this is not user-fixable which really sucks).

Of course it's *much* easier to supply a nice interactive experience for a
quite limited language such as matlab than it is for CL (mostly because CL is
more powerful and geared towards efficient code generation).

So CL might well have the best interactiveness/(expressiveness*speed) ratio.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming challenge: wildcard exclusion in cartesian products

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> (defun >> (val num-bytes)
>   "Right-shift positive integer val by num-bytes"
>   (floor (/ val (expt 2 num-bytes

or just (floor val (expt 2 num-bytes)) 

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Searching for uniqness in a list of data

[Alexander Schmolck]

Alexander Schmolck <[EMAIL PROTECTED]> writes:

> The easiest way to do this is to have a nested dictionary of prefixes: for
> each prefix as key add a nested dictionary of the rest of the split as value
> or an empty dict if the split is empty. Accessing the dict with an userinput
> will give you all the possible next choices.

Oops I was reading this too hastily -- forgot to compact and take care of sep.
You might also want to google 'trie', BTW.


(again, not really tested)


def addSplit(d, split):
if len(split):
if split[0] not in d:
d[split[0]] = addSplit({}, split[1:])
else:
addSplit(d[split[0]], split[1:])
return d
def compactify(choices, parentKey='', sep=''):
if len(choices) == 1:
return compactify(choices.values()[0],
  parentKey+sep+choices.keys()[0], sep)
else:
for key in choices.keys():
newKey, newValue = compactify(choices[key], key, sep)
if newKey != key: del choices[key]
choices[newKey] = newValue
return (parentKey, choices)
def queryUser(chosen, choices, sep=''):
next = raw_input('So far: %s\nNow type one of %s: ' %
(chosen,choices.keys()))
return chosen+sep+next, choices[next]
wordList=['1p2m_3.3-1.8v_sal_ms','1p2m_3.3-1.8v_pol_ms','1p3m_3.3-18.v_sal_ms']
choices = compactify(reduce(addSplit,(s.split('_') for s in wordList),  {}),
 sep='_')[1]
chosen = ""

while choices:
chosen, choices = queryUser(chosen, choices, '_')
print "You chose:", chosen


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Searching for uniqness in a list of data

[Alexander Schmolck]

"rh0dium" <[EMAIL PROTECTED]> writes:

> Hi all,
> 
> I am having a bit of difficulty in figuring out an efficient way to
> split up my data and identify the unique pieces of it.
> 
> list=['1p2m_3.3-1.8v_sal_ms','1p2m_3.3-1.8_sal_log']
> 
> Now I want to split each item up on the "_" and compare it with all
> others on the list, if there is a difference I want to create a list of
> the possible choices, and ask the user which choice of the list they
> want.  I have the questioning part under control.   I can't seem to get
> my hands around the logic - the list could be 2 items or 100 long.  The
> point of this is that I am trying to narrow a decision down for an end
> user.  In other words the end user needs to select one of the list
> items, and by breaking it down for them I hope to simplify this.
> 
> list=['1p2m_3.3-1.8v_sal_ms','1p6m_3.3-1.8_sal_log']
>  would only question the first data set ['1p2m', '1p6m' ]
> 
> list=['1p2m_3.3-1.8v_sal_ms','1p2m_3.3-1.8v_pol_ms','1p3m_3.3-18.v_sal_ms']
>  If on the list ['1p2m','1p2m','1p3m'] the user selected 1p2m then the
> next list would only be ['sal','pol']
>  but if the user initially only selected 1p3m they would be done..
> 
> I hope this clarifies what I am trying to do.  I just can't seem to get
> my hands around this - so an explaination of logic would really be
> helpfull.  I picture a 2d list but I can't seem to get it..

The easiest way to do this is to have a nested dictionary of prefixes: for
each prefix as key add a nested dictionary of the rest of the split as value
or an empty dict if the split is empty. Accessing the dict with an userinput
will give you all the possible next choices.

Spoiler Warning -- sample implementation follows below.
































(mostly untested)

def addSplit(d, split):
if len(split):
if split[0] not in d:
d[split[0]] = addSplit({}, split[1:])
else:
addSplit(d[split[0]], split[1:])
return d
def queryUser(chosen, choices):
next = raw_input('So far: %s\nNow type one of %s: ' %
(chosen,choices.keys()))
return chosen+next, choices[next]

wordList=['1p2m_3.3-1.8v_sal_ms','1p2m_3.3-1.8v_pol_ms','1p3m_3.3-18.v_sal_ms']
choices = reduce(addSplit,(s.split('_') for s in wordList),  {})
chosen = ""
while choices:
chosen, choices = queryUser(chosen, choices)
print "You chose:", chosen

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

Rocco Moretti <[EMAIL PROTECTED]> writes:

> I think it's worth pointing out that not all dynamicism is equal, when it
> comes to difficulty in compiling to machine code.

No kidding (do you have any idea how this thread started out?).

> Lisp, like the good functional language that it is, has (primarily) immutable
> values, and minimal side effects.
[further nonsense snipped]

Please don't spread misinformation about things about which you are clueless[1].

'as


Footnotes: 
[1]  Just as a minor illustrative detail: in python 2 out of 4 builtin
 collection types are immutable (tuples and strings; newer versions also
 have immutable and mutable sets) in CL 5 out of 5 are mutable
 (arrays/vectors/strings, hash-tables, cons cells).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Michele Simionato" <[EMAIL PROTECTED]> writes:

> I replied to this message yesterday, but it did not appear, so let's
> try again.
> 
> I agree with your points, but I would not say that Lisp is
> intrinsically more dynamic than Python as a language;

Neither would I -- I don't think either is obviously more dynamic than the
other.

But since it has been implied that python's comparatively poor performance is
simply due to it being more dynamic than other languages, I wanted to point
out that one could with just as much justification claim CL to be more dynamic
than python (it is in some regards, but not in others -- how to weight them to
achieve some overall "score" is not obvious. I really doubt that python will
ever come remotely close to the level of dynamism that now defunct lispmachine
technology achieved, though).

> it is just more interactive and has more features (and more complexities
> too).

Indeed -- CL is much more complex than python and has many, many more warts.

As for common lisp being "just more interactive" -- all things being equal I
fail to see how "more interactive" cannot imply more dynamic -- IMO it doesn't
get much more dynamic than changing and inspecting things interactively. Also
not all the ways in which CL is more dynamic represent features that increase
complexity. For example in CL you could just write

  def foo(x, l=[], N=len(l)): [...]

and have it work as expected because defaults are evaluated on call (this is
one of the very rare occassions of an obvious design wart in python, IMO).

In other cases, of course, more dynamism seems to involve added complexity.
For example CL has sane (dynamically scoped) global variables (and local ones,
if you declare them "special"). I think python is somewhat broken in this
regard, but I must admit I have no idea how to implement dynamically scoped
variables simply and "pythonically", so I wouldn't call it an obvious design
flaw.

> BTW, regarding your first point on interactive sessions, are you aware
> of Michael Hudson's recipe
> "automatically upgrade class instances on reload()"
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 ?

Thanks, it's nice to be aware of other solutions, I'll have a closer look at
some point. I've of course also written my own code for that purpose -- apart
from ipython.el and a couple of private utilities I even got sufficiently
pissed off by bugs introduced by python's poor support for serious interactive
work that I started writing some sort of versioned module system that kept
track of what was being imported from where to where, but I ran out of time
and ultimately for this and unrelated reasons switched to matlab in this
particular case.

Matlab sucks in countless ways, but it gives a superior interactive
environment. If you do experimental work where state is expensive to recompute
from scratch but where you need to tune various parameters to obtain the
desired results, problems introduced by changes not properly propagating are
very, very irritating -- especially if you want to keep a record of what changes
effected what, so that your experiments are repeatable.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Michele Simionato" <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> > As common lisp and scheme demonstrate you can have high level of dynamism 
> > (and
> > in a number of things both are more dynamic than python) and still get very
> > good performance (in some cases close to or better than C).
> 
> Just for personal enlightment, where do you think Lisp is more dynamic
> of Python?
> Can you new name a few features?

Sure (I'm assuming that by lisp you mean common lisp):

- development model

  - by default the development model is highly interactive and you can
redefine all sorts of stuff (functions, methods, classes even the syntax)
without having to start over from scratch (you can also save the current
state of affairs as an image). By contrast changing modules or classes in
interactive python sessions is rather tricky to do without screwing things
up, and it doesn't support images, so sessions tend to be much more
short-lived.

Emacs+slime also offers more powerful functionality than emacs+python mode
(autocompletion, jumping to definitions, various parallel sessions or
remotely connecting to running applications via sockets etc.)

- hot-patching
   
  - partly as a consequence of the above, you can also arrange to hot-patch
some running application without too much trouble (IIRC Graham claims in
one of his essays that one of his favorite pranks was fixing a bug in the
application whilst on the phone to the customer as she reported it and
then telling her that everything in fact seemed to work fine and to try
again)

- error handling:

  - by default you end up in the debugger if something goes wrong and in many
cases you can correct it in place and just continue execution (if you've
ever had some long numerical computation die on plotting the results
because of a underflow as you exponentiate to plot in transformed
coordinates, you'd appreciate being able to just return 0 and continue)

  - Apart from "usual" exception handling CL has much more powerful resumable
exceptions that offer far more fine grained error handling possibiliies.

For more info let me recommend the chapter from Peter Seibel's excellent
"practical common lisp" (available in print, and also freely online):


<http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html>

(The whole book is a great ressource for people who want to have quick
play with common lisp and see how it's features can be leveraged for real
applications (such as html creation, or writing an mp3 server or id3
parser). Peter also makes an easy to install, preconfigured "lispbox"
bundle of Emacs+a free lisp implementation available on his web-page).

- OO: 

  - You know this already, but I'd argue that multimethods and method
combinations give you more dynamism then class-centric OO.

  - Also, if you change the definition of a class all existing instances will
be updated automatically. You can get a similar effect in python by
laboriously mutating the class, provided it doesn't use __slots__ etc, but
that is more brittle and also more limited -- for example, in CL you can 
specify what
happens to instances when the class is updated.

- chameleon like nature:

  It's much easier to make CL look like something completely different (say 
prolog
  or some indentation based, class-centric language like python) than it would
  be with python. In particular:

  - there are no reserved keywords

  - you can e.g. implement new syntax like python style """-strings easily
(I've done so in fact) with reader macros. Indentation based syntax should
also be possible along the same lines, although I haven't tried.

  - you can introduce pretty much any sort of control structure you might
fancy and you can carry out very sophisticated code transformations behind
the scenes.

- finally, with Lispmachines there at least used to be whole operating systems
  written all the way down in lisp and according to all the testimony you
  could interactively modify quite basic system behaviour. The only extant
  systems that come even remotely close would be smalltalks, but even squeak
  which is incredibly malleable and a cross-platform mini-OS in its own right
  uses the host OS for many basic tasks.


'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Kay Schluehr" <[EMAIL PROTECTED]> writes:

> Alexanders hypothesis is completely absurd. 

You're currently not in the best position to make this claim, since you
evidently misunderstood what I wrote (I certainly did not mean to suggest that
Guido *deliberately* chose to make python slow; quite the opposite in fact).

Maybe I wasn't sufficiently clear, so if rereading my original post doesn't
bring about enlightenment, I'll try a restatement.

> It turned out over the years that capabilities of Python optimization are
> lower than those of Lisp and Smalltalk. But its a system effect and
> epiphenomenon of certain design decisions. 

The point is that the design decisions, certainly for Common Lisp, scheme and
particularly for dylan where also informed by what could be done
*efficiently*, because the people who designed these languages knew a lot
about advanced compiler implementation strategies for dynamic languages and
thought that they could achieve high levels of expressiveness whilst retaining
the possibility of very fast implementations (IIRC dylan specifically was
meant to be something like within 90% of C performance). CL and dylan were
also specifically designed for building very large and sophisticated systems,
whereas it seems Guido originally thought that python would scale to about 500
LOC.

> This might change with PyPy - who knows? The Lisp/Smalltalk design is
> ingenious, radical and original and both languages were considered too slow
> for many real-world-applications over decades. But no one has ever claimed
> that Alan Kay intentionally created a slow language in order to hold the
> herd together - and it accidentally turned out to be reasonably fast with
> JIT technology in the late 90s.

I'm pretty sure this is wrong. Smalltalk and Lisp were both quite fast and
capable before JIT technology in the 90ies came along -- just not necessarily
on hardware optimized for C-like languages, partly because no one anticipated
that the x86 and co. would become so dominant (I also roughly remember Alan
Kay expressing his frustration not to long ago over the fact that despite a
5 fold increase in processing speed, current hardware would only run early
smalltalk 100x faster than the lisa -- I almost certainly misremember the
details but you get the picture).

> A conspiracy like theory used to explain what's going on is needless.

Indeed.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

Torsten Bronger <[EMAIL PROTECTED]> writes:

> I was rather stunned, too, when I read his line of thought.
> Nevertheless, I think it's not pointless, albeit formulated in an
> awkward way.  Of course, Python has not been deliberately slowed
> down.

Indeed -- and I'm really not sure what defect in someone's reading skills or
my writing skills would make anyone think I suggested this.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Donn Cave" <[EMAIL PROTECTED]> writes:

> Quoth Alexander Schmolck <[EMAIL PROTECTED]>:
> | "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> ...
> |> the only even remotely formal definition I've ever seen is "language with
> |> designed to script an existing application, with limited support for 
> handling
> |> its own state". 
> |
> |> Early Tcl and JavaScript are scripting languages, Python is not.
> |
> | Right. Which shows that by this definition scripting language is not a
> | meaningful and useful concept. No one will understand you correctly when you
> | refer to "scripting language" and mean only something like the above -- and
> | unless you spend a lot of your time talking about early tcl and early
> | javascript I doubt you'd need a word for it, either.
> 
> Oddly enough, that's what I understand it to mean, too, so you can't
> strictly say "no one".

Really? If someone talked about scripting languages without further
qualifications and much context would you automatically take that to exclude
modern Javascript, modern Tcl and python, perl, ruby etc.?

Or would you just think to yourself 'Ah, probably again someone who uses
"scripting language" imprecisely or incorectly'?

In pretty much any case I can think of all somewhat prominent languages even
those that started out purely in the context of scripting one particular
application (such as arguably javascript, although that sense of scripting is
definitely again distinct from the sense "providing application customization
and extension by users") by now have ursurped other tasks and don't fall
strictly under the given definition anymore. So my impression is that since
"scripting languages" as above would only refer to a very obscure set of
programming languages, almost no one uses the term strictly in that way.

This meaning can always be expressed by "application (specific) scripting
language" -- but what would you use to refer to "perl, python, ruby et al"?

> On the other hand, I think it's obvious that a language like Python could
> be used for scripting, without having been specifically designed for it as
> described above.  


Interviewer: "Why did you create Python in the first place?"
 
Guido: "We wanted Amoeba to be as useful as Unix for our daily work, but it was
lacking a scripting language. So I set out to design my own."

So Guido certainly designed it as a "scripting language", but since the term
is so vague, he might 


> There's an ambiguity in the phrase, out of context - I can say "Python can
> serve as a scripting language for some applications", but not "Python is a
> scripting language!", since its place in the taxonomy of languages would be
> somewhere else.

I definitely agree that scripting language is rather ambiguous.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

Bruno Desthuilliers <[EMAIL PROTECTED]> writes:

> Alexander Schmolck a écrit :
> > Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> >
> 
> >>DH a écrit :
> >>(snip)
> >>
> >>>It is by design. Python is dynamically typed. It is essentially an
> >>>interpreted scripting language like javascript or ruby or perl,
> >>
> >>
> >>It's not a "scripting" language, and it's not interpreted.
> > Of course it is. What do you think happens to the bytecode?
> 
> 
> Ok, then what do you think happens to 'machine' code ?

It gets interpreted (by a CPU, for example) -- your point being? If it is that
my definition of interpreted language would be overly inclusive, note that the
difference between interpreting byte code is a task that at least arguably
still belongs to the python language proper (and there even is a public
bytecode interface) whereas interpreting machine code typically falls outside
the tasks and specifications of the language that generated it. In any event,
I didn't make any claims that some particular language is *not* interpreted.


> "interpreted" usually means "no compilation, all parsing etc redone at each
> execution", which is not the case with a bytecode/vm based implementation.

When people (including the python website maintainers) talk about interpreted
languages they often include all languages that don't compile to machine code.
"Interpreted language" is not a terribly well defined concept and the usage of
words also changes to reflect general trends. Since pretty much no language of
any significance today is still interpreted in the sense you hold to be
canonical, when people talk about interpreted languages nowadays they (IMHO)
typically mean something else. This is just Grice in action.

> > And if python
> > isn't a scripting language, then what on earth is?
> 
> 
> bash is a scripting language for *n*x systems. javascript is a scripting
> language for web browsers. VBScript is a scripting language for MS
> applications.

Python is also a scripting language for *n*x systems and various applications.
 
> > You might want to argue about whether scriping language is a meaningful and
> > useful concept,
> 
> A scripting languagee is a language whose main purpose is to be embbeded in an
> application to provide the user a way of programmaticaly automate some tedious
> tasks.

A few lines ago bash was also a scripting language but I can't personally
recall ever seeing bash embedded in some application.

> Now you could of course argue about what is an application...
> 
> > but it's really hard to see how you could talk about "scripting
> > languages" without including python.
> 
> Ho, really ? How many applications using Python as scripting language ? 

I'd guess dozens. Several Gnome and Kde programs, some scientific software, a
number of games and other commercial software such as UML editors.

> And how many applications written in Python ?

No idea. My guess would be that there are far fewer high-profile end user
applications written in python than embedding python, though.
 
> Python *can* be used as a scripting language (and is not too bad at it), but
> it *is* not a scripting language.
 

Interviewer: "Why did you create Python in the first place?"
 
Guido: "We wanted Amoeba to be as useful as Unix for our daily work, but it was
lacking a scripting language. So I set out to design my own."

Summary of my position: it's futile pedantry trying to correct someone who
claims that python is an interpreted scripting language, since neither of
these terms are terribly well defined and your definitions don't even seem to
be internally fully consistent and certainly have the appearance of
disagreeing with those of the creator of the language.

If you dislike people refering to python as "interpreted" you can always add
that it compiles to bytecode. But the poster you corrected was already aware
of that and mentioned it himself.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> 
> > My point was that Guido probably (and fortunately!) was unaware of the 
> > extent
> > to which you can have both dynamism and speed

For the convenience of other readers, allow me to restore the snipped second
half of that sentence: "... and the extent to which very
dynamic languages are suitable for writing robust software."
 
> any my point was that chosing to ignore something doesn't mean
> that you're ignorant.

Interviewer: "You said originally you thought 500 lines would be a big
   Python program." 
Guido van Rossum: "That was just my lack of imagination."

<http://www.artima.com/intv/pyscale3.html>


Guido van Rossum: "Another thing, much farther in the future, is
  compilation to C or machine code. I used to think that this was impossible
  and (perhaps because of that) uninteresting, but recent experiments (like
  Armin Rigo's Psyco and Greg Ewing's Pyrex) suggest that this will
  eventually be possible. It should provide Python with an incredible
  performance boost and remove many of the reasons why many people are still
  reluctant to switch to Python."
  
<http://www.onlamp.com/pub/a/python/2002/06/04/guido.html?page=1>

 
> (but since you keep repeating this nonsense, it's clear that you're
> pretty ignorant wrt. software design.  too much CS exposure?).
 
Indeed. Your amazing reading comprehesion and lucid argumentation would
obviously be lost on my posts.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> 
> > You might want to argue about whether scriping language is a meaningful and
> > useful concept, but it's really hard to see how you could talk about 
> > "scripting
> > languages" without including python.
> 
> define "scripting language".

Pretty much any definition that isn't practically useless would do. I'd
personally opt for something like:

 A language that doesn't make all common simple tasks difficult and painful.

If that sounds too wishy-washy, note that I specifically question whether
scripting language is a useful and meaningful concept to start with -- I just
find it silly to take issue with calling python a scripting language but not
with the term scripting language itself (especially given that even the python
tutorial talks about python scripts and that almost anyone who uses the term
would include python).
 
> the only even remotely formal definition I've ever seen is "language with
> designed to script an existing application, with limited support for handling
> its own state". 

> Early Tcl and JavaScript are scripting languages, Python is not.

Right. Which shows that by this definition scripting language is not a
meaningful and useful concept. No one will understand you correctly when you
refer to "scripting language" and mean only something like the above -- and
unless you spend a lot of your time talking about early tcl and early
javascript I doubt you'd need a word for it, either.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> 
> > What's far more interesting to me, however, is that I think there a good
> > reasons to suspect python's slowness is more of a feature than a flaw: I'd 
> > not
> > be suprised if on the whole it greatly increases programmer productivity and
> > results in clearer and more uniform code.
> 
> > So ironically, some share of python's success might actually be due to
> > ignorance on Guido's part
> 
> it didn't, for even a millisecond, strike you that maybe, just maybe, the
> "make it as dynamic as we possibly can" choice was made on purpose ?

Python is far less dynamic than smalltalk, and presumably also self (last time
I checked there was no implementation for x86, so I have no practical
experience with self). Even common lisp could reasonably be called more
dynamic than python. And all these language communities did in fact still
manage to come up with efficient implementations.

Thus the "make it as dynamic as it possibly can" choice is hardly the cause
for python's slowness, so what's your point?

My point was that Guido probably (and fortunately!) was unaware of the extent
to which you can have both dynamism and speed and the extent to which very
dynamic languages are suitable for writing robust software. I'm pretty sure I
remember reading stuff by Guido himself in which he indicated that he
originally thought that a language with a similar level of dynamism as python
had to be slow anyway and I'm also pretty sure that I read some other stuff by
him which indicates that he thought a language like python would be only
suitable for relatively small scale development. If you don't doubt he wrote
that I'm not sure what we're disagreeing about (because clearly both
statements are wrong), if you do maybe I or someone else can find the right
reference, or maybe I really misremembered.

Anyayw, I'm pretty sure that Guido wouldn't have bothered to add things like
compiler macros to python, whatever his level of his technical expertise
concerning efficient implementations of highly dynamic languages might have
been.

However I don't find it at all implausible to assume that had Guido known all
the stuff that say, David Ungar and Guy Steele were aware of at the same time,
python would have come out not necessarily less dynamic but considerably
faster -- to its own detriment.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

Bruno Desthuilliers <[EMAIL PROTECTED]> writes:

> DH a écrit :
> (snip)
> > It is by design. Python is dynamically typed. It is essentially an
> > interpreted scripting language like javascript or ruby or perl,
> 
> 
> It's not a "scripting" language, and it's not interpreted.

Of course it is. What do you think happens to the bytecode? And if python
isn't a scripting language, then what on earth is? 

You might want to argue about whether scriping language is a meaningful and
useful concept, but it's really hard to see how you could talk about "scripting
languages" without including python.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> Hi, I've been thinking about Python vs. Lisp.  I've been learning
> Python the past few months and like it very much.  A few years ago I
> had an AI class where we had to use Lisp, and I absolutely hated it,
> having learned C++ a few years prior.  They didn't teach Lisp at all
> and instead expected us to learn on our own.  I wasn't aware I had to
> uproot my thought process to "get" it and wound up feeling like a
> moron.
> 
> In learning Python I've read more about Lisp than when I was actually
> trying to learn it, and it seems that the two languages have lots of
> similarities:
> 
> http://www.norvig.com/python-lisp.html
> 
> I'm wondering if someone can explain to me please what it is about
> Python that is so different from Lisp that it can't be compiled into
> something as fast as compiled Lisp?  

Nothing. Given a sufficiently smart implementation any language can be as fast
as any other -- it might just be a billion times harder to write that
implementation for language A than for language B.

> From this above website and others, I've learned that compiled Lisp can be
> nearly as fast as C/C++, so I don't understand why Python can't also
> eventually be as efficient? Is there some *specific* basic reason it's
> tough? Or is it that this type of problem in general is tough, and Lisp has
> 40+ years vs Python's ~15 years?

I think if you're looking for one single reason, it is presumably that (IIRC)
python was designed on the erronous assumption that dynamically typed
languages have to be slow (and are unsuitable for real applications anyway)
wheras common lisp wasn't. Furthermore the people involved in common lisp were
much more knowledgeable and experienced in things like compiler design and had
a long history of similar languages and various implementations to build upon.

As common lisp and scheme demonstrate you can have high level of dynamism (and
in a number of things both are more dynamic than python) and still get very
good performance (in some cases close to or better than C). But both these
languages have been designed with compiler writers and the generation of fast
code in mind, so they made design decisions to ease writing fast lisp
compilers and programs.

For example:

- python classes (and to some extent modules) are essentially dictionaries
  that you can modify and customize more or less at will at run-time and that
  behave interchangeably in many respects. I'm sure that presents several
  optimization headaches.

  By contrast if the common lisp compiler sees the symbol CL:LIST (usually
  written just LIST, because the CL package is imported by default) it can
  safely assume that it refers to the builtin LIST function, because you're
  not allowed to rebind the function value of functions in the CL package.
  Python can assume no such thing if it comes across ``list`` -- for all it
  knows it might as well be the number 42. Also the package and class system
  are completely separate and although common lisp's OO system is rather more
  powerful than python's it has been designed to be implementable efficiently.

- in python almost everything has to happen at run-time, whereas in common
  lisp you can do things at compile time, load time or run-time e.g:

- common lisp has a mechanism for making compiler declarations (so you can
  tell the compiler to inline a function, or the type of a variable, or to
  optimize something for speed and not for space etc.)

- common lisp has macros (proper ones, not C style) which allow you to build
  efficient abstractions

- common lisp has compiler macros. This sort of means that you can write 
your
  own compiler optimizations for your functions (i.e. if you know that your
  expensive FOO function is indempotent you could arrange for all calls of 
the
  form (FOO (FOO A)) to be replaced with simply A, in a similar way as an
  optimizing compiler might replace (a+b+c+d)*0 with 0).

What's far more interesting to me, however, is that I think there a good
reasons to suspect python's slowness is more of a feature than a flaw: I'd not
be suprised if on the whole it greatly increases programmer productivity and
results in clearer and more uniform code.

If you know the language to be dog slow any way, you're much less likely to
waste your time (and that of future maintainers) on the pointless
microoptimizations that geeks so love. Also, since only builtins have
reasonable performance there's added motiviation to become very familiar with
the available builtins (and standard libarary) and far less temptation to roll
one's own version of say dict.setdefault (even if it it sucks). The fact that
non-standard library code is inherently somewhat inferior (because it will
either be written in python and slow or written in C and a pain to install)
adds further incentive to attempt community wide standardization.

I think it's not unreasonable to speculate that all this decreases produc

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Terry Reedy" <[EMAIL PROTECTED]> writes:

> <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > In learning Python I've read more about Lisp than when I was actually
> > trying to learn it, and it seems that the two languages have lots of
> > similarities:
> >
> > http://www.norvig.com/python-lisp.html
> >
> > I'm wondering if someone can explain to me please what it is about
> > Python that is so different from Lisp that it can't be compiled into
> > something as fast as compiled Lisp?  From this above website and
> > others, I've learned that compiled Lisp can be nearly as fast as C/C++,
> 
> In order to be that fast, some of the dynamism of intepreted Lisp must be 
> given up.  In particular object code is not list data.  

I'm not entirely sure what you are talking about, but you're almost certainly
very confused about something. Not all common lisp implementations even have
an interpreter (which doesn't tend to be visible to the user).

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

py-ext: casting pointers to ints on 32bit and 64bit systems

[Alexander Schmolck]

what's the best approach to write C(++)-extension code that has to create a
python int from a C pointer and vice versa so that it works smoothly on 32 bit
and 64 platforms (on which sizeof(int) != sizeof(*void)) equally work (under
unix,mac&windows and with gcc, vc and borland)?

Currently the relevant code (in mlabraw.cpp available from
) looks like somthing like this:

/* C++ -> py */
Engine *ep;
[...]
return Py_BuildValue("i", int(ep))

and this:

/* py -> C++ */
int lHandle;
[...]
PyArg_ParseTuple(args, "is:get", &lHandle, &lName)

I've suggested modifications along the following lines to a user who had
problems building the module on a 64 bit system

/* C++ -> py */
Engine *ep;
[...]
return Py_BuildValue("l", long(ep))

/* py -> C++ */
long lHandle;
[...]
PyArg_ParseTuple(args, "ls:get", &lHandle, &lName)

This apparently works, so I'm now looking for the best way to adapt the source
code so that it will (ideally) compile out of the box on both 32 bit and 64
bit systems.

I guess the right type to use would be intptr_t (rather than #define something
to be int or long according to platform), but I don't know how well that is
supported by various C++ compilers. Also, is there something better than

#ifdef _A_64_BIT_PLATFORM
PyArg_ParseTuple(args, "ls:get", &lHandle, &lName)
#else
PyArg_ParseTuple(args, "is:get", &lHandle, &lName)
#endif
?

and how would I best go about #define'ing _A_64_BIT_PLATFORM?

thanks,

'as
-- 
http://mail.python.org/mailman/listinfo/python-list