What is Python's answer to Perl 6?

[Reinhold Birkenfeld]

Hello,

another Perl/Python question: the subject says it all.

Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.

Is Python taking a similar step (-> Python 3) some time in the near future?

Reinhold

 

[Cliff Wells]

Hello,

another Perl/Python question: the subject says it all.

Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.

Is Python taking a similar step (-> Python 3) some time in the near future?

assert("Perl 6" < "Python 2")

Somehow I suspect that assertion will hold for the foreseeable future,
no matter how much the numbers change <wink>

 

[Valentino Volonghi aka Dialtone]

Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.

Why do you say this? Did you read the whole Apocalypses? Anyway 15 days ago
freshmeat published this:
http://freshmeat.net/articles/view/1339/

Maybe, it's not that easier to read or write.

Is Python taking a similar step (-> Python 3) some time in the near future?

Why? What do you need to do in python that you can't do right now? Isn't it
read-write friendly enough?

Perl6 is, currently, a 4 year development effort that no one knows when will
be ended (I even read that it will take another 4 years), maybe, if it takes
so much to develop just the first version, it's really too complicated.

 

[Dirkjan Ochtman]

Hello,

another Perl/Python question: the subject says it all.

Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.

Is Python taking a similar step (-> Python 3) some time in the near future?

Reinhold

The virtual machine underlying the Perl 6 language, Parrot
(www.parrotcode.org) will also support running Python. This will
probably incur performance benefits as well as allowing some interesting
interoperability between Perl 6 and Python-on-Parrot.

Whether Python-on-Parrot will become the official Python: I don't know.

Regards,

Dirkjan

 

[Reinhold Birkenfeld]

Why do you say this? Did you read the whole Apocalypses?

Yes, I read most of the Apocalypses, the Exegeses and the Synopses.

Anyway 15 days ago freshmeat published this:
http://freshmeat.net/articles/view/1339/

Maybe, it's not that easier to read or write.

For average programs, it seems that it will. Just think about classes.
One thing the freshmeat article complains about is breaking
compatibility. Well, you can't correct design mistakes by keeping old
syntax around.

A great plus will be the new regular expressions.

Why? What do you need to do in python that you can't do right now? Isn't it
read-write friendly enough?

Perl6 is, currently, a 4 year development effort that no one knows when will
be ended (I even read that it will take another 4 years), maybe, if it takes
so much to develop just the first version, it's really too complicated.

That's a point. The whole object system (roles, interfaces, etc.) is far
too complicated and almost no one will need it.

Reinhold

PS: I'm happy with Python, and I'm not going to complain about it. But
as a programmer who uses both languages, I'm just asking because I'm
curious...

 

[Michael Hoffman]

The virtual machine underlying the Perl 6 language, Parrot
(www.parrotcode.org) will also support running Python. This will
probably incur performance benefits as well as allowing some interesting
interoperability between Perl 6 and Python-on-Parrot.

I'll believe the performance benefits when I see them. The Parrot people
promised they would be faster by OSCON 2004 or Guido would get to pie
Dan Sugalski in the face. If you don't already know what happened, you
can see a picture here:

http://weblogs.mozillazine.org/zach/archives/006129.html

 

[Valentino Volonghi aka Dialtone]

Yes, I read most of the Apocalypses, the Exegeses and the Synopses.

I hope it worths the effort

For average programs, it seems that it will. Just think about classes.
One thing the freshmeat article complains about is breaking
compatibility. Well, you can't correct design mistakes by keeping old
syntax around.

Correct, but breaking everything in the language will make Perl6 a
completely new one, just preserving the name. And the community will have to
relearn from scratch to love it. Are you ready to almost trash all the
current perl5 library?

PS: I'm happy with Python, and I'm not going to complain about it. But
as a programmer who uses both languages, I'm just asking because I'm
curious...

I actually hope python 3.0 is not that far away, since there are some tiny
things that really need to be fixed in python2. Perl and Python, after all,
have a very different philosophy and the featurefulness of perl6 will be
matched with the extreme simplicity and clarity of python (which is also
a feature)

 

[A.M. Kuchling]

Is Python taking a similar step (-> Python 3) some time in the near future?

The list of features for Python 3000 is described in PEP 3000,
appropriately enough:

http://www.python.org/peps/pep-3000.html

Most of the suggested changes remove redundancy, such as removing
now-unneeded built-in functions and language features.

--amk

 

[Ville Vainio]

"Reinhold" == Reinhold Birkenfeld
Reinhold> A great plus will be the new regular expressions.

Well, if they are any good we'll just port them to Python. "import
re2" and we are all set. Everyone wins.


Reinhold> PS: I'm happy with Python, and I'm not going to complain
Reinhold> about it. But as a programmer who uses both languages,
Reinhold> I'm just asking because I'm curious...

Overall, there seems to be some kind of minor consensus (to the extent
it means anything in the internet) that perl6 is a disaster that is
taking way too long to happen. Implementing (rather making the design
decisions) py3k seems trivial in comparison.

 

[gabriele renzi]

Michael Hoffman ha scritto:

I'll believe the performance benefits when I see them. The Parrot people
promised they would be faster by OSCON 2004 or Guido would get to pie
Dan Sugalski in the face. If you don't already know what happened, you
can see a picture here:

