Re: Lisp-likeness

[Jacek Generowicz]

"Carl Banks" <[EMAIL PROTECTED]> writes:

> Michele Simionato wrote:
> > Carl Banks:
> > > If Python did it the way Scheme did, this would be pretty useless.
> >
> > But notice that Scheme has no problems whatsoever:
> >
> > (define (toplevel)
> >   (define a 1)
> >   (define (f)
> > (display a))
> >   (set! a 2)
> >   (f))
> >
> > (toplevel)
> >
> > prints 2 the same as in Python.
> 
> Hmm. On closer inspection, I'm going to have to amend my implictation
> of Scheme: the example poster was cheating.  Scheme and Python both do
> closures the same way.  However, the Scheme snippet in the original
> example used a let-block.  I.e., it introduced a new scope, whereas the
> Python example did not (because it doesn't have anything like let).

Yes, we've been over this many times. I'm surprised that Michele
hasn't yet referenced the thread where we exposed the gory details, as
was his custom for a while :-)



Message-ID: <[EMAIL PROTECTED]>, for this particular
aspect, in case anyone gives a monkey's left testicle.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Logging global assignments

[Jacek Generowicz]

Larry Bates <[EMAIL PROTECTED]> writes:

> Suggestion:
> Use ConfigParser to set your globals instead and you can track
> your assignments over each file, section and option in the file.

I would dearly love to go down this sort of route but, unfortunately,
they are not _my_ configuration files, and it is not _my_
configuration mechanism ... it's just the one I have to work with. I
do not have the freedom to change it; I merely have to try to make
some sense out of it :-(
-- 
http://mail.python.org/mailman/listinfo/python-list

Logging global assignments

[Jacek Generowicz]

I am dealing with an application which reads in configurations by
calling (a wrapper around) execfile. Any configuration file may itself
execfile other configuration files in the same manner.

I would like to create a log containing all global assignments made in
these files. Comparing the globals dictionaries before and after is
not quite enough, as 

a) this misses multiple assignments to the same name, within a single
   file,

b) doesn't allow me to pinpoint the line at which the assignment is
   made.

Inspecting the implementation of execfile suggests to me that the
assignments are performed by a hard-wired call to PyDict_SetItem, in
the opcode implementations, so it looks like ideas based on giving
execfile a globals dictionary with an instrumented __setitem__ are
probably doomed to failure.

Is there any way of injecting some of my code into the process of
global name binding, or some other means of "capturing" global
assignments ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.4 removes None data type?

[Jacek Generowicz]

Warren Postma <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
> 
> > I just read in the 'What's New in Python 2.4' document that the None
> > data type was converted to a constant:
> > http://python.org/doc/2.4/whatsnew/node15.html
> 
> Implication: A long standing wart in Python now gone.  Its time to
> gloat. Are there any really evil glitches LEFT in Python?

