Re: Python becoming less Lisp-like

[Terry Reedy]

"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> And does this code object know which non-local names are on an
> intermediate level and which are global?

Yes (from 2.2):
>>> import dis
>>> x = 1
>>> def f():
...   y = 2
...   def g():
...z = 3
...print x,y,z
...   return g
...
>>> dis.dis(f)
  0 SET_LINENO   1

  3 SET_LINENO   2
  6 LOAD_CONST   1 (2)
  9 STORE_DEREF  0 (y)

 12 SET_LINENO   3
 15 LOAD_CLOSURE 0 (y)
 18 LOAD_CONST   2 (", line 3>)
 21 MAKE_CLOSURE 0
 24 STORE_FAST   1 (g)

 27 SET_LINENO   6
 30 LOAD_FAST1 (g)
 33 RETURN_VALUE
 34 LOAD_CONST   0 (None)
 37 RETURN_VALUE
>>> g = f()
>>> dis.dis(g)
  0 SET_LINENO   3

  3 SET_LINENO   4
  6 LOAD_CONST   1 (3)
  9 STORE_FAST   0 (z)

 12 SET_LINENO   5
 15 LOAD_GLOBAL  1 (x)
 18 PRINT_ITEM
 19 LOAD_DEREF   0 (y) # intermediate value
 22 PRINT_ITEM
 23 LOAD_FAST0 (z)
 26 PRINT_ITEM
 27 PRINT_NEWLINE
 28 LOAD_CONST   0 (None)
 31 RETURN_VALUE

Terry J. Reedy



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

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

[TLOlczyk]

On 16 Mar 2005 06:37:45 -0500, Carl Shapiro <[EMAIL PROTECTED]>
wrote:

>I have a virtually completed port of CMUCL to Win32.  And, if I was
>not busy organizing a Lisp conference, it would be publicly available
>by now.

If it's the conference I think, then the deadline for papers was about
a week ago. I suspect that most of the other routine parts have been
taken care of leaving scheduling. IOW your time is freeing up. 

OTOH it may just be wishful thinking on my part. Any idea how much
longer?





The reply-to email address is [EMAIL PROTECTED]
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Antoon Pardon]

Op 2005-03-22, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-03-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>> 
>>>Antoon Pardon wrote:
>>>
Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>:

I find it odd that you start by saying you still find them very
consistent and here state there is a slight inconsistency.
>>>
>>>I said that the way that binding a name on a class instance always 
>>>creates an instance attribute regardless of the presence of a 
>>>similarly-named class attribute is consistent with the way that name 
>>>binding works in any scope.  This is true.  Binding of a name within a 
>>>function-local scope works the same way -- bindings are always created 
>>>within the narrowest scope unless something is explicitly done to 
>>>force other behavior.
>> 
>> 
>> But bindings in function scope happen earlier. There already
>> happens some kind of binding at call time. If it wouldn't
>> you wouldn't get an UnboundLocalError but just a NameError.
>> What seems to happen is that at call time all local variable
>> get prebound to somekind of illegal value and if they still have
>> this illegal value when you acces them, python raises the
>> UnboundLocalError
>> 
> They don't get pre-bound to some kind of illegal value. The parser 
> determines due to the presence in the function's code of an assignment 
> with that name as object - by STATIC analysis - that the name is local, 
> and therefore generates local references for it. It's the failure of a 
> local read that gives rise to the UnboundLocalError.
>
> If you want to talk about this as a binding you can, I suppose. In 
> actual fact, though, it's the code object's co_names attribute that says 
> which names are to be regarded as local, as far as I understand it.

And does this code object know which non-local names are on an
intermediate level and which are global? If not it seems the
binding has to be more than just the code object's co_names attribute.

>> To have something consistent with that with instances and classes
>> would mean that the interpreter would find out what attributes could
>> possible be created and do the samekind of prebindind so that if you
>> accessed such an attribute you wouldn't get an AttributeError but
>> something like an UnboundAttributeError.
>> 
> You appear to be asking for a very explicit (and extremely ambitious) 
> type of optimization here.

You misunderstand. I don't ask for this. I just argue that this is
what should happen in order to make what happens in function scope
and what happens with attributes (more) consistent with each other.

What I was wondering, doesn't __slots__  do something like this?

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

Re: Python becoming less Lisp-like

[Steve Holden]

Antoon Pardon wrote:
Op 2005-03-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
Antoon Pardon wrote:
Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>:
I find it odd that you start by saying you still find them very
consistent and here state there is a slight inconsistency.
I said that the way that binding a name on a class instance always 
creates an instance attribute regardless of the presence of a 
similarly-named class attribute is consistent with the way that name 
binding works in any scope.  This is true.  Binding of a name within a 
function-local scope works the same way -- bindings are always created 
within the narrowest scope unless something is explicitly done to 
force other behavior.

But bindings in function scope happen earlier. There already
happens some kind of binding at call time. If it wouldn't
you wouldn't get an UnboundLocalError but just a NameError.
What seems to happen is that at call time all local variable
get prebound to somekind of illegal value and if they still have
this illegal value when you acces them, python raises the
UnboundLocalError
They don't get pre-bound to some kind of illegal value. The parser 
determines due to the presence in the function's code of an assignment 
with that name as object - by STATIC analysis - that the name is local, 
and therefore generates local references for it. It's the failure of a 
local read that gives rise to the UnboundLocalError.

If you want to talk about this as a binding you can, I suppose. In 
actual fact, though, it's the code object's co_names attribute that says 
which names are to be regarded as local, as far as I understand it.

To have something consistent with that with instances and classes
would mean that the interpreter would find out what attributes could
possible be created and do the samekind of prebindind so that if you
accessed such an attribute you wouldn't get an AttributeError but
something like an UnboundAttributeError.
You appear to be asking for a very explicit (and extremely ambitious) 
type of optimization here.


You pointed out a case in which class/instance attributes behave 
slightly differently than local/global names do, and I agree with you 
that there is a difference in behavior there.  However, that 
difference is in the way that bare names are resolved into 
local/global references, and *not* in the way that name binding works. 

Well I don't agree. If name binding would work the same, I would
expect other exceptions.

 The name binding rules are consistent; the inconsistency is in name 
*lookups*,

I'm not convinced. The lookup can find out about such cases on
intermediate scopes. I doubt that the lookup knows at the start
at what level he is going to find the name. So either he keeps
the name of local variables of each function somewhere, to do
the special case if the variable is local on that level or the
name has to be prebound somehow.


and is a case of strong optimization of the standard case 
affecting the behavior of an unusual (and strongly discouraged) case. 

That only affects the behaviour of an unusual (and strongly discouraged)
case, doesn't make it consistent. It may be a good argument for choosing
to do it this way despite it being (slightly) inconsisten. It is not
an argument for it being consistent.

 There is a slight inconsistency in something *other* than what the 
O.P. was complaining about being inconsistent; I'm recognizing that 
inconsistency at the same time as I'm attempting to point out that the 
other "inconsistency" really *is* consistent.  (I'm also pointing out 
that this name-lookup inconsistency is a good example of "practicality 
beats purity", because the value of the optimization is, IMO, much 
greater than the cost of the inconsistency.)

I'm not so sure, but I'm not going to argue this.
Great. I though you were going to start up with the snails again ... :-)
regards
 Steve
--
Meet the Python developers and your c.l.py favorites March 23-25
Come to PyCon DC 2005  http://www.pycon.org/
Steve Holden   http://www.holdenweb.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Antoon Pardon]

Op 2005-03-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>> 
>> I find it odd that you start by saying you still find them very
>> consistent and here state there is a slight inconsistency.
>
> I said that the way that binding a name on a class instance always 
> creates an instance attribute regardless of the presence of a 
> similarly-named class attribute is consistent with the way that name 
> binding works in any scope.  This is true.  Binding of a name within a 
> function-local scope works the same way -- bindings are always created 
> within the narrowest scope unless something is explicitly done to 
> force other behavior.

But bindings in function scope happen earlier. There already
happens some kind of binding at call time. If it wouldn't
you wouldn't get an UnboundLocalError but just a NameError.
What seems to happen is that at call time all local variable
get prebound to somekind of illegal value and if they still have
this illegal value when you acces them, python raises the
UnboundLocalError

To have something consistent with that with instances and classes
would mean that the interpreter would find out what attributes could
possible be created and do the samekind of prebindind so that if you
accessed such an attribute you wouldn't get an AttributeError but
something like an UnboundAttributeError.

> You pointed out a case in which class/instance attributes behave 
> slightly differently than local/global names do, and I agree with you 
> that there is a difference in behavior there.  However, that 
> difference is in the way that bare names are resolved into 
> local/global references, and *not* in the way that name binding works. 

Well I don't agree. If name binding would work the same, I would
expect other exceptions.

>   The name binding rules are consistent; the inconsistency is in name 
> *lookups*,

I'm not convinced. The lookup can find out about such cases on
intermediate scopes. I doubt that the lookup knows at the start
at what level he is going to find the name. So either he keeps
the name of local variables of each function somewhere, to do
the special case if the variable is local on that level or the
name has to be prebound somehow.

> and is a case of strong optimization of the standard case 
> affecting the behavior of an unusual (and strongly discouraged) case. 

That only affects the behaviour of an unusual (and strongly discouraged)
case, doesn't make it consistent. It may be a good argument for choosing
to do it this way despite it being (slightly) inconsisten. It is not
an argument for it being consistent.

>   There is a slight inconsistency in something *other* than what the 
> O.P. was complaining about being inconsistent; I'm recognizing that 
> inconsistency at the same time as I'm attempting to point out that the 
> other "inconsistency" really *is* consistent.  (I'm also pointing out 
> that this name-lookup inconsistency is a good example of "practicality 
> beats purity", because the value of the optimization is, IMO, much 
> greater than the cost of the inconsistency.)

I'm not so sure, but I'm not going to argue this.

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

Re: Python becoming less Lisp-like

[Jeff Shannon]

Antoon Pardon wrote:
Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>:
I find it odd that you start by saying you still find them very
consistent and here state there is a slight inconsistency.
I said that the way that binding a name on a class instance always 
creates an instance attribute regardless of the presence of a 
similarly-named class attribute is consistent with the way that name 
binding works in any scope.  This is true.  Binding of a name within a 
function-local scope works the same way -- bindings are always created 
within the narrowest scope unless something is explicitly done to 
force other behavior.

You pointed out a case in which class/instance attributes behave 
slightly differently than local/global names do, and I agree with you 
that there is a difference in behavior there.  However, that 
difference is in the way that bare names are resolved into 
local/global references, and *not* in the way that name binding works. 
 The name binding rules are consistent; the inconsistency is in name 
*lookups*, and is a case of strong optimization of the standard case 
affecting the behavior of an unusual (and strongly discouraged) case. 
 There is a slight inconsistency in something *other* than what the 
O.P. was complaining about being inconsistent; I'm recognizing that 
inconsistency at the same time as I'm attempting to point out that the 
other "inconsistency" really *is* consistent.  (I'm also pointing out 
that this name-lookup inconsistency is a good example of "practicality 
beats purity", because the value of the optimization is, IMO, much 
greater than the cost of the inconsistency.)

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

Re: Python becoming less Lisp-like

[Antoon Pardon]

Op 2005-03-18, Bengt Richter schreef <[EMAIL PROTECTED]>:
>
 [ ... ]
>
> BTW, I would like a re-assign or find-and-rebind operation spelled ":=" which 
> would
> make x := 123 mean look for x as if to read its value in a right hand side 
> expression,
> (except do not look into __builtins__) and wherever found, rebind to 123 -- 
> and if not found,
> raise an exception.
>
> I think var := 'something' would be a useful substitute for the idiom of
> var[0] = 'something' and be unambiguous.
>
> ":=" as an operator could combine like = if desired, so we could write
> var +:= some.long.expression[that].you('do')**not.want.to.type.twice
> instead of
> _ = some.long.expression[that].you('do')**not.want.to.type.twice
> var +:= _  # meaning var := var + _
> or such.

Well you have my support for this. But I have the impression this
differs from the previous time you came up with a similar idea.
If IRC your previous proposal limited the search to the local
scope, making a := b equivallent to something like a; a = b.

I must say I like your current idea better.

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

Re: Python becoming less Lisp-like

[Antoon Pardon]

Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>> 
>>>Bruno Desthuilliers wrote:
>>>
- if x is a class attribute of class A and a is an instance of A, 
a.x=anyvalue create a new instance attribute x instead of modifying A.x
>>>
>>>This is very consistent with the way that binding a name in any scope 
>>>will shadow any bindings of that name in "higher" scopes.  It is the 
>>>same principle by which one is able to use the same name for a 
>>>function-local variable that is used for a global variable, without 
>>>destroying that global variable.  [...]
>> 
>> Not entirely. The equivallent is imposible in function scope.
>> If function scope would work exactly equivallent as the
>> above the following should work 
>> 
>> a = 42
>> def f():
>>   a = a + 1
>>   print a
>> print a
>> 
>> And the result should be:
>> 
>> 43
>> 42
>> 
>
> I'd still say that the name binding rules are very consistent.  The 
> name lookup rules are a little different (as they *should* be for 
> class/instance attributes),

