Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Python becoming less Lisp-like

Reply
Thread Tools

Re: Python becoming less Lisp-like

 
 
Kay Schluehr
Guest
Posts: n/a
 
      03-15-2005
Maybe You can answer my question what this simple LISP function does ?

(defun addn (n)
#'(lambda (x)
(+ x n)))

This is correct LISP-syntax if You bear in mind LISPs powerwull macro
language...

I think Guido and python-dev are very carefull in adding new power to
Python. They have to balance the needs for powerfull language features
on the one hand, simplicity on the other hand. That this relation
drifts towards more power and more complexity since Python 2.2. is a
correct observation, but You probably may have notized that the number
of large projects using Python as their primal language is growing. The
boundary between that what was formerly called "systems programming"
and "scripting" is blurred ( if Your mindset reduces
"systems-programming" on the availability of pointers You certainly
don't have any problems with the common public prejudices ).

> 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.


Maybe You should explain what You regard as Pythons "core design", what
belongs to the core and what to the periphery? Otherwise Your statement
seems to be plain emotional.

> 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.


My hypothesis about lambda: lambda will be trashed because it is an
alien in the language. It is impure. Trashing it is an expression of
Pythons rassism. There is no way of "doing it right" without exceeding
it's power and making it less controlable. When Guido once stated that
the generator way of doing things is Pythons future it was also a
renouncement of lambda. Compared with this ideological orientation the
introduction of the @-syntax is a minor sacrilege on syntax esthetics -
though this special character may hurd the souls of the believers more
that everything else introduced into the language.

Kay

 
Reply With Quote
 
 
 
 
Nick Craig-Wood
Guest
Posts: n/a
 
      03-15-2005
Torsten Bronger <(E-Mail Removed)-aachen.de> 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 <(E-Mail Removed)> -- http://www.craig-wood.com/nick
 
Reply With Quote
 
 
 
 
Carl Banks
Guest
Posts: n/a
 
      03-15-2005

Torsten Bronger wrote:
> Steven Bethard <(E-Mail Removed)> 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

 
Reply With Quote
 
Tim Daneliuk
Guest
Posts: n/a
 
      03-15-2005
In-Reply-To: <(E-Mail Removed)-wood.com>
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 <(E-Mail Removed)-aachen.de> 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 http://www.velocityreviews.com/forums/(E-Mail Removed)
PGP Key: http://www.tundraware.com/PGP/
 
Reply With Quote
 
Serge Orlov
Guest
Posts: n/a
 
      03-15-2005
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.

 
Reply With Quote
 
Torsten Bronger
Guest
Posts: n/a
 
      03-15-2005
Hallöchen!

"Serge Orlov" <(E-Mail Removed)> 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
 
Reply With Quote
 
Peter Maas
Guest
Posts: n/a
 
      03-15-2005
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')
-------------------------------------------------------------------
 
Reply With Quote
 
Martin Franklin
Guest
Posts: n/a
 
      03-15-2005
Tim Daneliuk wrote:
> In-Reply-To: <(E-Mail Removed)-wood.com>
> 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 <(E-Mail Removed)-aachen.de> 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?
>


 
Reply With Quote
 
Paul Boddie
Guest
Posts: n/a
 
      03-15-2005
Torsten Bronger <(E-Mail Removed)-aachen.de> wrote in message news:<(E-Mail Removed)-aachen.de>...
>
> 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
 
Reply With Quote
 
Torsten Bronger
Guest
Posts: n/a
 
      03-15-2005
Hallöchen!

(E-Mail Removed) (Paul Boddie) writes:

> Torsten Bronger <(E-Mail Removed)-aachen.de> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
More Efficiency,More Benefit,Less Risk,Less Work! jiajia wu ASP .Net 0 10-01-2009 01:50 PM
More Efficiency,More Benefit,Less Risk,Less Work! 6668 Ruby 0 05-14-2009 12:33 AM
Re: Is c.l.py becoming less friendly? Terry Reedy Python 3 02-06-2009 09:11 AM
Is c.l.py becoming less friendly? mk Python 1 02-05-2009 04:22 PM
mozilla spam filter becoming less effective Dave - Dave.net.nz NZ Computing 1 08-22-2005 05:43 AM



Advertisments