Python 2.4 (#1, Dec  1 2004, 14:23:15) 
[GCC 3.2.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> True, False = False, True
>>> True
False
>>> 

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

Re: type of simple object

[Jacek Generowicz]

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

> Hello Jacek,
> 
> Thanks for the answer,
> 
> Can you tell me how can I check if an object is a sequence (you are
> right, this is actually what I want)?

You try to use it as a sequence. If it works, then it was a
sequence. If it was not a sequence, you handle the exception and do
something appropriate.

For example:

>>> def f(seq, something):
... try:
... number = sum(something)
... except TypeError:
... number = something
... return [number*item for item in seq]
... 
>>> f([1,2,3], 4)
[4, 8, 12]
>>> f([1,2,3], [1,2,3])
[6, 12, 18]
>>> f([1,2,3], (1,2,3))
[6, 12, 18]
>>> f([1,2,3], {1:'one', 2:'two', 3:'three'})
[6, 12, 18]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: type of simple object

[Jacek Generowicz]

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

> Thank you guys.
> 
> My function should multiply every element  of a list, for example
> "something"
> and "something" can be an integer or another list.
> If it deals with integer than it is ok, but
> If it deals with list than it become false for example list*2 =
> listlist, and what I really want is to mutlitply its member.

Which member? A list can have many members ... or none at all.

> That's why I need to know the type of my data in "something".

No, you don't need to know its type at all. You need to know whether
it is a sequence or not ... which is a far cry from knowing its type.

> By the way I am new in python, I heard that it has a MatLab
> capabilities, How good is that?

Depends on what you mean by "MatLab capabilities". Matlab is highly
matrix oriented, therefore it provides lots of fast matrix operations,
and syntactic sugar for dealing with matrices. If you want to think of
everything as a matrix, then you could well be disappointed by
Python. 

There is a package for driving matlab from Python, which you might
find interesting (it might even be what you meant by "MatLab
capabilities"). Google is your friend.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: type of simple object

[Jacek Generowicz]

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

> The result 
> How can I check it since it is not a string right?

It is a type, which is a first-class object in its own right.

type('hello') == str

However, I reiterate, you almost certainly don't really care about
what the actual type is. To care about the actual type is to struggle
against a fundamental feature of python: Duck Typing.

Yes, I admit, there are situations in which you might really care
about the actual type. However, given that you do not know how to
check the type in Python, the chances are rather high that you are
sufficienly new to Python to not realize that, typically, you need not
(and should not) care about the actual type. The chances are that you
are trying to program in a style which you learned in another
language, and which not the most productive in Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's idiom for function overloads

[Jacek Generowicz]

Philippe Fremy <[EMAIL PROTECTED]> writes:

> Enforcing types also brings the benefit that the program is more
> deterministic. In my experience, there is a lot more benefits to have
> an object whose type is clearly identified than to have function that
> accepts generic objects.
> 
> 
> I would go as far as saying that variables should have immutable
> types.

If you really believe this, then I would go as far as saying that you
would be happier in a language other than Python.

> It is more restricting that what python provides currently, but
> leads to clearer programming practice: the intent of the developer
> shows up in the type he uses.

Not in my opinion or experience.

To each his own, and vice versa.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: type of simple object

[Jacek Generowicz]

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

> How do I know type of simple object is tuple or list or integer, for
> example my function should understand what is the object type passed in
> its argument


Answers ordered in decreasing degree of Pythonicity:

1) You are mistaken, the function almost certainly should not care
   whether the object is a tuple or a list (or integer)[1].

2) isinstance(obj, list) etc.

3) type(obj)



[1] You probably want to check whether the object is capable of doing
whatever it is that you expect lists or tuples to do for you. For
example: 


def total(object):
try:
return sum(object) # The list-or-tuple case
except TypeError:
return object  # The integer case

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

Re: Next step after pychecker

[Jacek Generowicz]

Paul Rubin  writes:

> Philippe Fremy <[EMAIL PROTECTED]> writes:
> > I would like to develop a tool that goes one step further than
> > pychecker to ensure python program validity. The idea would be to get
> > close to what people get on ocaml: a static verification of all types
> > of the program, without any kind of variable declaration. This would
> > definitely brings a lot of power to python.
> 
> You know, I've always thought that ML-style type inference is an
> impressive technical feat, but why is it so important to not use
> declarations?  This is an aspect I've never really understood.

You gain something akin to duck typing, though in a formalized way
(type classes). The code works for any types which provide the
features which are used in the code, without regard for the specific
type. You gain generic programming.

You also gain not having to clutter your code with all the type
declarations. And you gain not having to decide what types you will
use too early on in development.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's idiom for function overloads

[Jacek Generowicz]

"F. GEIGER" <[EMAIL PROTECTED]> writes:

> As Philippe already said, use objects that support the protocol or decide
> what to do with it after having checked its type. I do that, if I have to,
> like so:
> 
> 1  def doIt(arg):
> 2if type(arg) == type([]):
> 3map(doIt, arg)
> 4 else:
> 5# Do it on a scalar type
> 6# ...
> 7return result

Now, consider that line 3 would execute very happily if the type of
arg were 

1) list, 
2) str,
3) tuple,
4) dict,
5) file,
6) any other built-in iterable or sequence,
7) any useer-defined iterable or sequence,
8) a subclass of any of the above,
9) god knows what else ...

... yet in line 2 you have ensured that the whole function will not
work properly for any of the listed types other than the first.

You could make the code much more general by doing it like this:

try:
map(doIt, arg)
except TypeError:
...


The important thing to note is that the actual types of Python objects
are usually not very interesting or important at all. What is much
more important is what the object is able to do: what messages it
understands, what protocols it supports.