Why should they? 

> and that's why there's a different net 
> effect (UnboundLocalError) as shown in your example.  I'd say, 
> however, that if there's a special case here it's with the 
> function-local variables, not the class/instance attributes.

Which is the special case and which is the normal case is not
that important here. The fact is that they behave different,
so you can't claim it is very consistent.

I'm getting the impression that 'consistent' just means:
that is how python works, on this newsgroup.

> It's the 
> optimizations to the function-local namespace which prevent 
> transparent re-binding of global names.  And given that the 
> function-local namespace is by far the most heavily used, and the 
> relative utility (and wisdom) of using globals in this way, this is a 
> case where the benefit of the special case is well worth the cost of 
> its slight inconsistency.

I find it odd that you start by saying you still find them very
consistent and here state there is a slight inconsistency.

It seems we mean different things with "very consistent"

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

Re: Python becoming less Lisp-like

[Bengt Richter]

On Fri, 18 Mar 2005 09:16:42 -0800, Jeff Shannon <[EMAIL PROTECTED]> wrote:

>Antoon Pardon wrote:
>> Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>> 
>>>Bruno Desthuilliers wrote:
>>>
- if x is a class attribute of class A and a is an instance of A, 
a.x=anyvalue create a new instance attribute x instead of modifying A.x
>>>
>>>This is very consistent with the way that binding a name in any scope 
>>>will shadow any bindings of that name in "higher" scopes.  It is the 
>>>same principle by which one is able to use the same name for a 
>>>function-local variable that is used for a global variable, without 
>>>destroying that global variable.  [...]
>> 
>> Not entirely. The equivallent is imposible in function scope.
>> If function scope would work exactly equivallent as the
>> above the following should work 
>> 
>> a = 42
>> def f():
>>   a = a + 1
>>   print a
   f()   # ;-)
>> print a
>> 
>> And the result should be:
>> 
>> 43
>> 42
>>
IIRC, in some past version that used to be the way it worked (if you don't 
forget to call f() ;-)
I think it is logical. I.e., the right hand side of a = a + 1
is logically evaluated first, so the status at that time should IMO
determine the meaning of "a" -- i.e., look for it in an outer scope.
Next comes the local assignment of "a" which should create a local name
binding, but the code for determining the assigned value should IMO
be the code for the "a + 1" with no local binding of "a" yet existing.

I don't know how much code would break to go back to that, but maybe
not so much, since it's not legal now:

 >>> a = 42
 >>> def f():
 ... a = a +1
 ... print a
 ...
 >>> f()
 Traceback (most recent call last):
   File "", line 1, in ?
   File "", line 2, in f
 UnboundLocalError: local variable 'a' referenced before assignment
 >>> print a
 42

BTW, I would like a re-assign or find-and-rebind operation spelled ":=" which 
would
make x := 123 mean look for x as if to read its value in a right hand side 
expression,
(except do not look into __builtins__) and wherever found, rebind to 123 -- and 
if not found,
raise an exception.

I think var := 'something' would be a useful substitute for the idiom of
var[0] = 'something' and be unambiguous.

":=" as an operator could combine like = if desired, so we could write
var +:= some.long.expression[that].you('do')**not.want.to.type.twice
instead of
_ = some.long.expression[that].you('do')**not.want.to.type.twice
var +:= _  # meaning var := var + _
or such.

>
>I'd still say that the name binding rules are very consistent.  The 
They are consistent, but I have to say the function-body full lookahead to 
determine
local vs outer (not to mention normal function vs generator) jars my 
sensibilities.

>name lookup rules are a little different (as they *should* be for 
>class/instance attributes), and that's why there's a different net 
>effect (UnboundLocalError) as shown in your example.  I'd say, 
>however, that if there's a special case here it's with the 
>function-local variables, not the class/instance attributes.  It's the 
>optimizations to the function-local namespace which prevent 
>transparent re-binding of global names.  And given that the 
>function-local namespace is by far the most heavily used, and the 
>relative utility (and wisdom) of using globals in this way, this is a 
>case where the benefit of the special case is well worth the cost of 
>its slight inconsistency.
The optimization argument goes away with x := something I think, since
the x search can be limited to looking in the lexical environment
exactly like looking for read-only outer scope names now, just with
different consequences for finding or not finding.

Regards,
Bengt Richter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Jeff Shannon]

Antoon Pardon wrote:
Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
Bruno Desthuilliers wrote:
- if x is a class attribute of class A and a is an instance of A, 
a.x=anyvalue create a new instance attribute x instead of modifying A.x
This is very consistent with the way that binding a name in any scope 
will shadow any bindings of that name in "higher" scopes.  It is the 
same principle by which one is able to use the same name for a 
function-local variable that is used for a global variable, without 
destroying that global variable.  [...]
Not entirely. The equivallent is imposible in function scope.
If function scope would work exactly equivallent as the
above the following should work 

a = 42
def f():
  a = a + 1
  print a
print a
And the result should be:
43
42
I'd still say that the name binding rules are very consistent.  The 
name lookup rules are a little different (as they *should* be for 
class/instance attributes), and that's why there's a different net 
effect (UnboundLocalError) as shown in your example.  I'd say, 
however, that if there's a special case here it's with the 
function-local variables, not the class/instance attributes.  It's the 
optimizations to the function-local namespace which prevent 
transparent re-binding of global names.  And given that the 
function-local namespace is by far the most heavily used, and the 
relative utility (and wisdom) of using globals in this way, this is a 
case where the benefit of the special case is well worth the cost of 
its slight inconsistency.

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

Re: Python becoming less Lisp-like

[Antoon Pardon]

Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Bruno Desthuilliers wrote:
>
>> A few examples:
> [...]
>> - to get the length of a sequence, you use len(seq) instead of seq.len()
>> - to call objects attributes by name, you use [get|set]attr(obj, name 
>> [,value]) instead of obj.[get|set]attr(name [,value])
>
> These are both very consistent applications of a more functional style 
> of programming, rather than the pure object-oriented style you seem to 
> desire.  It's not that Python is inconsistent; it's that Python is 
> consistently blending multiple paradigms in a way that uses the best 
> features of each and (mostly) avoids the worst pitfalls of each.
>
>> - if x is a class attribute of class A and a is an instance of A, 
>> a.x=anyvalue create a new instance attribute x instead of modifying A.x
>
> This is very consistent with the way that binding a name in any scope 
> will shadow any bindings of that name in "higher" scopes.  It is the 
> same principle by which one is able to use the same name for a 
> function-local variable that is used for a global variable, without 
> destroying that global variable.  Doing as you suggest would be far 
> *less* consistent, and would create a special case for class/instance 
> lookups where there is none now.
>

Not entirely. The equivallent is imposible in function scope.
If function scope would work exactly equivallent as the
above the following should work 

a = 42
def f():
  a = a + 1
  print a
print a

And the result should be:

43
42

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

Re: Python becoming less Lisp-like

[Kay Schluehr]

Paul Boddie wrote:

> The principal advantage of the property function was to permit the
> definition of "active" attributes without having a huge
> "if...elif...else" statement in the __getattr__ method. So the
> motivation was seemingly to externalize the usually simple logic in
> __getattr__ so that one could know a bit more about the supported
> properties of an object without having to read the source code.
>
> Java should be able to support Python-style properties by converting
> property accesses to accessor method calls before runtime, but with
> this capability within easy reach (and in all irony), the creators of
> the language instead decided to force programmers to explicitly call
> these rigidly-named methods, despite the raw property names actually
> being exposed to external tools like property editors, JavaServer
> Pages, and so on.

The accessor() was dedicated to someone in another newsgroup who came
from Java to Python and was annoyed by the _get, _set clutter which
reminds him to Java. He replaced property() alltogether by an own
construct. I wanted to convince him ( and also myself! ) that
property() can be customized for creating  accessors with very few
syntax.

>
> [accessor code cut]
>
> > class X(object):
> > a = accessor("a")
> > b = accessor("b", types = (tuple,list))
> > c = accessor("c", check = lambda x:hasattr(x,"__len__"))
>
> Hmmm, lambda!

Hi,Hi :)

This would not be much more code is even generic:

def are_attrs_present(*attrs):
def check_for_attrs(x):
return not False in [hasattr(x,attr) for attr in attrs]
return check_for_attrs

class X(object):
 a = accessor("a")
 b = accessor("b", types = (tuple,list))
 c = accessor("c", check = are_attrs_present("__len__","__add__"))

>>> x = X()
>>> x.c = 0  # raise TypeError ...
>>> x.c = "ok"   # ok

> This is a nice example, but I do wonder why so many examples of
> Python's dynamicity, especially with many of the newer features, seek
> to provide static type checking or some other variant on that theme.
> It would be nice to see more work done at the level of the compiler
to
> achieve those kinds of goals.

The motto "changing everything any time" demands a complete flow
analysis if one wants to make the compiler doing the typechecks. Even
the PyPy team has struggling with type inference ( "annotation" ) for a
long time and has not yet finished. So everyone is adding an ad-hoc
typechecker which means that there is really a need and Guido is right
in proposing some "type guards" allthough this hurts again a lot of
souls as we can observe in this thread too. His current suggestions are
either too restricted for each of the peoples requirements (
isinstance-typechecking, duck-typechecking, adaption ) or it is overly
permissive and is in danger to mean everything and nothing. Not to
speak about performance gains doing typechecks at runtime :-(

Regards Kay

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

REPOST: Re: Python becoming less Lisp-like

[Ville Vainio]

> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> writes:

>>> There would be keywords for static and class methods, no
>>> distinction between Unicode and non-Unicode

>> You couldn't do that 15 years ago because there were no Unicode
>> that time.

Torsten> I've never said that Guido was just too stupid at that
Torsten> time.  I only said "but you can definitely see that it's
Torsten> the oldest one".  In other words, a Ruby six years older
Torsten> than the real one would have the same problem.  And who
Torsten> knows how C# looks like in 10 years.

http://c2.com/cgi/wiki?PythonVsRuby

seems to suggest that Python has better Unicode support than Ruby.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

REPOST: Re: Python becoming less Lisp-like

[Ville Vainio]

> "Tim" == Tim Daneliuk <[EMAIL PROTECTED]> writes:

Tim> Except that in this case, removal will also complicate code
Tim> in some cases.  Consider this fragment of Tkinter logic:

Tim> UI.CmdBtn.menu.add_command(label="MyLabel",
Tim> command=lambda cmd=cmdkey: CommandMenuSelection(cmd))

Tim> Would it not be the case that, without lambda, we will need
Tim> to pollute the name space with a bunch of specialized little
Tim> functions for each and every construct like this?

You can reuse the same name for all those little functions to avoid
polluting the namespace. Choose 'L' if it gives you that cozy
lambda-ish feel.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Thomas Bellman]

Jeff Shannon <[EMAIL PROTECTED]> wrote:

> Because they may get stuck maintaining code that uses those features. 
>   Now, I'm generally in agreement with you -- in general, Python 
> features that aren't straightforward (e.g. metaclasses) are clearly 
> advanced features and aren't likely to be in everyday code.  I'm okay 
> with just knowing that metaclasses exist, and having a vague idea of 
> how one would use them.

> But the more features that some people ignore, the more that they tend 
> to write in a customized dialect that's a subset of the full language. 
>   And the more people write code in their own personal (or group) 
> dialect, the more fragmented the worldwide codebase becomes, and the 
> harder it is to understand code that doesn't come from the circle of 
> developers who you're directly familiar with.

In any non-trivial program, there will be a "small language",
consisting of functions, classes and data structures, that one
need to learn and understand in order to maintain the program.

If the implementation language (C, C++, Python, Ada, Pike, ...)
is small with few features, that set of functions et.c will be
larger, and you must thus take time to learn that instead.  And
that knowledge will *certainly* not help you with the next
program you have to maintain; learning of (say) metaclasses on
the other hand may very well do help you understand the next
program.

One may also note that features in the programming language are
likely to be better documented than the "small language" internal
to a large program, and thus easier to learn.

> It's true that a given programmer doesn't need to understand every 
> feature of the language, but it's not really fair to say "ignore it 
> and it won't affect you" -- there's still a cost associated with such 
> features that can't be ignored away.

There is a "local" cost with it, for learning Python, but I'm not
sure there really is a "global" cost, when you look at the entire
situation.