http://weblogs.mozillazine.org/zach/archives/006129.html

well, they failed to implement all of the tests but those implemented
actually run faster than CPython.
Anyway they are at 0.1.1 or something like that. There is time to become
faster or to disappear completely, I guess

 

[Jonathan Ellis]

Hello,

another Perl/Python question: the subject says it all.

Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.

Perl6 has been in development since 2001 and isn't anywhere near done.
No doubt it will be done sometime but it reminds me of Gnu Hurd --
working alternatives are out there so it's hard to get excited about
vapor. (Which isn't exactly fair to the Hurd guys.

Perl6 will fix some of the worst broken-ness of perl5 but I haven't
seen anything indicating that Wall's TMTOWTDI philosophy has changed,
so it will still suck for anything nontrivial.

-Jonathan

 

[Jonathan Ellis]

The list of features for Python 3000 is described in PEP 3000,
appropriately enough:

http://www.python.org/peps/pep-3000.html

Most of the suggested changes remove redundancy, such as removing
now-unneeded built-in functions and language features.

I'm sure this has been brought up before, but a quick google search
didn't find anything on moving [has|get|set]attr into attributes of
object. Why wouldn't this be considered a Good Thing? Just because
Ruby people would like it?

-Jonathan

 

[Reinhold Birkenfeld]

The list of features for Python 3000 is described in PEP 3000,
appropriately enough:

http://www.python.org/peps/pep-3000.html

Most of the suggested changes remove redundancy, such as removing
now-unneeded built-in functions and language features.

I'm sure this has been brought up before, but a quick google search
didn't find anything on moving [has|get|set]attr into attributes of
object. Why wouldn't this be considered a Good Thing? Just because
Ruby people would like it?

You can take this step even further:

The builtin functions (that aren't doomed for py3k) can be classified in
those groups:

A. Constructors for built-in types

basestring, bool, complex, dict, file, float, int, list, long, object,
str, slice, tuple, type

These cannot be made attributes of some object.

B. Functions that can be attributed to some class or module

abs, divmod, round, pow -> math

ord -> str
In consequence: [uni]chr -> int
hex, oct -> int

super, *attr, isinstance, issubclass -> object

hash -> sys?

C. Functions that could be made attributes of lists/sequences

max, min, len, enumerate, sum

But that would require to implement them for all sequence types or
implement a common basetype 'seq'.

D. Other functions I cannot attribute to a class

eval
globals, locals, vars
iter
property
classmethod, staticmethod
cmp
[x]range
repr
__import__

Reinhold

 

[A.M. Kuchling]

Well, if they are any good we'll just port them to Python. "import
re2" and we are all set. Everyone wins.

I don't think so. Perl5 regexes are pretty independent of the rest of the
language, but Perl6's are interweaved with the rest of Perl's syntax, so I
don't think we'll ever see a Perl6-equivalent of PCRE.

--amk

 

[Michael Hoffman]

C. Functions that could be made attributes of lists/sequences

max, min, len, enumerate, sum

But that would require to implement them for all sequence types or
implement a common basetype 'seq'.

And iterators?

 

[Michael Hoffman]

well, they failed to implement all of the tests but those implemented
actually run faster than CPython.

Just saying, they said they would deliver it by a certain date and they
didn't. I understand the team is mainly made up of volunteers so I am
sympathetic, but I will still believe their claims only when they prove
them.

Anyway they are at 0.1.1 or something like that. There is time to become
faster or to disappear completely, I guess

There is also time for CPython or IronPython to become faster during
that time.

 

[Josiah Carlson]

Hello,

another Perl/Python question: the subject says it all.

Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.

Is Python taking a similar step (-> Python 3) some time in the near future?

I'd say Python 2.2, 2.3 and 2.4 are all answers to Perl 6. Python has
gotten incrementally faster, gained a larger standard library, and added
some language features without breaking backwards compatibility in a
major way.

Python is getting better /today/. Python is available /today/. Perl 6
won't be available for a couple years, meanwhile, Perl 5 doesn't seem
like it has undergoing any significant changes in a few years (I don't
follow Perl 5's development, but I haven't noticed any slashdot stories
on Perl 5).

- Josiah

 

[Peter Hansen]

And iterators?

And dicts. And ....

 

[Reinhold Birkenfeld]

And dicts. And ....

Exactly the problem.

Reinhold

 

[Reinhold Birkenfeld]

I don't think so. Perl5 regexes are pretty independent of the rest of the
language, but Perl6's are interweaved with the rest of Perl's syntax, so I
don't think we'll ever see a Perl6-equivalent of PCRE.

The interweaving is only important if you "design your program as one
big regex" . There is the possibility of embedded closures, OK, but
one can live without it.

The assignment of variables in regexes can surely be reproduced in a
PCRE lib.

And I can imagine to wrap up the Perl6 concept of grammars in a class
that then can resolve referenced regexes.

(Perl6 proposes this sort of syntax for grouping regexes:

grammar Some_Grammar {
rule identifier { [a-z]* }
rule plus_expression { <identifier> \+ <identifier> }
etc.
}

)

I just think that the new RE syntax is much cleaner and easier to read.
We'll see how other languages adapt or not.

Reinhold