Hiding some code behind a type-check, in Python, is quite frequently
the wrong thing to do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's idiom for function overloads

[Jacek Generowicz]

Philippe Fremy <[EMAIL PROTECTED]> writes:

>   Hi Frans,
> 
> > Since Python doesn't have static typing, how is the same result as
> > traditional function overloads results in acheived?
> 
> 
> With dynamic typing obviously. :-)
> 
> You can not reproduce the C++ overload idiom

Of course you can. Use a multimethod of some sort.

The canonical answer to the OQ, of course, includes things like
"Consider whether you really want/need to do this" and "duck typing".

Frequently, in Python, code which checks for types, rather than
checking for features, ends up being excessively restrictive and
insufficiently general.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: variable declaration

[Jacek Generowicz]

"Michael Tobis" <[EMAIL PROTECTED]> writes:

> In fact, I'd recommend a paragraph early in the Nutshell book saying
> "there are no declarations, no use strict, no implicit none, sorry,
> forget it",

It would have to be a pretty long paragraph, if it were to list all
the things that you do NOT find in Python.

> and an index listing under "declarations" pointing to a detailed
> exegesis of their nonexistence.

Think about this. You are either asking that the book's author
anticipate your personal expectations, and write the book to cater for
YOUR PERSONAL expectiations ... or you are asking for a book with an
inifititely long index. The list of things absent from Python is
infinite.

> It would have saved me some time.

You don't want a book, you want a personal tutor.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from __future__ import decorators

[Jacek Generowicz]

Tim Roberts <[EMAIL PROTECTED]> writes:

> Jacek Generowicz <[EMAIL PROTECTED]> wrote:
> >
> >I have some code, which makes copious use of the @decorator syntax
> 
> I'm very curious to know what kind of application you are writing in which
> "copious use of the @decorator syntax" actually solved a problem
> productively.

An application in which, before python2.4, I used to have lots of code
that looked like

def somefun(...):
...
somefun = somedecorator(somefun)

:-)


It's not interesting to discuss what "somedecorator" actually
represents. But being able to see that the function is decorated right
next to the "def", as opposed to having to look beyond the end of the
definition certianly makes a significant difference to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from __future__ import decorators

[Jacek Generowicz]

Skip Montanaro <[EMAIL PROTECTED]> writes:

> Jacek> Crazy idea ... would it be possible to shadow 2.3's parser with
> Jacek> one stolen from 2.4 ?
> 
> If you're willing to go to that much trouble, why not just upgrade to 2.4?

*I* upgraded to 2.4 sometime when it was in alpha.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from __future__ import decorators

[Jacek Generowicz]

Peter Otten <[EMAIL PROTECTED]> writes:

> Have a look at Bill Mill's redecorate utility:
> 
> http://llimllib.f2o.org/files/redecorate.py

Heh, this is exactly the sort of thing I wanted do avoid writing, as
it would be difficult to get right. Looks like it's author has similar
feelings. However, it could well be the most pragmatic solution in my
case.

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

Re: from __future__ import decorators

[Jacek Generowicz]

Thomas Heller <[EMAIL PROTECTED]> writes:

> Jacek Generowicz <[EMAIL PROTECTED]> writes:
> 
> > I have some code, which makes copious use of the @decorator syntax
> > which was introduced in Python2.4. Now I find myself in a situation
> > where I have to run the code under Python 2.3. However, I would like
> > to keep developing the code with the new syntax.
> >
> > How could I best automate the process of making the syntax digestible
> > by Python2.3 ?
> 
> The only way that I know of is this, although you have to rewrite your
> code somewhat:

The whole point would be to keep on developing perfectly normal
Python2.4 code, but have some means of getting it to run on 2.3,
without modification.

> http://dirtsimple.org/2004/11/using-24-decorators-with-22-and-23.html

Certainly an interesting approach. Perhaps this can be combined with a
simple textual transformation of the source code which simply replaces
@decorator with add_assignment_advisor(decorator) ... or something
along those lines.

Still, I'd prefer to find a solution on the AST level, but I guess
that's not possible without re-writing the praser.

Crazy idea ... would it be possible to shadow 2.3's parser with one
stolen from 2.4 ?
-- 
http://mail.python.org/mailman/listinfo/python-list