-- 
Thomas Bellman,   Lysator Computer Club,   Linköping University,  Sweden
"Too much of a good thing is WONDERFUL." !  bellman @ lysator.liu.se
 -- Mae West !  Make Love -- Nicht Wahr!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Antoon Pardon]

Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> news.sydney.pipenetworks.com wrote:
>
>> More in relation to the original topic, why can't people just ignore 
>> features they don't understand and may never use directly. 
>
> Because they may get stuck maintaining code that uses those features. 

So? You may get stuck maintaining code in an other language.
Are you going to complain about the existence of different
languages too?

>   Now, I'm generally in agreement with you -- in general, Python 
> features that aren't straightforward (e.g. metaclasses) are clearly 
> advanced features and aren't likely to be in everyday code.  I'm okay 
> with just knowing that metaclasses exist, and having a vague idea of 
> how one would use them.
>
> But the more features that some people ignore, the more that they tend 
> to write in a customized dialect that's a subset of the full language. 
>   And the more people write code in their own personal (or group) 
> dialect, the more fragmented the worldwide codebase becomes, and the 
> harder it is to understand code that doesn't come from the circle of 
> developers who you're directly familiar with.

Well that will be a judgement call for all those people, just as
life is mostly acting on judgement call.

> It's true that a given programmer doesn't need to understand every 
> feature of the language, but it's not really fair to say "ignore it 
> and it won't affect you" -- there's still a cost associated with such 
> features that can't be ignored away.  In some cases that cost is well 
> worth bearing (as is the case for metaclasses and descriptors, 
> especially as these two examples are implementation artifacts that 
> would exist whether they were exposed to programmers or not), but in 
> other cases it won't be, so it's important to keep in mind that the 
> cost exists.

Well if in some cases the costs are worth bearing, don't bear them.
Move on and look out for an other language. Newbees often enough
get the advise that with the mindset they currently have, python
is not the language they are looking for and they would be happier
programming in an other language. Well maybe that can happen to
experienced programmers too. Maybe the language will evolve so
it no longer fits there mindset. Well too bad, such things happen.

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

Re: Python becoming less Lisp-like

[Peter Maas]

Kay Schluehr schrieb:
Some people refused properties in Python for exactly this reason.
Defining somewhat like:
def _get_X(self):
return self._X
def _set_X(self,X):
self._X = X
X = property(_get_X, _set_X )
in a Java-style fashion is indeed awfull and clumsy and that people
dismiss such boilerplate code is understandable.
This is original Delphi-Style, btw. But why is this boilerplate code?
You define a property, and tell how it is read and written. How does
your preferred code look like?
--
---
Peter Maas,  M+R Infosysteme,  D-52070 Aachen,  Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Paul Boddie]

"Kay Schluehr" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> 
> Some people refused properties in Python for exactly this reason.
> Defining somewhat like:
> 
> def _get_X(self):
> return self._X
> 
> def _set_X(self,X):
> self._X =3D X
> 
> X =3D property(_get_X, _set_X )
> 
> in a Java-style fashion is indeed awfull and clumsy and that people
> dismiss such boilerplate code is understandable.

The principal advantage of the property function was to permit the
definition of "active" attributes without having a huge
"if...elif...else" statement in the __getattr__ method. So the
motivation was seemingly to externalize the usually simple logic in
__getattr__ so that one could know a bit more about the supported
properties of an object without having to read the source code.

Java should be able to support Python-style properties by converting
property accesses to accessor method calls before runtime, but with
this capability within easy reach (and in all irony), the creators of
the language instead decided to force programmers to explicitly call
these rigidly-named methods, despite the raw property names actually
being exposed to external tools like property editors, JavaServer
Pages, and so on.

[accessor code cut]

> class X(object):
> a = accessor("a")
> b = accessor("b", types = (tuple,list))
> c = accessor("c", check = lambda x:hasattr(x,"__len__"))

Hmmm, lambda!

> a,b,c are indeed properties of X !
> 
> >>> x = X()
> >>> x.b = [1,2,3] # o.k
> >>> x.b
> [1, 2, 3]
> >>> x.b = 0  # raises a TypeError, because a tuple/list is expected

This is a nice example, but I do wonder why so many examples of
Python's dynamicity, especially with many of the newer features, seek
to provide static type checking or some other variant on that theme.
It would be nice to see more work done at the level of the compiler to
achieve those kinds of goals.

  BRIDGEKEEPER:
Stop!
Who would cross the Bridge of Death must answer me these
questions three, ere the other side he see.
  THE PYTHONIC KNIGHT:
Ask me the questions, bridgekeeper. I am not afraid.
  BRIDGEKEEPER:
What... is your name?
  THE PYTHONIC KNIGHT:
My name is 'The Pythonic Knight'.
  BRIDGEKEEPER:
What... is your quest?
  THE PYTHONIC KNIGHT:
To seek the Holy Grail.
  BRIDGEKEEPER:
What... are decorators for?
  THE PYTHONIC KNIGHT:
Static type checking. No, param-- agh!

Or something [1] like that.

Paul

[1] http://www.mwscomp.com/movies/grail/grail-23.htm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Paul Boddie]

Mike Meyer <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> 
> The real problem is that newbies won't know which features are "meta"
> features best left to experts, and which features are ok for everyday
> programmers to use.

I think the original contributor to this thread was fairly accurate
when he described some of the confusion that newcomers to Python have
upon encountering Python's "transititonal" situation. I recall seeing
a thread fairly recently where someone wanted to know if they should
be using new-style classes or not, and whilst new-style classes do
introduce some desirable behaviour, being told to inherit from object
and then seeing lots of older code which doesn't do so raises a
certain amount of uncertainty on the part of the newcomer.

Everyone likes to criticise Java for additional notation which seems
like distracting boilerplate that obstructs the learning process (eg.
"public static void main"), but it would be worse if such notation
were optional and if programs still had a main function/method by some
other now-unfashionable means. Some of that uncertainty (albeit at
less visible levels) does now exist in Python, raising the issue of
coding "best practices" that I never thought would arise with the
language.

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

Re: Python becoming less Lisp-like

[Ville Vainio]

> "Mike" == Mike Meyer <[EMAIL PROTECTED]> writes:

Mike> The real problem is that newbies won't know which features
Mike> are "meta" features best left to experts, and which features
Mike> are ok for everyday programmers to use.

I suppose that a typical lazy newbie will just skip metaclasses and
descriptors on the grounds of not understanding them immediately. It's
the 'quest of guruhood' phase when novices start browsing wikis and
obscure python-dev discussions to find out how these things work. All
the documentation I've seen regarding these features mentions that the
user probably doesn't need to know about them; this is especially true
for metaclasses.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[news.sydney.pipenetworks.com]

Jeff Shannon wrote:
news.sydney.pipenetworks.com wrote:
More in relation to the original topic, why can't people just ignore 
features they don't understand and may never use directly. 

Because they may get stuck maintaining code that uses those features. 
 Now, I'm generally in agreement with you -- in general, Python features 
that aren't straightforward (e.g. metaclasses) are clearly advanced 
features and aren't likely to be in everyday code.  I'm okay with just 
knowing that metaclasses exist, and having a vague idea of how one would 
use them.

But the more features that some people ignore, the more that they tend 
to write in a customized dialect that's a subset of the full language. 
 And the more people write code in their own personal (or group) 
dialect, the more fragmented the worldwide codebase becomes, and the 
harder it is to understand code that doesn't come from the circle of 
developers who you're directly familiar with.
I don't totally understand what you're getting at here, but here's my 
take. If people can implement something which can be done using 
metaclasses without using metaclasses then I don't see a problem with 
this. However if someone implements something using metaclasses which 
can be done via other simpler means, then this is a just a education 
problem. It's like the procedural vs functional vs oo programming 
argument all over again. Some people will use OO for everything when it 
may not be best. etc. etc.

It's true that a given programmer doesn't need to understand every 
feature of the language, but it's not really fair to say "ignore it and 
it won't affect you" -- there's still a cost associated with such 
features that can't be ignored away.  In some cases that cost is well 
worth bearing (as is the case for metaclasses and descriptors, 
especially as these two examples are implementation artifacts that would 
exist whether they were exposed to programmers or not), but in other 
cases it won't be, so it's important to keep in mind that the cost exists.
Of course theres a cost with every feature. But with time that costs 
approaches zero if it becomes as rampant as is being suggested because 
you will get use to it. If you see it once every blue moon, well then 
you'll just have to have one very bad day at work.

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

Re: Python becoming less Lisp-like

[Jeremy Bowers]

On Wed, 16 Mar 2005 16:35:57 -0600, Mike Meyer wrote:
> The real problem is that newbies won't know which features are "meta"
> features best left to experts, and which features are ok for everyday
> programmers to use.
> 
> We recently saw a thread (couldn't find it in google groups) where
> some was trying to write decorators that would add a variable to a
> functions local namespace. When they actually stated the problem, it
> was a problem trivially solved by inheriting behavior, and that OO
> solution was what the OP finally adopted. But most of a week got
> wasted chasing a "solution" that should never have been investigated
> in the first place.

This isn't a new problem, and I'm not convinced it even makes it worse.
We (speaking broadly) have had to ask "No, what is it you are trying to
*do*?" for a long time. Whether the 'newbie' is reaching for decorators to
add a variable, trying to use lambdas to print, or trying to use XML-RPC
to make calls to local functions, the newbie who is going to ask "How do I
do this wrong thing?" isn't going to be affected either way by the
addition or removal of metaclasses, or much of anything else.

Is this arguable? Yes, absolutely, and I think none of us have the data
to prove this one way or the other. But a priori it is not obvious that
adding a few more possible mistakes to the already effectively infinite
set of them is necessary going to trap anybody who wasn't going to get
trapped on something else.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Mike Meyer]

[EMAIL PROTECTED] (Paul Boddie) writes:

> Steven Bethard <[EMAIL PROTECTED]> wrote in message news:<[EMAIL 
> PROTECTED]>...
>> 
>> Certainly descriptors in the "wrong hands" could lead to confusing, 
>> unreadable code.  But Python is a "we're all adults here" language, and 
>> so we have to trust other coders to be responsible.
>
> The problem is as much about social dynamics as it is about
> responsibility. Introduce a cool new feature and there'll always be a
> minority who will use it in every situation, no matter how absurd; the
> problem arises when these unnecessary excursions into absurdity start
> to dominate the code you're using or maintaining.

The real problem is that newbies won't know which features are "meta"
features best left to experts, and which features are ok for everyday
programmers to use.

We recently saw a thread (couldn't find it in google groups) where
some was trying to write decorators that would add a variable to a
functions local namespace. When they actually stated the problem, it
was a problem trivially solved by inheriting behavior, and that OO
solution was what the OP finally adopted. But most of a week got
wasted chasing a "solution" that should never have been investigated
in the first place.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Jeff Shannon]

news.sydney.pipenetworks.com wrote:
More in relation to the original topic, why can't people just ignore 
features they don't understand and may never use directly. 
Because they may get stuck maintaining code that uses those features. 
 Now, I'm generally in agreement with you -- in general, Python 
features that aren't straightforward (e.g. metaclasses) are clearly 
advanced features and aren't likely to be in everyday code.  I'm okay 
with just knowing that metaclasses exist, and having a vague idea of 
how one would use them.

But the more features that some people ignore, the more that they tend 
to write in a customized dialect that's a subset of the full language. 
 And the more people write code in their own personal (or group) 
dialect, the more fragmented the worldwide codebase becomes, and the 
harder it is to understand code that doesn't come from the circle of 
developers who you're directly familiar with.

It's true that a given programmer doesn't need to understand every 
feature of the language, but it's not really fair to say "ignore it 
and it won't affect you" -- there's still a cost associated with such 
features that can't be ignored away.  In some cases that cost is well 
worth bearing (as is the case for metaclasses and descriptors, 
especially as these two examples are implementation artifacts that 
would exist whether they were exposed to programmers or not), but in 
other cases it won't be, so it's important to keep in mind that the 
cost exists.

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

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

[Brandon J. Van Every]

Carl Shapiro wrote:
> "Brandon J. Van Every" <[EMAIL PROTECTED]>
> writes:
>
>> Last I looked, 2 years ago?, there were no compiled, open source
>> lisps that ran on Windows.  Has this changed?
>
> I have a virtually completed port of CMUCL to Win32.  [etc]

Ah, so you're the brave lad I heard about.  :-)  Well, good going!  Hope to
see it sometime.

-- 
Cheers, www.indiegamedesign.com
Brandon Van Every   Seattle, WA

When no one else sells courage, supply and demand take hold.

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

Re: Python becoming less Lisp-like

[Kay Schluehr]

Torsten Bronger wrote:
> Hallöchen!

Moin!