from __future__ import decorators

[Jacek Generowicz]

I have some code, which makes copious use of the @decorator syntax
which was introduced in Python2.4. Now I find myself in a situation
where I have to run the code under Python 2.3. However, I would like
to keep developing the code with the new syntax.

How could I best automate the process of making the syntax digestible
by Python2.3 ?

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

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

Donn Cave <[EMAIL PROTECTED]> writes:

> List incomprehensions do not parse well in my eyes.

Are you familiar with the Haskell syntax for list comprehensions?

For example:

 
http://www.zvon.org/other/haskell/Outputsyntax/listQcomprehension_reference.html

Does their striking similarity to mathematical set notation help at
all ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

Jeff Shannon <[EMAIL PROTECTED]> writes:

> I guess we'll have to agree to disagree

Indeed :-)

> I find that reading a lambda requires mentally pushing a stack frame
> to parse the lambda and another to translate map() into a loop,
> whereas a list comp's expression doesn't require such a shift

>  From the sounds of it, you may have the opposite experience with
>  reading map/lambda vs. reading list comps

No, I'm perefectly happy with both. I'm just trying to understand the
underlying reasons for people having trouble with one or the other, in
order to be better armed when the didactic need might arise.

One more question. Imagine that Python had something akin to Smalltalk
code blocks. Would something like

map([x | x+1], seq)

be any better for you than

map(lambda x:x+1, seq)

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

Re: The limitation of the Photon Hypothesis

[Jacek Generowicz]

Steve Holden <[EMAIL PROTECTED]> writes:

> Steve Horsley wrote:
>
> > Also, I think you probably accidentally posted to the wrong
> > newsgroup.
> 
> No, he deliberately posted to the wrong newsgroup.

Heh ... I initially read the subject line as "The limitation of the
Python Hypothesis".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

Steve Holden <[EMAIL PROTECTED]> writes:

> Well, I suspect that Church originally chose lambda precisely because
> of its meaninglessness,

IAANM, Church didn't choose lambda at all. He chose to put a "hat"
(like a circumflex accent) above the bound name. Then, because of some
typesetting difficulties, this was transformed into the nearest thing
that looked like it: a capital lambda in front of the name ... and
later the capital lambda turned into a lowercase one.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

Jeff Shannon <[EMAIL PROTECTED]> writes:

> Jacek Generowicz wrote:
> > "Anna" <[EMAIL PROTECTED]> writes:
> >
> >>But first, wouldn't something like:
> >>
> >>[x+1 for x in seq]
> >>
> >>be even clearer?
> > I'm glad you mentioned that. [...]
> 
> > As to whether it is clearer. That depends. I would venture to suggest
> 
> > that, given a pool of laboratory rats with no previous exposure to
> > Python, more of them would understand the map-lambda than the list
> > comprehension.
> 
> 
> I would venture to suggest the exact opposite, that the syntax of a
> list comprehension is in itself suggestive of its meaning, while 'map'
> and 'lambda' are opaque until you've researched them.

In the population of all laboratory rats, I think that the proportion
that would understand either form, would be as good as zero.

Given a population with previous exposure to computer programming, my
money is on the map-lambda version. But this last point is mostly
irrelevant. The fact is that you cannot program computers without
doing a bit of learning ... and the lambda, map and friends really do
not take any significant learning.

> Speaking for *this* laboratory rat, at least, map/lambda was always a
> nasty puzzle for me and difficult to sort out.  But when list comps
> were introduced, after reading just a sentence or two on how they
> worked, they were completely clear and understandable -- much more so
> than map/lambda after many months of exposure.

Forgetting about lambda, map, filter and reduce, do you find that you
pass callables around in your Python programs, or is this not
typically done in your programs?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

"Anna" <[EMAIL PROTECTED]> writes:

> Jacek Generowicz wrote:
> > "Anna" <[EMAIL PROTECTED]> writes:
> >
> > > With class and def, I at least have a *name* to start with - class
> > > Square pretty obviously is going to have something to do with
> > > geometric shapes, I would hope (or maybe with boring people...).
> >
> > Or maybe with multiplying something by itself. Or maybe the author
> > made some changes in his program, and forgot to rename the class
> > sensibly, and the class' functionality has nothing to do with squares
> > of any sort any more. Or maybe he felt the name "Square" was very
> > appropriate for something else in his program and inadvertently gave
> > the same name to two different entities thereby clobbering the one
> > whose use was intended at this point.
> 
> Idjits abound. ;-)

Yup ... which is one reason why lambda is so useful. Everything there
is to know about it is right in front of your eyes. There is no chance
that some idjit changed the meaning of lambda, or the code which
appears within it (unless that refers to some external names, of
course).

> > So, IIUC, you consider
> >
> >def add_one(x):
> >return x+1
> >
> >map(add_one, seq)
> >
> > to be clearer than
> >
> >map(lambda x:x+1, seq)
> 
> Completely, totally, and unambiguously:

Curious. It's very much the other way around for me.

> the version with the defined function is immediately clear to me;
> the version with the lambda is decipherable, but requires
> deciphering (even at 2nd and 3rd glance).  But first, wouldn't
> something like:
> 
> [x+1 for x in seq]
> 
> be even clearer?

I'm glad you mentioned that. My next question was going to be
something along the lines of what you think of the equivalent list
comprehension, which is spectacularly devoid of any names to give you
any hints whatsoever.

As to whether it is clearer. That depends. I would venture to suggest
that, given a pool of laboratory rats with no previous exposure to
Python, more of them would understand the map-lambda than the list
comprehension. 

There are no words in the list comprehension at all (besides the
common "seq"): it's all syntax. Even if "map" and "lambda" ring no
bells by association with anything you might have learned outside of
Python, they sure are a lot easier to look up in the documentation.

> Given an example more complex (which you must admit, lambdas usually
> are)

Well, they can't be _that_ much more complex in Python :-) But I'll
grant you, they are often more complex that the one above.

> - the name of the function is something my brain can hold on to to
> represent the group of operations; where with the lambda, I need to
> mentally go through each operation each time I try to read it. And the
> more complex f is, the harder time I have holding it all in my head
> while I figure out how to get from the beginning value x to the ending
> value f(x). lambda is an O(N*N) problem for my brain.

Fair enough. If I understand the code just by looking at it, then I
prefer to see it inline. If its meaning isn't obvious immediately,
then I'd go for the named function too. But I still value the ability
to inline-define the function while developing ... even if the inline
function will be outlined in the final product.

But, how do you feel about the individual lines of code in the body of
a multi-line function? They don't have individual names.

> I could see someone more mathematically-minded being happier with
> lambda. It's not, after all, the word "lambda" itself;

Aaah ... you did suggest (upthread) that it was the word itself which
gave you problems ... which is what piqued my interest.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

Nick Coghlan <[EMAIL PROTECTED]> writes:

> > Usually one or two have trouble grasping that "int" would be perfectly
> > adequate in this situation.
> 
> The ability to pass around functions at run-time was probably the
> hardest thing to get my head around when I started with Python,

And I suspect that this particular case is further complicated by the
fact that int is not a function ... it's a type!

I can imagine it might make a newbie's brain melt. Still, most of them
survive and thoroughly enjoy the course :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

"Anna" <[EMAIL PROTECTED]> writes:

> With class and def, I at least have a *name* to start with - class
> Square pretty obviously is going to have something to do with
> geometric shapes, I would hope (or maybe with boring people...).

Or maybe with multiplying something by itself. Or maybe the author
made some changes in his program, and forgot to rename the class
sensibly, and the class' functionality has nothing to do with squares
of any sort any more. Or maybe he felt the name "Square" was very
appropriate for something else in his program and inadvertently gave
the same name to two different entities thereby clobbering the one
whose use was intended at this point.

> def getfoo() tells me I'm the function is likely to go elsewhere and
> get something. It's a *start*,

All too often a start in the wrong direction.

> a handle, to deciphering whatever the following statements are
> doing. (Yes, I realize that often class and function names suck

Yup. I waste quite some time because of crappily chosen names.

> - but more often than not, they give *some* clue).
> 
> Whereas, with lambda - I have *nothing* to go on.

Aaah. OK, you object to lambda because it gives you no clue as to what
the function does, rather than with the word "lambda" itself? Is that
it?