> [First, I wanted to say "descriptors" instead of "decorators" (I
> superseded my post).]
>
> The goal is to trigger function calls when attributes are accessed.
> This is called properties in C# (and maybe in Ruby, too).  Python
> now also has this concept.  What I find ugly is that it is not a
> syntax element.  It looks artificially added to the language.  In
> C#, the "set" and "get" methods form with its attribute a syntactic
> unity.  Everything is together, and no "property" function is
> necessary.

Some people refused properties in Python for exactly this reason.
Defining somewhat like:

def _get_X(self):
return self._X

def _set_X(self,X):
self._X = X

X = property(_get_X, _set_X )

in a Java-style fashion is indeed awfull and clumsy and that people
dismiss such boilerplate code is understandable.

But "Thinking in Java" in Python is probably no good idea allthough
this style can be found in Guidos property-examples presented in his
famous introduction on new-style classes as well:

http://www.python.org/2.2/descrintro.html

I thought for a long time that C# solved this problem with a superior
accurate and compact notion, but paying more attention to the
property() function itself and not to the declarative style getters and
setters opened me a more generic road to reason about desciptors:

def accessor(name, check=None, types=[]):
'''
Generic property creator.
'''
name  = "__"+name
def get(obj):
if not hasattr(obj,name):
setattr(obj,name, None)
return getattr(obj,name)

def set(obj,value):
if types:
if not True in [isinstance(value,t) for t in types]:
raise TypeError, "Can't assign %s to property
%s."%(value,name[2:])
if check:
if not check(value):
   raise TypeError, "Can't assign %s to property
%s."%(value,name[2:])
else:
setattr(obj,name,value)
return property(get,set,None)



Now an example:


class X(object):
a = accessor("a")
b = accessor("b", types = (tuple,list))
c = accessor("c", check = lambda x:hasattr(x,"__len__"))

a,b,c are indeed properties of X !

>>> x = X()
>>> x.b = [1,2,3] # o.k
>>> x.b
[1, 2, 3]
>>> x.b = 0  # raises a TypeError, because a tuple/list is expected
.
.


Regards Kay

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

[OT] Re: Python becoming less Lisp-like

[Brian van den Broek]

news.sydney.pipenetworks.com said unto the world upon 2005-03-16 05:57:

trust the guy to do a good job. If you don't, then you can write it 
yourself which means you can do exactly how you want it which again 
makes the whole argument mute.
Anyone else having images of mimes engaged in street fights? ;-)
Best,
Brian vdB
--
http://mail.python.org/mailman/listinfo/python-list

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

[Carl Shapiro]

"Brandon J. Van Every" <[EMAIL PROTECTED]> writes:

> Last I looked, 2 years ago?, there were no compiled, open source lisps that
> ran on Windows.  Has this changed?

I have a virtually completed port of CMUCL to Win32.  And, if I was
not busy organizing a Lisp conference, it would be publicly available
by now.  An observation: most of the open-source Lisp implementations
make egregious assumptions about the underlying operating system, most
of which are just barely valid, even on UNIX.  (Perhaps this is an
observation about UNIX software in general.)  A lot of this had to be
untangled in order to make CMUCL usable.  More work remains to be
done.

When playing the role of a Windows developer, I have never been
satisfied with the level of integration that language run-times with a
UNIX heritage has to the Win32 API.  Such things as file system
interaction, I/O completion ports, thread pools, componentized
software, synchronization primitives and the like never quite work
correctly, especially when there is a run-time library which sits
above the C library.  You will find an amazing amount of shennanigans
in Lisp run-time libraries (commercial and open-source) as well as
those belonging to the various strongly-typed functional languages,
and scripting languages.  These systems would appear to have been
written with the assumption that they would be the "harness" of an
application, and that UNIX compatibility was an overriding concern;
fatal flaws for Win32 development.

I have never been a game developer, but I have worked on real-time
systems--written in Lisp.  I would guess that programmers in both
these domains have similar concerns.  You can write continuous systems
in Lisp, but it requires a fair amount of wizardry.  (This is
basically true of most garbage collected systems.)  Real-time
collectors help but often sap performance and introduce constraints of
their own.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[news.sydney.pipenetworks.com]

Torsten Bronger wrote:
HallÃchen!
"news.sydney.pipenetworks.com" <[EMAIL PROTECTED]> writes:

Torsten Bronger wrote:

[...]
I have exactly the same impression, but for me it's the reason
why I feel uncomfortable with them.  For example, I fear that a
skilled package writer could create a module with surprising
behaviour by using the magic of these constructs.  I don't know
Python well enough to get more specific, but flexibility almost
always make confusing situations for non-hackers possible.
In that case I wouldn't worry about the magic which can be done in
python but the magic which can be done in C (which many modules
are written in).

The magic in Python must allow the magic in C.
You have answered your own question.
Sometimes I think people complain just to complain.

It's interesting though that the concerns I mentioned have
influenced so many language designs, isn't it?
Look, you may weight the pros and cons differently from me, that's
perfectly okay.  But don't tell me my thoughts were invalid.
I agree. It was an uncalled for statement and I apologise. I guess 
theres got to be critics for the language to become better.

I just think certain arguments are a bit thin. Especially all the talk 
about the decorator syntax. I have never seen so much discussion over 
such a small detail. It's not as if the BDFL is going to start 
introducing all types of special chars in the language. From the way 
people carry on, it shall as heck sounds like it.

More in relation to the original topic, why can't people just ignore 
features they don't understand and may never use directly. Tell me you 
understand exactly how every single module you have ever used works 
whether or not its written in pure simple python or python with hacky 
features. Regardless of how a piece of software is written, as long as 
it works, has a good test bed, has a smart programmer behind, then lets 
trust the guy to do a good job. If you don't, then you can write it 
yourself which means you can do exactly how you want it which again 
makes the whole argument mute.

You can't take a ride on someones sweat and blood and expect them to 
control how they program as well can you ? If you're paying them, then 
make sure they don't use any special features.

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

Re: Python becoming less Lisp-like

[Torsten Bronger]

HallÃchen!

"news.sydney.pipenetworks.com" <[EMAIL PROTECTED]> writes:

> Torsten Bronger wrote:
>
>> [...]
>>
>> I have exactly the same impression, but for me it's the reason
>> why I feel uncomfortable with them.  For example, I fear that a
>> skilled package writer could create a module with surprising
>> behaviour by using the magic of these constructs.  I don't know
>> Python well enough to get more specific, but flexibility almost
>> always make confusing situations for non-hackers possible.
>
> In that case I wouldn't worry about the magic which can be done in
> python but the magic which can be done in C (which many modules
> are written in).

The magic in Python must allow the magic in C.

> Sometimes I think people complain just to complain.

It's interesting though that the concerns I mentioned have
influenced so many language designs, isn't it?

Look, you may weight the pros and cons differently from me, that's
perfectly okay.  But don't tell me my thoughts were invalid.

TschÃ,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Paul Boddie]

Steven Bethard <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> 
> Certainly descriptors in the "wrong hands" could lead to confusing, 
> unreadable code.  But Python is a "we're all adults here" language, and 
> so we have to trust other coders to be responsible.

The problem is as much about social dynamics as it is about
responsibility. Introduce a cool new feature and there'll always be a
minority who will use it in every situation, no matter how absurd; the
problem arises when these unnecessary excursions into absurdity start
to dominate the code you're using or maintaining.

>  There are some very 
> reasonable uses for descriptors which I don't believe are really 
> confusing, for example the lazy property recipe:
> 
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/363602

This is all very exciting, but...

  * You could do this with __getattr__ since Python 1.x, possibly
even Python 0.x. Moreover, the __getattr__ example would be
more readable.

  * This introduces runtime baggage to solve a notation issue. Yes,
accessor methods are "so Java", but once a program is running
who cares whether it's a property or a method that is getting
called? (Actually, for interactive inspection of an object
model there is some argument for having properties...)

I think the first point quite reasonably illustrates the original
contributor's concerns about Python's current consistency/coherency.

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

Re: Python becoming less Lisp-like

[Peter Maas]

Fernando schrieb:
The real problem with Python is that it has been very successful as a
scripting language in the static-typing/C/C++ world. Those
programmers, instead of adapting their evil ways to Python, and
realizing the advantages of a dynamic language, are influencing
Python's design and forcing it into the static-typing mold.
Examples?
Python is going the C++ way: piling feature upon feature, adding bells
and whistles while ignoring or damaging its core design.
What is core design? What are bells and whistles? I find it surprising
that you talk about adding bells and whistles, whereas the URL you are
referring to is about removing features.
The new 'perlified' syntax for decorators, the new static type bonds
and the weird decision to kill lambda instead of fixing it are good
examples that show that Python is going the wrong way.
I don't think that the introduction of '@' for decorators justifies
the term perlification. If special characters are avoided at all costs
Python could become too verbose like Java which is often critized for
that in c.l.py.
What used to be a cool language will soon be an interpreted C/C++
without any redeeming value. A real pity...
What do you mean with cool? Which parts of Python are C/C++ish? Which
features leave Python "without any redeeming value"? This phrase
is close to trolling because is vague, emotional and unspecific.
The fear of the anti-static fanatics is unfounded. Guido has made
clear that he is thinking of a  pychecker-like mechanism for
validating programs at compile time. There's nothing wrong with
defining interfaces and conditions and being able to check them
before actually running the program.
--
---
Peter Maas,  M+R Infosysteme,  D-52070 Aachen,  Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Jeremy Bowers]

On Tue, 15 Mar 2005 03:21:48 -0800, Paul Boddie wrote:
> Well, I've been using Python for almost ten years, and I've managed to
> deliberately ignore descriptors and metaclasses quite successfully. I get
> the impression that descriptors in particular are a detail of the
> low-level implementation that get a disproportionate level of coverage
> because of the "hack value" they can provide (albeit with seemingly
> inappropriate application to certain problem areas).

I kept playing with descriptors, and tearing them out of production code,
but I finally figured out how to "think" of them, I think. 

You want to create a descriptor for a type of "property()" that you keep
using over and over again. If it's a one-off, use a property and be done
with it. If you find yourself writing the same property over and over
again, having access to the descriptor itself lets you factor it out so
you can write it Once and Only Once (IMHO the highest of all programming
laws^H^H^H^H^H rules of thumb).

I went a long time before I came up with a use case for that, but now I
have one where I want an attribute to fire an event in a particular manner
every time it is changed. Rather than write a read function and a write
function for each attribute (or try to hack it with closures or other
arcane enchantments), it was easy to pack it up as a descriptor. It's a
little too large to just copy and paste, but the upshot is that I can use
it just like this:

class Whatever(object):
name = EmitOnChange("nameChange", "_name")

and that will fire a "nameChange" event into my event system every time
someone modifies "name", and the "real" value is stored in _name.
(Obviously, I use it more than this once in the real code.)

This may not be the best way to look at it from the C point of view, but I
think it's a good way to look at it from the Python point of view. It
probably is pretty rare that you need this, but it's there.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Mike C. Fletcher]

Thomas Bellman wrote:
Torsten Bronger <[EMAIL PROTECTED]> wrote:
 

Just to amplify Thomas' statements...
...
And inflexibility will always make some situations horribly
daunting to get out of.
Powerful constructs like these can, in some cases, enable a
skilled package writer to design an API that reduces the amount
of boiler plate code needed for using the package.
 

...
The following is from the (draft of) my paper for my pycon presentation 
(upcoming).

We see similar patterns throughout the class-type redesign, the 
introduction of the __new__ method which allowed for “hooking” the 
creation (as distinct from initialization) of an object, the 
__getattribute__ method for hooking all attribute access. In each 
case, the operations were previously “part of the interpreter” and 
unavailable for customization by the Python programmer, the protocols 
generalized the behavior, making objects themselves responsible for 
what was previously implemented by the interpreter, and thus was 
always exactly the same.

That sameness was arguably a strong advantage for Python in the early 
days of its life-cycle. When you were handed an object (particularly, 
any object defined by a class), it had simple, predictable behavior. 
The (one) class implementation was straightforward enough that most 
new users didn't particularly get lost in it. Of course, the flip side 
was the presence of “types”, which could behave very differently, and 
the need for people who wanted to customize the core behavior of an 
object (for instance to change how attribute traversal was handled) to 
write C extensions. And then there was the strange exception for 
attribute access for functions, but that was so natural and practical 
it seldom bit anyone who wasn't doing meta-programming.

Effectively, there were a few bits of “magic” that the Python 
programmer needed to understand, but the variety and complexity of the 
magical patterns was limited. The magic incantations could be learned 
readily by the acolyte, but there was a hard cap on what could be done 
without becoming a “wizard” and programming in C. The limits on 
functionality made Python a smaller and less complex language, but it 
also tended to frustrate the “wizards”, who, after all, might know C, 
but would rather either program in Python (or spend more of their time 
looking at really deep C, rather than creating yet another 
customization to support something just beyond the reach of the acolytes).

So, with Python 2.2, the wizards of Python made it possible to 
override and customize the behavior of objects in ways that were 
previously impossible. They brought things that were previously 
“magic” (for example, the order of attribute lookup that somehow 
created bound instance methods) into the realm of the understandable 
by rationalizing the process.

metaclasses and descriptors are primarily of interest to 
metaprogrammers, people whose target audience is other programmers. Most 
programmers can get along perfectly fine ignoring them save for knowing 
what the particular ones they *use* do. Metaprogramming is not 
*necessarily* a *dark* art, but it can certainly lead the way to 
darkness if done improperly or wantonly. When done properly, you can 
build systems that seem to perfectly map a problem domain into the 
familiar embrace of everyday Python with just the right "lived in" 
touches to make it seem as though the language was designed from the 
start to support that domain [leaving aside any questions of syntactic 
variants, which is its own involved debate].

When you have metaprogramming to do, it is *such* a relief when you can 
get it done in Python without resorting to C.

Have fun all,
Mike

 Mike C. Fletcher
 Designer, VR Plumber, Coder
 http://www.vrplumber.com
 http://blog.vrplumber.com
 PyCon is coming...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[news.sydney.pipenetworks.com]

Torsten Bronger wrote:
HallÃchen!
[EMAIL PROTECTED] (Paul Boddie) writes:

Torsten Bronger <[EMAIL PROTECTED]> wrote:

At first, I was very pleased by Python's syntax (and still I am).
Then, after two weeks, I learned about descriptors and
metaclasses and such and understood nothing (for the first time
in syntax I felt totally lost).
Well, I've been using Python for almost ten years, and I've
managed to deliberately ignore descriptors and metaclasses quite
successfully. I get the impression that descriptors in particular
are a detail of the low-level implementation that get a
disproportionate level of coverage because of the "hack value"
they can provide (albeit with seemingly inappropriate application
to certain problem areas).

I have exactly the same impression, but for me it's the reason why I
feel uncomfortable with them.  For example, I fear that a skilled
package writer could create a module with surprising behaviour by
using the magic of these constructs.  I don't know Python well
enough to get more specific, but flexibility almost always make
confusing situations for non-hackers possible.
In that case I wouldn't worry about the magic which can be done in 
python but the magic which can be done in C (which many modules are 
written in). Sometimes I think people complain just to complain.

I know that such magic is inavoidable with dynamic languages, but
There's always a but.
descriptors will be used almost exclusively for properties, and
therefore I think it would have been better to hard-wire properties
in the interpreter rather than pollute the language with this sort
of proto-properties (aka descriptors).
Have you heard of java ? maybe you'll like groovy.
TeX is extremely dynamic.  It can modify its own scanner in order to
become an XML parser or AFM (Adobe font metrics) reader.  This is
highly confusing for all but those five or six people on this planet
who speak TeX fluently.  Since I saw raw TeX, I dislike
"proto-syntaxes" (or meta-syntaxes if you wish).
Now you're talking about extremes
Huy
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[news.sydney.pipenetworks.com]

Bruno Desthuilliers wrote:
Valentino Volonghi aka Dialtone a écrit :
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
It is actually. Ruby's syntax is mostly consistent and coherent, and 
there is much less special cases than in Python.
 
I'd be glad to know which special cases are you referring to.

A few examples:
- A statement is different from an expression (2 special cases instead 
of one general case).
You do know that Ruby may well get this special case as well. At least 
they know a good thing when they see it. I'm not sure why this is a 
problem in any case.

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

Re: Python becoming less Lisp-like

[news.sydney.pipenetworks.com]

Bruno Desthuilliers wrote:
news.sydney.pipenetworks.com a Ãcrit :

I looked for a new language for my hobby programming.  I used to use
Turbo Pascal for 10 years and then C++ for 6 years.  A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python.  At the
moment, I want to go with Python, but you can definitely see that
it's the oldest one: Many parts of its syntax are awkward and look
like patchwork.

You mean you think Ruby syntax is less awkward then Python ?

It is actually. Ruby's syntax is mostly consistent and coherent, and 
there is much less special cases than in Python.
Really, well I must be wrong. Each to his own opinion then.
Now it's also much more difficult to grasp Ruby for programmers coming 
from procedural languages, but that's another story.
So being more consistent and coherent means being more complex ? I'm 
glad python worried about the complex part before the consistent and 
conherent part.

Maybe you should add Perl to your list of languages to learn 
especially after your complaints about the decorator syntax.

I guess you stopped your exploration of Ruby at the first sign of 
'special chars' syntax.
well not really. I stopped when it started to look to much like perl. I 
hate too much punctuation in syntax. I quite like the @ in ruby better 
then the self in python though, but at the end of the day, i don't 
really care that much whether it's an @ or a self.

I don't like Perl, I still prefer to use Python (over Ruby) for a number 
of good and less good reasons, but I somewhat share Fernando's (and some 
other's people here) concerns about the future of MyFavoriteLanguage.
Fair enough. It seems many people want to trade places with the BDFL. I 
don't. May his god bless him ;-)

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

Re: Python becoming less Lisp-like

[Steven Bethard]

Kent Johnson wrote:
Steven Bethard wrote:
Bruno Desthuilliers wrote:
class CommandMenuSelectionCallback:
def __init__(self, key):
self.key = key
def __call__(self):
print self.key

Looks like Java.
When was the last time you used Java?  It has no support for using 
classes as callable objects.  __call__ would have to be invoked 
manually; you definitely couldn't have a CommandMenuSelectionCallback 
instance masquerading as a function as this code (basically) does.
It's like Java in that it uses a short helper class to define an event 
callback. In the case of Java it would be an anonymous inner class 
programming to an interface. It's like Java in that it uses five lines 
of code to do what Python can do in one.
Well the second is definitely true. ;)
Do you really prefer this verbosity to a lambda expression?
Depends on the situtation.  I do like that the signature of 
CommandMenuSelectionCallback is correct (that is, no arguments), where
lambda cmd=cmdkey: CommandMenuSelection(cmd)
has an optional argument when one is not asked for.

OTOH, in this particular case, the real problem is that the API has made 
a poor choice for callbacks.  The signature of 
UI.CmdBtn.menu.add_command should be
add_command(label, command, *args, **kwargs)
instead of
add_command(label, command)
Of course API's won't always do things the way you want them to, so I 
can see that in working around API deficiences, lambda can occasionally 
seem useful.

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

Re: Python becoming less Lisp-like

[Jeff Shannon]

Bruno Desthuilliers wrote:
A few examples:
[...]
- to get the length of a sequence, you use len(seq) instead of seq.len()
- to call objects attributes by name, you use [get|set]attr(obj, name 
[,value]) instead of obj.[get|set]attr(name [,value])
These are both very consistent applications of a more functional style 
of programming, rather than the pure object-oriented style you seem to 
desire.  It's not that Python is inconsistent; it's that Python is 
consistently blending multiple paradigms in a way that uses the best 
features of each and (mostly) avoids the worst pitfalls of each.

- if x is a class attribute of class A and a is an instance of A, 
a.x=anyvalue create a new instance attribute x instead of modifying A.x
This is very consistent with the way that binding a name in any scope 
will shadow any bindings of that name in "higher" scopes.  It is the 
same principle by which one is able to use the same name for a 
function-local variable that is used for a global variable, without 
destroying that global variable.  Doing as you suggest would be far 
*less* consistent, and would create a special case for class/instance 
lookups where there is none now.

- sequence methods that modify the sequence in place return None instead 
of returning self - ok, I know the rational for this one, but I still 
dont like it, and still count it as a special case since when using a 
'destructive' sequence method I can't chain it with non-destructive 
method calls.
This is not a special case.  It is a deliberate and consistent design 
decision, and it is implemented uniformly through the standard 
library.  Note that if your preference was the standard, one could 
*still* use the same logic to call it a special case -- that in some 
cases a method call returns a new object leaving the original 
unmodified, and in other cases it modifies the original object and 
returns a reference to it.  The current implementation has the 
advantage of being much less likely to lead to hard-to-detect bugs 
than your preference would.

Also, Python enforce some coding style (indentation) but not some others 
(capitalization for example). So you always have to check, on a lib by 
lib base, what style has been used (I personnaly don't give a damn 
whether I use underscore_all_lower or mixedCaps, but consistency is 
useful, even more when there's such a huge stdlib). Worst, the base 
class for new style classes is all lower ('object') when the usual 
convention is to use CamelCase for classes.
Um... does Lisp enforce capitalization?  No.  Does C? I didn't think 
so.  Keep in mind that Python uses indentation not as a coding style, 
but as an inherent part of the syntax in the same way that C uses {} 
(but that indentation is much easier for humans to keep straight).  Do 
you complain that C enforces brace-usage but not capitalization styles?

What you have here is a listing of things about Python that you don't 
like.  They are not actually special cases, except in the sense of 
"things that Bruno especially dislikes".  Now, you're welcome to 
dislike them if you want, but be aware that some of the things that 
you're looking at as weaknesses, others of us see as positive and 
beneficial things, and in many cases there's real evidence to support 
the contention that Python's design choices will decrease the 
frequency of bugs.

Perhaps Python *is* becoming less Lisp-like... but I've never been 
convinced that Lisp is the best of all possible programming languages, 
so maybe being less Lisp-like and more Python-like is a good thing.

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

Re: Python becoming less Lisp-like

[Kent Johnson]

Steven Bethard wrote:
Bruno Desthuilliers wrote:
class CommandMenuSelectionCallback:
def __init__(self, key):
self.key = key
def __call__(self):
print self.key
Looks like Java.

When was the last time you used Java?  It has no support for using 
classes as callable objects.  __call__ would have to be invoked 
manually; you definitely couldn't have a CommandMenuSelectionCallback 
instance masquerading as a function as this code (basically) does.
It's like Java in that it uses a short helper class to define an event callback. In the case of Java 
it would be an anonymous inner class programming to an interface. It's like Java in that it uses 
five lines of code to do what Python can do in one.

Do you really prefer this verbosity to a lambda expression? Yikes!
Kent
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Jeff Shannon]

Martin Franklin wrote:
Tim Daneliuk wrote:
Except that in this case, removal will also complicate code in some
cases.  Consider this fragment of Tkinter logic:
UI.CmdBtn.menu.add_command(label="MyLabel",
command=lambda cmd=cmdkey: 
CommandMenuSelection(cmd))

In this case you perhaps should try using a class like so:-
UI.CmdBtn.menu.add_command(label="MyLabel",
   command=CommandMenuSelectionCallback(cmdkey))
Where CommandMenuSelectionCallback is a class like so:
class CommandMenuSelectionCallback:
def __init__(self, key):
self.key = key
def __call__(self):
print self.key
One could equivalently define CommandMenuSelectionCallback as a 
function which creates and returns closures --

def CommandMenuSelectionCallback(key):
def func():
CommandMenuSelection(key)
return func
This should have the same practical value as the callable class; in 
both cases you have a callable taking a single argument, which 
produces a callable taking no arguments.  Whether one prefers that the 
resulting callable object be a class instance or a closure (function) 
seems to me to be largely a matter of taste.