So, IIUC, you consider

   def add_one(x):
   return x+1
   
   map(add_one, seq)

to be clearer than

   map(lambda x:x+1, seq)

?

> With lambdas, all I know is that the programmer wanted to hide
> whatever it is the program is doing behind the curtain...

I find this a strange way of looking at it, given that, with lambda,
what the program is doing is right there in front of your very eyes at
the very point at which it is doing it. Were there a name, _then_ you
could argue that the functionality is hidden ... and you would have to
look the name up, to make sure that it really represents what you
inferred it meant (and, to be absolutely sure, you'd have to double
check that it hasn't been rebound by some other part of the program in
some nasty way). None of these problems arise with lambda.

> IMHO, YMMV, etc etc

Of course. Same here.

> Personally, I like lambdas less than regular expressions (of which
> I'm particularly UNfond but understand their usefulness at
> times). At least with regular expressions - I know that the
> gibberish I need to decipher (probably) has to do with text
> parsing...

Hmm, that tells you about as much as lambda does. With lambda you know
that the gibberish you need to decipher has to do with functions :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

Nick Coghlan <[EMAIL PROTECTED]> writes:

> Jacek Generowicz wrote:
> > [*] Funnily enough, getting them to understand that "lambda x: fn(x)"
> > is just a very silly way of writing "fn", can be quite a struggle
> > at times ... but that's probably a consequence of the context in
> > which lambda is introduced.
> 
> If you genuinely taught them that, you may have done them a disservice:

Yes, I was wondering whether I should add lots of caveats to the above.

> Py> def f(x):
> ...print x
> ...
> Py> f1 = f
> Py> f2 = lambda x: f(x)
> Py> f1("hi")
> hi
> Py> f2("hi")
> hi
> Py> def f(x):
> ...   print x * 2
> ...
> Py> f1("hi")
> hi
> Py> f2("hi")
> hihi

There are far less contrived situations in which my original statement
(taken at face value) is wrong. Functions with optional arguments, for
example.

What actually happens is that some of them end up writing:

lambda x: int(x)

in a situation where they want to specify something which will perform
conversions of the type:

"123" -> 123   

ie, string to integer conversions.

Usually one or two have trouble grasping that "int" would be perfectly
adequate in this situation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

"Anna" <[EMAIL PROTECTED]> writes:

> Having taken some calculus (derivatives, limits, some integrals) but
> never even heard of lambda calculus, to me, lambda means absolutely
> NOTHING. Less than nothing.

And before you took calculus, the chances are that derivatives, limits
and integrals meant less than nothing to you.

But now, I am quite sure, you know that in Python lambda is a keyword
which creates anonymous functions. Now that you know what lambda does,
what's the problem with it? (It certainly doesn't mean "Less than
nothing" to you now.)

> So, I guess I don't like the word itself

Fair enough. I guess there are people out there who might have a
distaste for the word "class" or "def" or any of the other words which
are keywords in Python.

> Every other word in Python has an obvious meaning.  lambda doesn't.

Obvious to whom?

The meaning of every word is obvious, once you have been taught it;
and a complete mystery if you have not.

What do you make of "seq[2:-2]"? It means "less than nothing" to the
uninitiated. Just like lambda.

Getting students in my Python courses to understand "seq[2:-2]" takes
about as much (maybe even a bit more) effort as getting them to
understand lambda[*]. But once they have been taught these features,
they can handle them just fine.


[*] Funnily enough, getting them to understand that "lambda x: fn(x)"
is just a very silly way of writing "fn", can be quite a struggle
at times ... but that's probably a consequence of the context in
which lambda is introduced.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: spacing of code in Google Groups

[Jacek Generowicz]

Peter Hansen <[EMAIL PROTECTED]> writes:

> Jacek Generowicz wrote:
> > Peter Hansen <[EMAIL PROTECTED]> writes:
> >>Why the heck would I ever have to do "rectangle operations" on a
> >>regular basis?  ;-)
> > Well, given that all editors are cat equivalent[*], you don't _have_
> > to use any of their features :-)
> 
> This "cat equivalent" thing is a red-herring.  I can rarely type more
> than a line of code without making a typographical error.  Sometimes
> I won't catch that error until a bit later.  Using "cat" alone would
> provide me little opportunity to fix the error, so I would never
> be able to produce a working program longer than a few lines.