Also, once Python 2.5 is realeased, one should be able to use the 
partial() function (see http://www.python.org/peps/pep-0309.html) to 
accomplish much the same thing in a more general fashion.  ISTM that 
partial() will cover somewhere between 50% and 95% of the current 
(reasonable) uses of lambda -- my guess being that it's towards the 
hight end of that range.

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

Re: Python becoming less Lisp-like

[Thomas Bellman]

Torsten Bronger <[EMAIL PROTECTED]> wrote:

> I have exactly the same impression, but for me it's the reason why I
> feel uncomfortable with them.  For example, I fear that a skilled
> package writer could create a module with surprising behaviour by
> using the magic of these constructs.

If the behaviour is surprising, then the package writer wasn't
very skilled...  A very large part of the skill needed to write a
module, is knowing how to design its interface so it becomes easy
to use, intuitive, and non-surprising.

> I don't know Python well
> enough to get more specific, but flexibility almost always make
> confusing situations for non-hackers possible.

On the other hand, *in*flexibility doesn't give any guarantee
against confusing situations.  At least not as long as there is
enough flexibility in the language to actually allow you to do
anything more advanced than "Hello World".

And inflexibility will always make some situations horribly
daunting to get out of.

Powerful constructs like these can, in some cases, enable a
skilled package writer to design an API that reduces the amount
of boiler plate code needed for using the package.

If some authors write bad books, do you blame the English
language for allowing them to write such books, or do you
blame the writers for using English in a bad way?


-- 
Thomas Bellman,   Lysator Computer Club,   Linköping University,  Sweden
"We don't understand the software, and! bellman @ lysator.liu.se
 sometimes  we don't understand the hardware, ! 
 but we can *see* the blinking lights!"   ! Make Love -- Nicht Wahr!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Steven Bethard]

Bruno Desthuilliers wrote:
class CommandMenuSelectionCallback:
def __init__(self, key):
self.key = key
def __call__(self):
print self.key

Looks like Java.
When was the last time you used Java?  It has no support for using 
classes as callable objects.  __call__ would have to be invoked 
manually; you definitely couldn't have a CommandMenuSelectionCallback 
instance masquerading as a function as this code (basically) does.

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

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

[David Golden]

James Graves wrote:

> 
> But coverage in this area (compiled CL) is a bit thin, I'll admit.
> 

But who really cares?  After all, there are the mature commercial
proprietary lisp compilers for those people who insist on using
closedware OSes, and they've already proven they're willing to use
closedware.

This, I fear, is similar to Brandon's demands for a microcrap
visual-studio compatible yet open source gaming framework. or silly
expectations of microsoft suite support for various open-source
language implementations (just google search on groups for his
name...): 

Might happen (has happened, to an extent), but where's the developer
motivation?   It's not like it's hard to install linux these days. 
Most open source developers would be indifferent at best to a windows
port, it's not like it's even a fun challenge like a port to an obscure
platform like AROS would be, you just end up with
creeping hungarian notation ugliness in your code, and lots of #defines.
Most people writing open source and for the fun of it just aren't going
to go massively out of the way to support windows, and even if they do,
they're just giving the slaves another excuse not to throw off their
chains.






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

Re: Python becoming less Lisp-like

[Valentino Volonghi aka Dialtone]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:

> A few examples:
> - A statement is different from an expression (2 special cases instead
> of one general case).

> - You can't use statements in a lambda

Good reason to remove lambda, let's do this asap.

> - to get the length of a sequence, you use len(seq) instead of seq.len()

I can see nothing wrong with this.
seq.__len__() 
works equally well.

> - to call objects attributes by name, you use [get|set]attr(obj, name
> [,value]) instead of obj.[get|set]attr(name [,value])

this is the same as above. And I can see nothing wrong with this. This
is not a special case but syntax sugar. If you feel more comfortable use
the following:

seq.__getattribute__('append')


> - if x is a class attribute of class A and a is an instance of A, 
> a.x=anyvalue create a new instance attribute x instead of modifying A.x

How is this a wart? Do you understand mutable and immutable objects?

In [7]: class A(object):
   ...: a = {}
   ...: b = 5 
   ...: 

In [8]: a = A()

In [9]: b = A()


# Modifying an immutable object yields a new object, thus a new binding
In [10]: a.b = 3

In [11]: b.b
Out[11]: 5

# Modyfing a mutable object doesn't change the original binding:
In [12]: a.a['a'] = 4

In [13]: b.a
Out[13]: {'a': 4}

It would be a wart if it was like you thought it should be because the
behaviour of objects changed depending on where they happend to be.

> - sequence methods that modify the sequence in place return None instead
> of returning self - ok, I know the rational for this one, but I still
> dont like it, and still count it as a special case since when using a
> 'destructive' sequence method I can't chain it with non-destructive 
> method calls.

This has nothing to do with special cases... Your countless special
cases are coming out to be things you didn't really understand about
python.

> - object.__getattr__ (if it exists...) is called only when attribute 
> name is not found. object.__setattr__ (if it exists...) is always called.

This is because of the new object model. Agree here, there should be
only one: __getattr__ or __getattribute__.

> - functions are not methods

functions are functions and methods are functions that take the instance
of the object as their first argument. Anyway discussion is ongoing to
remove the bound/unbound difference. Though you can actually do this:

In [14]: class A(object):
   : def foo(self, a):
   : print "hello world"
   : 

In [15]: a = A()

In [16]: a.foo(1)
hello world

In [17]: def baz():
   : 
KeyboardInterrupt

In [17]: def baz(self):
   : print "hello world"
   : 

In [18]: a.foo = baz.__get__(a)

In [19]: a.foo() 
hello world

> - old-style classes vs new-style classes

Agreed. Backwards compatibility wins here. Again Python 3k will remove
this.

Of all your points I agreed on only 3 or 4. This strikes me as a very
well thought out language that in 15 years managed to only get 3 or 4
special cases.

> Also, Python enforce some coding style (indentation) but not some others
> (capitalization for example). So you always have to check, on a lib by

you are mixing oranges and apples here.

> lib base, what style has been used (I personnaly don't give a damn 
> whether I use underscore_all_lower or mixedCaps, but consistency is 
> useful, even more when there's such a huge stdlib). Worst, the base 
> class for new style classes is all lower ('object') when the usual 
> convention is to use CamelCase for classes.

Python standard library is consistent with this style. The only library
I am aware of that doesn't follow this style is wxPython with wax, and I
always discurage every python developer to use this library for this
very reason. I can agree with you here, but this is not a special case.

> I'm not able to count them all, since a good part of them are not carved
> in my poor little brain - I just deal with them day after day. I love

You are not able to count them all since there are almost not special
cases. But many things that could be done in a better way (this is for
sure, python is far from perfect, but it 'sucks' a lot less then
everything else).

-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Bruno Desthuilliers]

Martin Franklin a écrit :
Tim Daneliuk wrote:
In-Reply-To: <[EMAIL PROTECTED]>
(snip)
Of course we users will complain about removals, but we'll knuckle
down and take our medicine eventually ;-)
Except that in this case, removal will also complicate code in some
cases.  Consider this fragment of Tkinter logic:
UI.CmdBtn.menu.add_command(label="MyLabel",
command=lambda cmd=cmdkey: 
CommandMenuSelection(cmd))

In this case you perhaps should try using a class like so:-
UI.CmdBtn.menu.add_command(label="MyLabel",
   command=CommandMenuSelectionCallback(cmdkey))
Where CommandMenuSelectionCallback is a class like so:
class CommandMenuSelectionCallback:
def __init__(self, key):
self.key = key
def __call__(self):
print self.key
Looks like Java.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Bruno Desthuilliers]

Valentino Volonghi aka Dialtone a écrit :
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
It is actually. Ruby's syntax is mostly consistent and coherent, and 
there is much less special cases than in Python.
 
I'd be glad to know which special cases are you referring to.
A few examples:
- A statement is different from an expression (2 special cases instead 
of one general case).
- You can't use statements in a lambda
- to get the length of a sequence, you use len(seq) instead of seq.len()
- to call objects attributes by name, you use [get|set]attr(obj, name 
[,value]) instead of obj.[get|set]attr(name [,value])
- if x is a class attribute of class A and a is an instance of A, 
a.x=anyvalue create a new instance attribute x instead of modifying A.x
- sequence methods that modify the sequence in place return None instead 
of returning self - ok, I know the rational for this one, but I still 
dont like it, and still count it as a special case since when using a 
'destructive' sequence method I can't chain it with non-destructive 
method calls.
- object.__getattr__ (if it exists...) is called only when attribute 
name is not found. object.__setattr__ (if it exists...) is always called.
- functions are not methods
- old-style classes vs new-style classes