And have you ever tried to write a serious program on a Turing Machine?

This is exactly my point: Turing Equivalence is only theoretical. In
practise some languages are more powerful than others. Same goes for
editors.

> But the whole argument is fairly moot...  I've needed a rectangle
> operation only once in the last ten years,

Whereas I use rectangle operations, on average, a few times every day
... because they are part of my standard toolbox, they suggest
themselves as the right solution to many a problem.

There are plenty of programmers out there who "have only needed
classes once in the last ten years".

More powerful editors, just like more powerful languages, can make
their users more productive. Complicated editors, just like
complicated programming languages, can make their users less
productive[*]. The optimal point in complexity-expressiveness space
will be different for different individuals, be it for editors or
programming languages.


[*] I suspect that there are a few around here who would interpret
this as an indictment against the direction in which Python is
going :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: spacing of code in Google Groups

[Jacek Generowicz]

Peter Hansen <[EMAIL PROTECTED]> writes:

> Why the heck would I ever have to do "rectangle operations" on a
> regular basis?  ;-)

Well, given that all editors are cat equivalent[*], you don't _have_
to use any of their features :-)

But just like Python (particularly in the hands of a skilled Python
programmer) is more productive than a Turing Machine, any featureful
editor (in the hands of an experienced user) is far more productive
than "cat > file".


[*] A bit like Turing equivalence: any program you can write in any
other editor, you could also write with "cat > file"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: spacing of code in Google Groups

[Jacek Generowicz]

Peter Hansen <[EMAIL PROTECTED]> writes:

> Grant Edwards wrote:
> > I always rather liked line numbers (a-la 'can -n').  That also
> > makes discussion of the code easier:
> 
> That, unfortunately, is somewhat harder to remove without
> using a regular expression...

You mean to say that your editor does not have rectangle operations ? 
:-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cookbook 2nd ed Credits (was Re: The Industry choice)

[Jacek Generowicz]

[EMAIL PROTECTED] (Alex Martelli) writes:

> ...but each still gets ONE free copy...!-)

Who gets Luther Blissett's copy ? :-)

And are all the Luther Blissetts the same Luther Blisset ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Jacek Generowicz]

[EMAIL PROTECTED] (Alex Martelli) writes:

> I've always liked the (theoretical) idea that assertions (including of
> course contracts) could be used as axioms used to optimize generated
> code, rather than (necessarily) as a runtime burden.  E.g. (and I don't
> know of any implementation of this concept, mind you), inferring (e.g.
> from such assertions) that x>=0, and that y<0, the compiler could simply
> cut away a branch of dead code guarded by "if x warning, in this case;-)...

A few months ago, a troll challenged the denizens of comp.lang.lisp to
write a Lisp implementation of some some code which he posted in C++,
which would be competitive in terms of speed with his C++
version. The c.l.lers duly obliged, and, IIRC, it so happened that the
improvement that made the Lisp version overtake the C++ one was the
declaration of some variable to be of type "floating point number in
the range 0 to two Pi".

Of course, in CL type declarations are not contracts, but promises to
the compiler ... but it's still an examlpe of a situation where more
specific type information allowed the compiler to produce more
efficient code, in practice.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Docs. Hardcopy 2.4 Library Reference, interested?

[Jacek Generowicz]

"Brad Clements" <[EMAIL PROTECTED]> writes:

> Is anyone interested in purchasing a hardcopy version of the Python 2.4
> Library reference?
> 
> That is, assuming it was NOT  a direct print of current html/pdf versions.
> 
> So, nicely formatted for a printed book (spiral bound probably), with
> several indexes as appropriate, or perhaps a permutted index.
> 
> I'm thinking about doing this through lulu.com or cafepress, but it's going
> to take a lot of work to make a really nice printed version of the library
> reference from the LaTex source files (even via sgmlconv). Also wondering if
> I can get bleeds from either of these sites.
> 
> So, before I waste my time. Is anyone interested in such a beast? And if so,
> how much would you be willing to spend?
> 
> On demand printing still looks expensive to me. :-(

Brian Gough (Network Theory Ltd.) publishes Python manuals:

  http://www.network-theory.co.uk/python/

He sometimes reads this group; I've CCd him to give him a heads-up.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pre-PEP generic objects

[Jacek Generowicz]

Carlos Ribeiro <[EMAIL PROTECTED]> writes:

> On 06 Dec 2004 10:09:25 +0100, Jacek Generowicz
> <[EMAIL PROTECTED]> wrote:
> [great explanation about function descriptors]
> 
> Thanks. Now I know more about function descriptors than I ever wanted
> to :-) With a little polish,

Yeah, replace the two relevant instances of "it's" with "its" for a
start. It makes me cringe reading through it!

> this post would make a great addition to the descriptors
> documentation, don't you think?

I'm not sure what an appropriate place for it would be, and I don't
really have time to find out; if you do, feel free to use the material.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pre-PEP generic objects

[Jacek Generowicz]

Jp Calderone <[EMAIL PROTECTED]> writes:

> When the class object is created, the namespace is scanned for
> instances of .  For those and only those, a
> descriptor is created which will produce bound and unbound methods.

This isn't quite correct. A descriptior is any object which has
callable attributes called "__get__", "__set__" or "__delete__". Pure
Python functions *are* descriptors:

>>> import types
>>> for name in '__get__', '__set__', '__delete__':
... print name, name in dir(types.FunctionType)
... 
__get__ True
__set__ False
__delete__ False


because they have a __get__ attribute. Builtin functions are not
descriptors:

>>> for name in '__get__', '__set__', '__delete__':
... print name, name in dir(types.BuiltinFunctionType)
... 
__get__ False
__set__ False
__delete__ False

because they do not have any of these.


It is the FunctionType.__get__ which is responsible for the binding of
methods. You can see this for yourself by calling it directly:

>>> class Foo(object):
... pass
... 
>>> def bar():
... pass
... 
>>> bar.__get__(None, Foo)

>>> bar.__get__(Foo(), Foo)
>

Note that if FunctionType.__get__ is passed both an instance and a
class, then it returns a bound method. If it is only passed a class,
then it returns an unbound method.

So, let's write a little descriptior which merely reports what
arguments it's __get__ method receives:

>>> class Test__get__(object):
... def __get__(*args):
... return args
... 

Let's add an instance of this as a class attribute to Foo:

>>> Foo.test = Test__get__()

... and see what happens when you access it through the class:

>>> Foo.test
(<__main__.Test__get__ object at 0x40171b8c>, None, )

... and what happens when you access it via an instance of the class:

>>> Foo().test
(<__main__.Test__get__ object at 0x40171b8c>, <__main__.Foo object at 
0x40171a4c>, )

Observe that when accessing the attribute through the class, __get__
is not passed any instance, which tells __get__ to return an unbound
method (as we saw above). If it is accessed through an instance,
__get__ is passed both an instance and its class, which tells __get__
to return a bound method.

The question remains "Why is __get__ called when an attribute is
looked up?" The answer is "Because that's what __getattribute__
does". Which __getattribute__? That depends. If you access via the
class, then it's type.__getattribute__, if you access through an
instance of the class, then it's object.__getattribute__. More
generally, an attribute access such as

X.Y

is equivalent to

   type(X).__getattribute__('Y')

So, the type of object whose attribute you are looking up, determines
(via it's __getattribute__ method) the arguments that the attribute's
__get__ will be passed.

Note that __getattribute__ of ModuleType, does *not* invoke this
descriptor protocol of functions at all ... otherwise, all
module-level functions would be turned into methods !
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: decorators ?

[Jacek Generowicz]

BJörn Lindqvist <[EMAIL PROTECTED]> writes:

> I think the essence of decorators is that it makes it possible to do
> in Python what you in other languages do with method qualifiers.

I find it fascinating that the addition of a bit of syntax sugar gives
the perception that a whole range of new and previously unthinkable
possibilities have opened themselves before us.

@X
def Y...
...


is merely syntax sugar (or syntax ammonia, for some) for


def Y...
...
Y = X(Y)

Anything you can do with decorators, you could do before (with the
exception of rebinding the __name__ of functions).

And yet, that bit of syntax sugar really _does_ make a big difference
to the lengths that people are prepared to take the possibilities that
the underlying feature affords them.
-- 
http://mail.python.org/mailman/listinfo/python-list