Also, Python enforce some coding style (indentation) but not some others 
(capitalization for example). So you always have to check, on a lib by 
lib base, what style has been used (I personnaly don't give a damn 
whether I use underscore_all_lower or mixedCaps, but consistency is 
useful, even more when there's such a huge stdlib). Worst, the base 
class for new style classes is all lower ('object') when the usual 
convention is to use CamelCase for classes.

Please note that you wrote "much less" which means there are probably so
many that you weren't able to count them.
I'm not able to count them all, since a good part of them are not carved 
in my poor little brain - I just deal with them day after day. I love 
Python and find it one of the best languages around, but the truth is 
that it has warts - like any other language - and no one can honnestly 
deny it. Some are on the way to disappear (the type unification is a 
good thing in intself, even if it actually leads to having 2 more or 
less compatible object models...)

Regards,
Bruno
--
http://mail.python.org/mailman/listinfo/python-list

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

[Christopher C. Stacy]

"Brandon J. Van Every" <[EMAIL PROTECTED]> writes:
> Last I looked, 2 years ago?, there were no compiled, open source
> lisps that ran on Windows.  Has this changed?

GCL (formerly known as KCL and ACL) has been around since 1984,
and has been available on Windows since 2000.

ECL (another KCL derivative) has been available since about 1990.

Corman Common Lisp only runs on Windows, and has been available since 1998.

There might be others; those are off the top of my head.
I am also not counting here any Lisp implementations that 
ran on Windows under the Cygwin support; just native ones.

Historically, compiled open-souce Lisp implementations 
have been available since the 1960s.

All this information has been available in FAQs and 
on many web pages since forever.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

[James Graves]

Brandon J. Van Every <[EMAIL PROTECTED]> wrote:
>James Graves wrote:
>>
>> If you want to do application development, Common Lisp is where it's
>> at, no doubt about it.  There are more and better libraries for CL
>> these days, and they are easier to install and manage with tools like
>> ASDF. Multiple open-source implementations, covering the most popular
>> platforms (Windows, Linux, Mac).
>
>Last I looked, 2 years ago?, there were no compiled, open source lisps that
>ran on Windows.  Has this changed?

Yes.  

GCL compiles to C first.  And it has been ported to Windows.  It isn't
fully ANSI compliant yet, though they are working on that.  I haven't
had to try that yet.

There's talk about a port of SBCL to Windows.  But I don't know what
progress has been made on that front.  

But coverage in this area (compiled CL) is a bit thin, I'll admit.

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

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

[Fraca7]

On Tue, 15 Mar 2005 12:25:02 -0800, Brandon J. Van Every wrote:

> Last I looked, 2 years ago?, there were no compiled, open source lisps that
> ran on Windows.  Has this changed?

I don't think so. I recently (about 2 months ago) started to want to learn
Lisp (didn't go far for now) and wanted to find a Windows impl, to
evaluate "cross-platformability". The only open source/free software Lisp
interpreter I found was Common Lisp under Cygwin. Not exactly win32
native. But good enough, I think.

-- 
One Page Principle:
A specification that will not fit on one page of 8.5x11 inch
paper cannot be understood.
-- Mark Ardis

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

compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

[Brandon J. Van Every]

James Graves wrote:
>
> If you want to do application development, Common Lisp is where it's
> at, no doubt about it.  There are more and better libraries for CL
> these days, and they are easier to install and manage with tools like
> ASDF. Multiple open-source implementations, covering the most popular
> platforms (Windows, Linux, Mac).

Last I looked, 2 years ago?, there were no compiled, open source lisps that
ran on Windows.  Has this changed?

-- 
Cheers, www.indiegamedesign.com
Brandon Van Every   Seattle, WA

"The pioneer is the one with the arrows in his back."
  - anonymous entrepreneur

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

Re: Python becoming less Lisp-like

[James Graves]

Brandon J. Van Every <[EMAIL PROTECTED]> wrote:
>James Graves wrote:
>>
>> So with Python 3000, you're going to end up with a language just as
>> big as CL, but without the most fundamental building blocks.  Ah
>> well, to each his own.
>
>Preventing people from building things from scratch is probably an
>industrial advantage.  

I believe that steering people away from building similar constructs
from scratch is a good thing.  You end up different implementations
which do almost, but not quite, the same thing.  And that is a hassle to
maintain.

However, trying to _prevent_ this in the language itself is too
restrictive, IMHO.  Most (perhaps nearly all) of the time, I should be
using the standard constructs provided by the language base.  But there
will be times and circumstances where I will want to build my own, from
the ground up.

And some of these times, that will be the Right Thing to Do, too.

>Look how fragmented the Lisp world is.

I have looked at the Lisp world.  In depth.  It's not as bad as it used
to be, and it is getting better day-by-day.  

If you want a nice enviroment to learn programming, get DrScheme.  There
are some good (free!) books out there on the 'net.

If you want to do application development, Common Lisp is where it's at,
no doubt about it.  There are more and better libraries for CL these
days, and they are easier to install and manage with tools like ASDF. 
Multiple open-source implementations, covering the most popular
platforms (Windows, Linux, Mac).

Cheers,

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

Re: Python becoming less Lisp-like

[El Pitonero]

Fernando wrote:
> The real problem with Python is ... Python is
> going the C++ way: piling feature upon feature, adding bells
> and whistles while ignoring or damaging its core design.

I totally agree.

Look at a recent thread "Compile time evaluation (aka eliminating
default argument hacks)"

http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/d0cd861daf3cff6d/6a8abafed95a9053#6a8abafed95a9053

where people coming from C++ or other typical programming languages
would do:

x = 1
def _build_used():
  y = x + 1
  return x, y
def f(_used = _build_used()):
  x, y = _used
  print x, y

instead of:

x=1
def f():
   y=x+1
   global f
   def f(x=x, y=y):
 print x, y
   f()

It is easy to see that people have been molded into thinking one way
(declaration of functions, legacy from staticly typed languages),
instead of viewing code also as object that you can tweak.

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

Re: Python becoming less Lisp-like

[Brandon J. Van Every]

James Graves wrote:
>
> So with Python 3000, you're going to end up with a language just as
> big as CL, but without the most fundamental building blocks.  Ah
> well, to each his own.

Preventing people from building things from scratch is probably an
industrial advantage.  Look how fragmented the Lisp world is.

-- 
Cheers,   www.indiegamedesign.com
Brandon Van Every Seattle, WA

"witch-hunt" - (noun) (Date: 1885)
1: a searching out for persecution of persons accused
   of witchcraft
2: the searching out and deliberate harassment of
   those (as political opponents) with unpopular views
- witch-hunter (noun)
- witch-hunting (noun or adjective)

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

Re: Python becoming less Lisp-like

[James Graves]

Fernando   <[EMAIL PROTECTED]> wrote:

> Peter Seibel <[EMAIL PROTECTED]> wrote:
>
> > Looks like the BDFL is planning to take lambda, reduce, filter, and
> > map out of Python in the next big rev of Python (so called Python
> > 3000):
> >
> >  
>
>Basically, it says that it will get rid of the explicit map, filter
>and reduce and substitute them by some syntactic sugar that uses them
>implicitly. That's ok, and not a big deal.
>
>It will also get rid of lambda, and it's not a great loss, since
>python's version is so limited that it's almost useless. Besides,
>given the syntactic sugar used to replace map, reduce and filter,
>there's no real need for lambda in the most usual cases.

It is my opinion that this is a natural consequence of infix notation,
deep operator precedence heirarchy, and consequently no macro system.

With Lisp, you have the good, solid, general constructs.  And if you
need syntactic sugar (like WHEN, for example), you can just build
it up using macros.

So with Python 3000, you're going to end up with a language just as big
as CL, but without the most fundamental building blocks.  Ah well, to
each his own.

My Road to Lisp was long and twisty.  For a while it covered some Python
territory.  But I started look into where exactly the interesting bits
of Python came from.  And here I am.  Though I've still got a lot to
learn.

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

Re: Python becoming less Lisp-like

[Steven Bethard]

Torsten Bronger wrote:
[EMAIL PROTECTED] (Paul Boddie) writes:
Well, I've been using Python for almost ten years, and I've
managed to deliberately ignore descriptors and metaclasses quite
successfully. I get the impression that descriptors in particular
are a detail of the low-level implementation that get a
disproportionate level of coverage because of the "hack value"
they can provide (albeit with seemingly inappropriate application
to certain problem areas).
I have exactly the same impression, but for me it's the reason why I
feel uncomfortable with them.  For example, I fear that a skilled
package writer could create a module with surprising behaviour by
using the magic of these constructs.  I don't know Python well
enough to get more specific, but flexibility almost always make
confusing situations for non-hackers possible.
I know that such magic is inavoidable with dynamic languages, but
descriptors will be used almost exclusively for properties, and
therefore I think it would have been better to hard-wire properties
in the interpreter rather than pollute the language with this sort
of proto-properties (aka descriptors).
Certainly descriptors in the "wrong hands" could lead to confusing, 
unreadable code.  But Python is a "we're all adults here" language, and 
so we have to trust other coders to be responsible.  There are some very 
reasonable uses for descriptors which I don't believe are really 
confusing, for example the lazy property recipe:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/363602
While writing too many descriptors is a code smell, the functionality is 
there as an implementation detail of new-style classes, and I'm quite 
happy that Python trusts me enough to expose this detail for when I need it.

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

Re: Python becoming less Lisp-like

[Serge Orlov]

Fernando wrote:
> On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel
<[EMAIL PROTECTED]>
> wrote:
>
> >Looks like the BDFL is planning to take lambda, reduce, filter, and
> >map out of Python in the next big rev of Python (so called Python
> >3000):
> >
> >  
>
> Basically, it says that it will get rid of the explicit map, filter
> and reduce and substitute them by some syntactic sugar that uses them
> implicitly. That's ok, and not a big deal.
>
> It will also get rid of lambda, and it's not a great loss, since
> python's version is so limited that it's almost useless. Besides,
> given the syntactic sugar used to replace map, reduce and filter,
> there's no real need for lambda in the most usual cases.
>
> The real problem with Python is that it has been very successful as a
> scripting language in the static-typing/C/C++ world. Those
> programmers, instead of adapting their evil ways to Python, and
> realizing the advantages of a dynamic language, are influencing
> Python's design and forcing it into the static-typing mold. Python is
> going the C++ way: piling feature upon feature, adding bells and
> whistles while ignoring or damaging its core design.

You're wrong about design: http://www.artima.com/intv/pyscale.html
Quoting Guido: The first sound bite I had for Python was, "Bridge
the gap between the shell and C." So I never intended Python to be
the primary language for programmers.


>
> The new 'perlified' syntax for decorators, the new static type bonds
> and the weird decision to kill lambda instead of fixing it are good
> examples that show that Python is going the wrong way. What used to
> be a cool language will soon be an interpreted C/C++ without any
> redeeming value. A real pity...

Yeah, that was a good time. After a nice bridge between the shell
and C was built they never ceased piling feature upon feature and
kept adding bells and wristles.

  Serge.

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

Re: Python becoming less Lisp-like

[Torsten Bronger]

HallÃchen!

Ville Vainio <[EMAIL PROTECTED]> writes:

>> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> writes:
>
> >>> There would be keywords for static and class methods, no
> >>> distinction between Unicode and non-Unicode
>
> >> You couldn't do that 15 years ago because there were no Unicode
> >> that time.
>
> Torsten> I've never said that Guido was just too stupid at that
> Torsten> time.  I only said "but you can definitely see that it's
> Torsten> the oldest one".  In other words, a Ruby six years older
> Torsten> than the real one would have the same problem.  And who
> Torsten> knows how C# looks like in 10 years.
>
> http://c2.com/cgi/wiki?PythonVsRuby
>
> seems to suggest that Python has better Unicode support than Ruby.

True.  When you google for it, you read "Japanese hate Unicode".
:-/  Well, then this is an invalid example.

TschÃ,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Ville Vainio]

> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> writes:

>>> There would be keywords for static and class methods, no
>>> distinction between Unicode and non-Unicode

>> You couldn't do that 15 years ago because there were no Unicode
>> that time.

Torsten> I've never said that Guido was just too stupid at that
Torsten> time.  I only said "but you can definitely see that it's
Torsten> the oldest one".  In other words, a Ruby six years older
Torsten> than the real one would have the same problem.  And who
Torsten> knows how C# looks like in 10 years.

http://c2.com/cgi/wiki?PythonVsRuby

seems to suggest that Python has better Unicode support than Ruby.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Ville Vainio]

> "Tim" == Tim Daneliuk <[EMAIL PROTECTED]> writes:

Tim> Except that in this case, removal will also complicate code
Tim> in some cases.  Consider this fragment of Tkinter logic:

Tim> UI.CmdBtn.menu.add_command(label="MyLabel",
Tim> command=lambda cmd=cmdkey: CommandMenuSelection(cmd))

Tim> Would it not be the case that, without lambda, we will need
Tim> to pollute the name space with a bunch of specialized little
Tim> functions for each and every construct like this?

You can reuse the same name for all those little functions to avoid
polluting the namespace. Choose 'L' if it gives you that cozy
lambda-ish feel.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Torsten Bronger]

HallÃchen!

[EMAIL PROTECTED] (Paul Boddie) writes:

> Torsten Bronger <[EMAIL PROTECTED]> wrote:
>
>> At first, I was very pleased by Python's syntax (and still I am).
>> Then, after two weeks, I learned about descriptors and
>> metaclasses and such and understood nothing (for the first time
>> in syntax I felt totally lost).
>
> Well, I've been using Python for almost ten years, and I've
> managed to deliberately ignore descriptors and metaclasses quite
> successfully. I get the impression that descriptors in particular
> are a detail of the low-level implementation that get a
> disproportionate level of coverage because of the "hack value"
> they can provide (albeit with seemingly inappropriate application
> to certain problem areas).

I have exactly the same impression, but for me it's the reason why I
feel uncomfortable with them.  For example, I fear that a skilled
package writer could create a module with surprising behaviour by
using the magic of these constructs.  I don't know Python well
enough to get more specific, but flexibility almost always make
confusing situations for non-hackers possible.

I know that such magic is inavoidable with dynamic languages, but
descriptors will be used almost exclusively for properties, and
therefore I think it would have been better to hard-wire properties
in the interpreter rather than pollute the language with this sort
of proto-properties (aka descriptors).

TeX is extremely dynamic.  It can modify its own scanner in order to
become an XML parser or AFM (Adobe font metrics) reader.  This is
highly confusing for all but those five or six people on this planet
who speak TeX fluently.  Since I saw raw TeX, I dislike
"proto-syntaxes" (or meta-syntaxes if you wish).

TschÃ,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Paul Boddie]

Torsten Bronger <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> 
> At first, I was very pleased by Python's syntax (and still I am).
> Then, after two weeks, I learned about descriptors and metaclasses
> and such and understood nothing (for the first time in syntax I felt
> totally lost).

Well, I've been using Python for almost ten years, and I've managed to
deliberately ignore descriptors and metaclasses quite successfully. I
get the impression that descriptors in particular are a detail of the
low-level implementation that get a disproportionate level of coverage
because of the "hack value" they can provide (albeit with seemingly
inappropriate application to certain problem areas).

Still, having new- and old-style classes, a separate old-style
exception class hierarchy, and various other "transitional" features
doesn't seem very "Pythonic", does it? ;-)

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

Re: Python becoming less Lisp-like

[Peter Maas]

Carl Banks schrieb:
In Python, classes aren't some magical land where the usual rules don't
hold (as they are in many other languages).  That's why "self." is used
on class variables, for instance.  A class is nothing more than a scope
that uses a smittering of magic to turn it into a type.
scope -> dictionary
--
---
Peter Maas,  M+R Infosysteme,  D-52070 Aachen,  Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Martin Franklin]

Tim Daneliuk wrote:
In-Reply-To: <[EMAIL PROTECTED]>
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Nick Craig-Wood wrote:

Torsten Bronger <[EMAIL PROTECTED]> wrote:

The current snapshot is a transitional Python and thus
with some double features.  The numerical types and two kinds of
classes are examples.  I'm very surprised about this, because Python
is a production language, but I'm happy, too.

As long as python 2.x -> 3.x/3000 isn't like perl 5.x -> perl 6.x I'll
be perfectly happy too.
"Less is more" is a much better philosophy for a language and having
the courage to take things out differentiates python from the crowd.
Of course we users will complain about removals, but we'll knuckle
down and take our medicine eventually ;-)

Except that in this case, removal will also complicate code in some
cases.  Consider this fragment of Tkinter logic:
UI.CmdBtn.menu.add_command(label="MyLabel",
command=lambda cmd=cmdkey: 
CommandMenuSelection(cmd))
In this case you perhaps should try using a class like so:-
UI.CmdBtn.menu.add_command(label="MyLabel",
   command=CommandMenuSelectionCallback(cmdkey))
Where CommandMenuSelectionCallback is a class like so:
class CommandMenuSelectionCallback:
def __init__(self, key):
self.key = key
def __call__(self):
print self.key
Would it not be the case that, without lambda, we will need to pollute
the name space with a bunch of specialized little functions for each
and every construct like this?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Torsten Bronger]

HallÃchen!

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

> Torsten Bronger wrote:
>
>>> Interesting.  I've never thought that.  What parts strike you as
>>> "patchwork"?
>>
>> Well, with a little bit of experience in the field of programming
>> languages, you can see which elements had been added later (ie
>> years after Python's creation).  Properties surely would have
>> looked *very* different 15 years ago.
>>
>> There would be keywords for static and class methods, no
>> distinction between Unicode and non-Unicode
>
> You couldn't do that 15 years ago because there were no Unicode
> that time.

I've never said that Guido was just too stupid at that time.  I only
said "but you can definitely see that it's the oldest one".  In
other words, a Ruby six years older than the real one would have the
same problem.  And who knows how C# looks like in 10 years.

But I want to program now, and this is the current situation in my
opinion.

TschÃ,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Serge Orlov]

Torsten Bronger wrote:
> > Interesting.  I've never thought that.  What parts strike you as
> > "patchwork"?
>
> Well, with a little bit of experience in the field of programming
> languages, you can see which elements had been added later (ie years
> after Python's creation).  Properties surely would have looked
> *very* different 15 years ago.
>
> There would be keywords for static and class methods, no distinction
> between Unicode and non-Unicode

You couldn't do that 15 years ago because there were no Unicode that
time.

  Serge.

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

Re: Python becoming less Lisp-like

[Tim Daneliuk]

In-Reply-To: <[EMAIL PROTECTED]>
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Nick Craig-Wood wrote:

> Torsten Bronger <[EMAIL PROTECTED]> wrote:
> 
>> The current snapshot is a transitional Python and thus
>> with some double features.  The numerical types and two kinds of
>> classes are examples.  I'm very surprised about this, because Python
>> is a production language, but I'm happy, too.
> 
> 
> As long as python 2.x -> 3.x/3000 isn't like perl 5.x -> perl 6.x I'll
> be perfectly happy too.
> 
> "Less is more" is a much better philosophy for a language and having
> the courage to take things out differentiates python from the crowd.
> 
> Of course we users will complain about removals, but we'll knuckle
> down and take our medicine eventually ;-)
> 

Except that in this case, removal will also complicate code in some
cases.  Consider this fragment of Tkinter logic:

UI.CmdBtn.menu.add_command(label="MyLabel",
command=lambda cmd=cmdkey: 
CommandMenuSelection(cmd))

Would it not be the case that, without lambda, we will need to pollute
the name space with a bunch of specialized little functions for each
and every construct like this?

-- 

Tim Daneliuk [EMAIL PROTECTED]
PGP Key: http://www.tundraware.com/PGP/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Carl Banks]

Torsten Bronger wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
> > Interesting.  I've never thought that.  What parts strike you as
> > "patchwork"?
>
> Well, with a little bit of experience in the field of programming
> languages, you can see which elements had been added later (ie years
> after Python's creation).  Properties surely would have looked
> *very* different 15 years ago.
>
> There would be keywords for static and class methods,

I don't think there would be.  For one thing, I doubt the Python
leadership thinks static and class methods are important enough to
warrant keywords.  For another thing, it violates Python's idea of how
much special belongs in class definitions (i.e., none at all).

In Python, classes aren't some magical land where the usual rules don't
hold (as they are in many other languages).  That's why "self." is used
on class variables, for instance.  A class is nothing more than a scope
that uses a smittering of magic to turn it into a type.

> no distinction
> between Unicode and non-Unicode,

True.

> and probably no multiple
> inheritance

I highly doubt it.  A couple years ago, when Python made the transition
to new-style classes, there was an opportunity to toss out multiple
inheritance.  Not only did the Python developers not toss it or
deprecate it, they put in a lot of work and effort to improve it.  We
now have a spiffy stable MRO algorithm to handle resolution of
attributes.

Besides, in the tradition of dynamic languages, MI is pretty par for
the course, unlike for static languages where it is seen as kind of
exotic.

>(which seem to have caused a lot of trouble recently),

Not sure what you're talking about here.  Was the problem with
XMLRPCServer related to MI?

> and no __new__.

Perhaps.  More likely, there would have been __new__ but no __init__.
At the C level, new and init do seem to serve distinct purposes, but I
don't know how important it would be in a new design.

> At first, I was very pleased by Python's syntax (and still I am).
> Then, after two weeks, I learned about descriptors and metaclasses
> and such and understood nothing (for the first time in syntax I felt
> totally lost).

Metaclasses weren't something that Python just threw in because it was
cool.  Rather, they were mostly a side effect of how Python constructs
classes.  When Python transistioned to new-style classes, the gods
decided to expose the metaclass functionality, because it could prove
useful in a lot of cases.

I believe, however, that there was an intentional lack of effort to
make them less obscure than they already are.  They didn't want average
people to be hacking metaclasses left and right.

> The reason why I stay with Python is (apart from the indenting
> syntax, huge community, and equally huge library) my feeling that
> the Python developers what to unify the language, even by dropping
> features.

Yes, fortunately that happens.  It's good, too.

> The current snapshot is a transitional Python and thus
> with some double features.  The numerical types and two kinds of
> classes are examples.  I'm very surprised about this, because Python
> is a production language, but I'm happy, too.

Yeah, well that's the price you gotta pay when remedying old mistakes
or restrictions.


-- 
CARL BANKS

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

Re: Python becoming less Lisp-like

[Nick Craig-Wood]

Torsten Bronger <[EMAIL PROTECTED]> wrote:
>  The current snapshot is a transitional Python and thus
>  with some double features.  The numerical types and two kinds of
>  classes are examples.  I'm very surprised about this, because Python
>  is a production language, but I'm happy, too.

As long as python 2.x -> 3.x/3000 isn't like perl 5.x -> perl 6.x I'll
be perfectly happy too.

"Less is more" is a much better philosophy for a language and having
the courage to take things out differentiates python from the crowd.

Of course we users will complain about removals, but we'll knuckle
down and take our medicine eventually ;-)

-- 
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Torsten Bronger]

HallÃchen!

Steven Bethard <[EMAIL PROTECTED]> writes:

> Torsten Bronger wrote:
>
>> the underlying constructs are utterly ugly, as are some of
>> Python's features (e.g. __getattr__ and such, and decorators, in
>> order to get nice class properties).
>
> What do you find ugly about __getattr__?

[First, I wanted to say "descriptors" instead of "decorators" (I
superseded my post).]

The goal is to trigger function calls when attributes are accessed.
This is called properties in C# (and maybe in Ruby, too).  Python
now also has this concept.  What I find ugly is that it is not a
syntax element.  It looks artificially added to the language.  In
C#, the "set" and "get" methods form with its attribute a syntactic
unity.  Everything is together, and no "property" function is
necessary.

>> I looked for a new language for my hobby programming.
>
> [snip]
>
>> I want to go with Python, but you can definitely see that it's
>> the oldest one: Many parts of its syntax are awkward and look
>> like patchwork.
>
> Interesting.  I've never thought that.  What parts strike you as
> "patchwork"?

Well, with a little bit of experience in the field of programming
languages, you can see which elements had been added later (ie years
after Python's creation).  Properties surely would have looked
*very* different 15 years ago.

There would be keywords for static and class methods, no distinction
between Unicode and non-Unicode, and probably no multiple
inheritance (which seem to have caused a lot of trouble recently),
and no __new__.

At first, I was very pleased by Python's syntax (and still I am).
Then, after two weeks, I learned about descriptors and metaclasses
and such and understood nothing (for the first time in syntax I felt
totally lost).

The reason why I stay with Python is (apart from the indenting
syntax, huge community, and equally huge library) my feeling that
the Python developers what to unify the language, even by dropping
features.  The current snapshot is a transitional Python and thus
with some double features.  The numerical types and two kinds of
classes are examples.  I'm very surprised about this, because Python
is a production language, but I'm happy, too.

TschÃ,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Valentino Volonghi aka Dialtone]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:

> It is actually. Ruby's syntax is mostly consistent and coherent, and 
> there is much less special cases than in Python.

I'd be glad to know which special cases are you referring to.
Please note that you wrote "much less" which means there are probably so
many that you weren't able to count them.
 
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Ulrich Hobelmann]

Torsten Bronger wrote:
HallÃchen!
Tach!
Moreover, I dislike the fact that new features are implemented
partly in the interpreter and partly in Python itself.  It reminds
me of TeX/LaTeX, where the enormous flexibility of TeX is used to
let it change itself in order to become a LaTeX compiler.  However,
the underlying constructs are utterly ugly, as are some of Python's
features (e.g. __getattr__ and such, and descriptors, in order to
get nice class properties).
Well, I think TeX is just an awful, weird language with (AFAIK) dynamic 
scoping.  Thinking of Lisp macros, I'd say that implementing features on 
top of a small language core is GREAT!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Bruno Desthuilliers]

news.sydney.pipenetworks.com a Ãcrit :

I looked for a new language for my hobby programming.  I used to use
Turbo Pascal for 10 years and then C++ for 6 years.  A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python.  At the
moment, I want to go with Python, but you can definitely see that
it's the oldest one: Many parts of its syntax are awkward and look
like patchwork.

You mean you think Ruby syntax is less awkward then Python ?
It is actually. Ruby's syntax is mostly consistent and coherent, and 
there is much less special cases than in Python.

Now it's also much more difficult to grasp Ruby for programmers coming 
from procedural languages, but that's another story.

Maybe you 
should add Perl to your list of languages to learn especially after your 
complaints about the decorator syntax.
I guess you stopped your exploration of Ruby at the first sign of 
'special chars' syntax.

I don't like Perl, I still prefer to use Python (over Ruby) for a number 
of good and less good reasons, but I somewhat share Fernando's (and some 
other's people here) concerns about the future of MyFavoriteLanguage.

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

Re: Python becoming less Lisp-like

[news.sydney.pipenetworks.com]

I looked for a new language for my hobby programming.  I used to use
Turbo Pascal for 10 years and then C++ for 6 years.  A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python.  At the
moment, I want to go with Python, but you can definitely see that
it's the oldest one: Many parts of its syntax are awkward and look
like patchwork.
You mean you think Ruby syntax is less awkward then Python ? Maybe you 
should add Perl to your list of languages to learn especially after your 
complaints about the decorator syntax.

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

Re: Python becoming less Lisp-like

[Fernando]

On Tue, 15 Mar 2005 00:01:09 +0100, Torsten Bronger
<[EMAIL PROTECTED]> wrote:


>> The new 'perlified' syntax for decorators,
>
>Python lost its innocence here: The first really special character,
>disturbing the former syntax style.  Not important, but irritating.
>
>> the new static type bonds
>
>What is meant by that?

http://www.artima.com/weblogs/viewpost.jsp?thread=85551
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Steven Bethard]

Torsten Bronger wrote:
the underlying constructs are utterly ugly, as are some of Python's
features (e.g. __getattr__ and such, and decorators, in order to get
nice class properties).
What do you find ugly about __getattr__?
I looked for a new language for my hobby programming.
[snip]
I want to go with Python, but you can definitely see that
it's the oldest one: Many parts of its syntax are awkward and look
like patchwork.
Interesting.  I've never thought that.  What parts strike you as 
"patchwork"?

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

Re: Python becoming less Lisp-like

[Torsten Bronger]

HallÃchen!

Fernando  <[EMAIL PROTECTED]> writes:

> [...]
>
> [...] Python is going the C++ way: piling feature upon feature,
> adding bells and whistles while ignoring or damaging its core
> design.

I'm new to Python, but I while I skimmed through the "What's new?"
of recent versions, I saw the same unfortunate development.

Moreover, I dislike the fact that new features are implemented
partly in the interpreter and partly in Python itself.  It reminds
me of TeX/LaTeX, where the enormous flexibility of TeX is used to
let it change itself in order to become a LaTeX compiler.  However,
the underlying constructs are utterly ugly, as are some of Python's
features (e.g. __getattr__ and such, and descriptors, in order to
get nice class properties).

> The new 'perlified' syntax for decorators,

Python lost its innocence here: The first really special character,
disturbing the former syntax style.  Not important, but irritating.

> the new static type bonds

What is meant by that?

> [...] What used to be a cool language will soon be an interpreted
> C/C++ without any redeeming value. A real pity...

I don't think so, there will be always an enormous difference.  But
Python seems a little bit chaotic.

I looked for a new language for my hobby programming.  I used to use
Turbo Pascal for 10 years and then C++ for 6 years.  A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python.  At the
moment, I want to go with Python, but you can definitely see that
it's the oldest one: Many parts of its syntax are awkward and look
like patchwork.

TschÃ,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Fernando]

On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel <[EMAIL PROTECTED]>
wrote:

>Looks like the BDFL is planning to take lambda, reduce, filter, and
>map out of Python in the next big rev of Python (so called Python
>3000):
>
>  

Basically, it says that it will get rid of the explicit map, filter
and reduce and substitute them by some syntactic sugar that uses them
implicitly. That's ok, and not a big deal.

It will also get rid of lambda, and it's not a great loss, since
python's version is so limited that it's almost useless. Besides,
given the syntactic sugar used to replace map, reduce and filter,
there's no real need for lambda in the most usual cases.

The real problem with Python is that it has been very successful as a
scripting language in the static-typing/C/C++ world. Those
programmers, instead of adapting their evil ways to Python, and
realizing the advantages of a dynamic language, are influencing
Python's design and forcing it into the static-typing mold. Python is
going the C++ way: piling feature upon feature, adding bells and
whistles while ignoring or damaging its core design. 

The new 'perlified' syntax for decorators, the new static type bonds
and the weird decision to kill lambda instead of fixing it are good
examples that show that Python is going the wrong way. What used to be
a cool language will soon be an interpreted C/C++ without any
redeeming value. A real pity...

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