I just came back from teaching Python on a cruise ship attended by mostly Perl folks. It was an interesting experience teaching Python with Randal in the audience =). One issue that came up is some of the lack of uniformity on what things are statements, methods and built-in functions. In the long-term version of the type/class unification work, things like int() become class constructors, which makes beautiful sense. The fact that int() calls __int__ methods fits nicely with type conversion mechanisms. However, there are a few things which still seem oddballish: copy.copy(), copy.deepcopy(), len() These basically call magic methods of their arguments (whether tp_slots or __methods__), and many languages implement them strictly as object methods. str() and repr() are a little weird -- I'm not sure which one will gain 'class constructor' status when the type/class unification work is done -- from the definition I'd say repr() should win, but the name is quite unfortunate given its new role... Guido, thoughts? Summary: Should copy, deepcopy and len be added as object methods? And if yes, how? Not all objects are copyable or measurable. Interfaces seem the right way to do this, but interfaces aren't in the plans so far that I know... What about a stringification method? --david
I just came back from teaching Python on a cruise ship attended by mostly Perl folks. It was an interesting experience teaching Python with Randal in the audience =).
Tell us more...
One issue that came up is some of the lack of uniformity on what things are statements, methods and built-in functions. In the long-term version of the type/class unification work, things like int() become class constructors, which makes beautiful sense. The fact that int() calls __int__ methods fits nicely with type conversion mechanisms.
Except that __int__ is poorly defined -- sometimes it is used as a precision-losing number cast (e.g. int(3.5) returns 3), sometimes it is an exact conversion (e.g. int("3")).
However, there are a few things which still seem oddballish:
copy.copy(), copy.deepcopy(), len()
These basically call magic methods of their arguments (whether tp_slots or __methods__), and many languages implement them strictly as object methods.
Yes, it's an old Python choice. OO zealots don't like it much, but it has the advantage that you don't have to introduce methods right away. Too late to change.
str() and repr() are a little weird -- I'm not sure which one will gain 'class constructor' status when the type/class unification work is done -- from the definition I'd say repr() should win, but the name is quite unfortunate given its new role... Guido, thoughts?
str() has won -- in part because of its name, in part because it is the "copy constructor", returning a string input unchanged.
Summary: Should copy, deepcopy and len be added as object methods? And if yes, how? Not all objects are copyable or measurable. Interfaces seem the right way to do this, but interfaces aren't in the plans so far that I know...
What about a stringification method?
I'd say leave it alone (we're getting enough complaints about "gratuitous" language changes as it is, and the changes we've committed to have very good reasons). --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I just came back from teaching Python on a cruise ship attended by mostly Perl folks. It was an interesting experience teaching Python with Randal in the audience =).
Tell us more...
Not much to tell. Randal was polite in my class and didn't interrupt too much =). There were some interesting discussions between Paul Prescod, Cameron Laird, Damian Conway, Mark-Jason Dominus, Randal and myself about Perl 6, which is looking more and more like Python from what I can tell. The most interesting bit of knowledge I learned is that the $, % and @ characters have a name -- they are sigils. And their use is going to change in Perl 6 to be consistent across contexts, as they'll be bound with the variable. Soon I may be able to say that "If Python hadn't been around, Perl 6 would be my language of choice". <snicker/>
Except that __int__ is poorly defined -- sometimes it is used as a precision-losing number cast (e.g. int(3.5) returns 3), sometimes it is an exact conversion (e.g. int("3")).
Actually, that doesn't bother me -- the definition which works well is "convert yourself to an integer". The fact that the float object decided to consider that as a truncation is possibly a bug in the float object's decision, but __int__ is still 'convert to int, however you (the type) see fit'.
Yes, it's an old Python choice. OO zealots don't like it much, but it has the advantage that you don't have to introduce methods right away. Too late to change.
I wasn't suggesting that we change it. Only that we add methods to the objects, much like we added string methods but kept the string module.
str() has won -- in part because of its name, in part because it is the "copy constructor", returning a string input unchanged.
Ah, subtle point I had missed.
I'd say leave it alone (we're getting enough complaints about "gratuitous" language changes as it is, and the changes we've committed to have very good reasons).
Again, I wasn't considering getting rid of old builtins. We're going to be adding new methods to all of the types anyway (since they'll derive from object), so I was just suggesting that len or length be an alias for __len__. A minor issue at most. Cheers, --david
Again, I wasn't considering getting rid of old builtins. We're going to be adding new methods to all of the types anyway (since they'll derive from object), so I was just suggesting that len or length be an alias for __len__.
Hm, but this would violate TOOWTDI. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Again, I wasn't considering getting rid of old builtins. We're going to be adding new methods to all of the types anyway (since they'll derive from object), so I was just suggesting that len or length be an alias for __len__.
Hm, but this would violate TOOWTDI.
So do string methods =). --da
Guido van Rossum wrote:
Again, I wasn't considering getting rid of old builtins. We're going to be adding new methods to all of the types anyway (since they'll derive from object), so I was just suggesting that len or length be an alias for __len__.
Hm, but this would violate TOOWTDI.
I am not an OO zealot but I am a consistency zealot. Calling a function that just turns around and calls a method is somewhat confusing and increasingly out of step with all of the other languages that support OO. I would appreciate if you could put this on the long-term fixes list and then you could choose an appropriate time when the howls of pain would be subdued. It really isn't in the same class as the division change because it is easy to interpret old code in the old way. We could support the "preferred syntax" and the "legacy syntax" indefinitely and there would still only one RIGHT way to do it. (just like you could still throw strings as exceptions but you aren't supposed to...) -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook
David Ascher wrote:
...
Not much to tell. Randal was polite in my class and didn't interrupt too much =).
Randal was polite in general but there was a point where he interjected: "And you say *Perl* has a lot of special cases? Python seems to have just as many!" These "function syntaxed methods" are one example but there are others. Some of the others are convenient (e.g. special casing of non-tuples after %) and some are backwards compatibility issues. Also, every time we'd point to a feature of Python (OO syntax, exception handling, generators, *) that was clearly better than Perl, Randal claimed it was already slated to be fixed for Perl 6. We suggested he print t-shirts with that refrain.
... There were some interesting discussions between Paul Prescod, Cameron Laird, Damian Conway, Mark-Jason Dominus, Randal and myself about Perl 6, which is looking more and more like Python from what I can tell.
My sense was "Second System Syndrome" but Damian Conway is confident that they don't have that problem. * from my point of view it seemed that we agreed that Python was better than Perl at almost everything but then I didn't sit in on Damian's "Data Munging" talk. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook
"PP" == Paul Prescod <paulp@ActiveState.com> writes:
PP> My sense was "Second System Syndrome" but Damian Conway is PP> confident that they don't have that problem. Isn't that one of the signs of the second system effect? <0.5 wink> Did he offer any reason for his confidence? Jeremy
Jeremy Hylton wrote:
"PP" == Paul Prescod <paulp@ActiveState.com> writes:
PP> My sense was "Second System Syndrome" but Damian Conway is PP> confident that they don't have that problem.
Isn't that one of the signs of the second system effect? <0.5 wink>
Did he offer any reason for his confidence?
I think the fundamental source of their confidence lay in Randal's answer when I challenged the claim that they would write translators which would automatically translate 95% of Perl5 code to Perl6: "If we're smart enough to write Perl5, we can do this". I think it glosses over a lot of important issues, but this isn't the forum to discuss it. Perl6 is being defined pretty much as the kitchen sink -- any cool feature from any cool language is going to be supported. Paul and I are skeptical about the ability to make that a coherent whole, but then again Perl doesn't really claim coherence, from what I can tell. Perl6 will have generators, coroutines but not continuations, higher-order functions, etc. etc. At the same time, they're trying to fix some of the issues which made Perl4/5 hard to learn, such as sigil mutability, etc. It's designed by committees (30 or so?), on the assumption that integration is a smaller issue than designing each 'feature' well. It's an interesting project to watch from the outside. There is also apparently a real split between people who are involved in Perl6 and those who aren't at all. I did have a very interesting chat w/ Damian Conway -- he said that Perl6 is already succeeding because it's revitalized the Perl5 community, and that there are lots of high-quality modules added to CPAN inspired by the Perl6 discussions. It also makes me a little jealous -- Perl manages to be a place where significant progress is made in the libraries as distinct from the core. In Pythonia, there is too much emphasis among the elite (us =) on adding features to the core as opposed to library modules, IMO. Related is the fact that much 'cutting-edge' work in Perl is written in Perl, while most of the cutting edge stuff in Pythonia is done in C. Some of that relates to the almost infinite mutability of the Perl engine by Perl itself, which is not a design goal of Python's -- we don't want 'just anyone' adding new keywords, for example. Still, there is room for exploration and prototyping there which we don't have such easy access to. --david
On Wed, Aug 22, 2001 at 11:44:36AM -0700, David Ascher wrote:
which would automatically translate 95% of Perl5 code to Perl6: "If we're smart enough to write Perl5, we can do this". I think it glosses
<snicker> "We let our code base deteroriate into an incomprehensible mess of code, and damn it, we can do it again!"
libraries as distinct from the core. In Pythonia, there is too much emphasis among the elite (us =) on adding features to the core as opposed to library modules, IMO. Related is the fact that much 'cutting-edge' work in Perl is written in Perl, while most of the cutting edge stuff in Pythonia is done in C. Some of that relates to
*Yes*. That's mostly why I've been drifting away from python-dev, too; the core is becoming more and more dull, the new features are more and more esoteric, and the more interesting action is in Python-based applications and libraries. As a bonus, if I work on a standalone package, I don't need to worry if a change is going to screw up the X thousands of Python users; only the much smaller pool of users of the package is at risk, and it's easier to decide to break things or provide backwards compatibility.
new keywords, for example. Still, there is room for exploration and prototyping there which we don't have such easy access to.
Tools/compiler lets you try out language modifications, though, so it's equally possible to do that with Python (witness PTL). We just don't do that very much, that's all. --amk
At 03:07 PM 8/22/2001 -0400, Andrew Kuchling wrote:
On Wed, Aug 22, 2001 at 11:44:36AM -0700, David Ascher wrote:
which would automatically translate 95% of Perl5 code to Perl6: "If we're smart enough to write Perl5, we can do this". I think it glosses
<snicker> "We let our code base deteroriate into an incomprehensible mess of code, and damn it, we can do it again!"
Now, now, let's not throw stones. :)
*Yes*. That's mostly why I've been drifting away from python-dev, too; the core is becoming more and more dull, the new features are more and more esoteric, and the more interesting action is in Python-based applications and libraries. As a bonus, if I work on a standalone package, I don't need to worry if a change is going to screw up the X thousands of Python users; only the much smaller pool of users of the package is at risk, and it's easier to decide to break things or provide backwards compatibility.
Is this a bad thing, though? C's not changed much in the past decade or two, but look at how much more canned functionality's available now than in, say, 1980. (Heck, add Perl, Python, and Ruby to the list of C's canned functionality if you like) Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk
At 11:44 AM 8/22/2001 -0700, David Ascher wrote:
Jeremy Hylton wrote:
> "PP" == Paul Prescod <paulp@ActiveState.com> writes:
PP> My sense was "Second System Syndrome" but Damian Conway is PP> confident that they don't have that problem.
Isn't that one of the signs of the second system effect? <0.5 wink>
Did he offer any reason for his confidence?
I think the fundamental source of their confidence lay in Randal's answer when I challenged the claim that they would write translators which would automatically translate 95% of Perl5 code to Perl6: "If we're smart enough to write Perl5, we can do this". I think it glosses over a lot of important issues, but this isn't the forum to discuss it.
Randal's confidence is based in some part on the fact that he's watching other people do it, and it's a lot easier to be confident that way. :) I, on the other hand, am nervous as all hell, honestly. (OTOH I feel the same way about raising my kids) Perl 5 to perl 6 isn't that tough though (we do chunks of Python and Ruby to perl 5, after all), and we do have a full-featured perl 5 parser handy. It's as much a task of either reimplementing the perl 5 C-based parser in perl as part of the perl 6 parser front-end (Non-trivial, but not rocket science either) or build a perl 5 bytecode->perl 6 bytecode translator, which is significantly easier. Or just teach the perl 5 parser to spit out a syntax tree, which it pretty much does already.
Perl6 is being defined pretty much as the kitchen sink -- any cool feature from any cool language is going to be supported.
It's designed by committees (30 or so?), on the assumption that integration is a smaller issue than designing each 'feature' well.
Forgive the snippage, but the above two quotes are directly related. Perl 6 the language is *not* being designed by committees, though parts of it look that way from the outside. There's exactly one person responsible for the design of perl 6--Larry. Damian's feeding a lot of interesting ideas to him, but Larry's ultimately responsible for putting together a coherent whole. The committee setup at the beginning was designed to let the people who had an interest in a particular topic get together and flesh out a proposal or four for Larry, but we made no promises that the proposals would see the light of day unchanged in the final language design. The internals design is being handled by a small group of folks, about six, each of us with a different area of competence. We're working things out so we have some good walls between components so they can be implemented semi-separately and in parallel. Part of me would like to have the "design by committee" feel stand until we pull the rabbit out of the hat later, but that might convince people that committee design can actually work in large projects and, well, we have enough of that nonsense around as it is.
I did have a very interesting chat w/ Damian Conway -- he said that Perl6 is already succeeding because it's revitalized the Perl5 community,
FWIW, the success does spread beyond perl. If nothing else, there's a fair amount of "Perl can do that? Well, then, so can *my* language!" feeling amongst folks who feel strongly about languages and such. (Can't imagine who that'd be... :) Perl's doing more, which is prompting folks to do more in other languages, as a tit for tat thing if nothing else. And most any time you add functionality, everybody wins. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk
Dan Sugalski wrote:
...
Perl 5 to perl 6 isn't that tough though (we do chunks of Python and Ruby to perl 5, after all), and we do have a full-featured perl 5 parser handy.
You guys are really focused on the syntax, but to me, the difficult things to handle are subtle *semantic* changes. That's why I said in another message that a two-interpreter system might be the easiest route. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook
At 02:03 PM 8/22/2001 -0700, Paul Prescod wrote:
Dan Sugalski wrote:
...
Perl 5 to perl 6 isn't that tough though (we do chunks of Python and Ruby to perl 5, after all), and we do have a full-featured perl 5 parser handy.
You guys are really focused on the syntax, but to me, the difficult things to handle are subtle *semantic* changes. That's why I said in another message that a two-interpreter system might be the easiest route.
Well, as I've had some Python (and Java) folks happily point out, perl doesn't have any well-defined semantics anyway. :) Seriously, we've a reasonably comprehensive test suite now with perl 5, and a very large code base with expected behavior to draw on to test the conversion. Much of the perl 5->perl 6 transition is strictly syntactic. It's possible that some of perl 5's undefined edge behaviour won't translate, but that'll only be because Larry's decided not to make it translate. Anything else is a bug, and one to be squashed. (We're not losing turing-completeness--perfect execution of past behaviour isn't unattainable) This isn't, after all, the first, or second, or even third time we've done this. The version number's 6 for a reason... Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk
On Wed, Aug 22, 2001 at 05:17:12PM -0400, Dan Sugalski wrote:
Seriously, we've a reasonably comprehensive test suite now with perl 5, and a very large code base with expected behavior to draw on to test the conversion. Much of the perl 5->perl 6 transition is strictly syntactic.
Also don't forget that we have a prototype of Perl 6 which implements pretty much everything that Larry has specified in Apocalypses 1 and 2. It is a patch of nearly 200 lines to the current Perl 5 interpreter. We're not changing *that* drastically, folks.
Simon Cozens wrote:
...
Also don't forget that we have a prototype of Perl 6 which implements pretty much everything that Larry has specified in Apocalypses 1 and 2.
It is a patch of nearly 200 lines to the current Perl 5 interpreter.
We're not changing *that* drastically, folks.
According to Damian there will be generators and a first-class class syntax and method getters/setters and metaclasses and optional static type declarations and ... Larry just hasn't got to the heavy part of the Camel book. :-) -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook
David> It also makes me a little jealous -- Perl manages to be a place David> where significant progress is made in the libraries as distinct David> from the core. In Pythonia, there is too much emphasis among the David> elite (us =) on adding features to the core as opposed to library David> modules, IMO. Related is the fact that much 'cutting-edge' work David> in Perl is written in Perl, while most of the cutting edge stuff David> in Pythonia is done in C. I think there is a lot of emphasis in the Python community on getting the platform "right". That leads to long debates about the correct way to do division, for instance. Also, Python is more platform-independent than Perl, so more work is necessary in the core to make and keep it that way. In addition, check out "man perlguts". The first statement begins This document attempts to describe how to use the Perl API, ... No hedging is necessary in either the Python C API manual or the Python Extending and Embedding manual. In fact, in the Extending and Embedding manual begins It is quite easy to add new built-in modules to Python, if you know how to program in C. So the problem you describe is is clearly Guido fault. He made Python's internals too clean. If he would have obfuscated the internals more, more people would have been drawn to the libraries (or repelled by the internals). ;-) On the flip side, I also think there is a lot of cool stuff going on in the library sector. You don't hear about it as much in part because Python doesn't have an equivalent to CPAN. I'm not talking just about the cataloging part (Vaults of Parnassus), but the build part (distutils) and automatic mirroring/dependency checking/download part (for which Python has, as yet, nothing remotely like it). That makes the barrier to use of libraries (and thus use by a critical mass) not in the core that much higher. There are how many Python Server Pages like things? They probably all have some very nifty features, but tend to be used by rather small pockets of people, at least relative to the overall segment of the Python community doing webish stuff. I'm not entirely sure why that's the case, but I suspect it has to do in part with the barrier to discovering, downloading, and installing these packages. Skip
On Wed, 22 Aug 2001, Skip Montanaro wrote: [...]
libraries (and thus use by a critical mass) not in the core that much higher. There are how many Python Server Pages like things?
#$&$&%. Don't worry; even if we only look at those on CPAN we have more templating systems in Perl than you would ever want to count.
They probably all have some very nifty features, but tend to be used by rather small pockets of people, at least relative to the overall segment of the Python community doing webish stuff. I'm not entirely sure why that's the case, but I suspect it has to do in part with the barrier to discovering, downloading, and installing these packages.
Nah, some things just have to be implemented and reimplemented and reimplemented and reimplemented in slightly different ways. :-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Jeremy Hylton wrote:
"PP" == Paul Prescod <paulp@ActiveState.com> writes:
PP> My sense was "Second System Syndrome" but Damian Conway is PP> confident that they don't have that problem.
Isn't that one of the signs of the second system effect? <0.5 wink>
Did he offer any reason for his confidence?
Nothing directly to that question (we ran out of time). But overall of the Perl guys said things like: a) we're got a bunch smart people working on it (Larry, Damian, Dan, etc.) b) everything we're doing has been done somewhere before so it isn't research (e.g. generators, proper exception handling, decent OO syntax, etc.) c) Perl 5 is a pretty complex system and people of similar caliber built that so why should Perl 6 be any different d) Perl 6's implementation will be so much cleaner than Perl 5's that integration of parts will be a lot easier. e) we've set up all of these working groups to parallelize development and that will help alot too. http://www.perl.com/pub/a/2000/09/perl6mail.html I think that they are way too optimistic, but there were a few things I learned that at least hinted in directions of sanity: Perl 5 support may be provided through some sort of dual interpreter model rather than trying to write a single interpreter that supports both. Dual interpreters are pretty well understood (pyperl, jpe, Perl.NET etc.) So "full backwards compatibility" may be possible using that trick. And Damian is trying to talk Larry out of a strict requirement that the Perl compiler be written in Perl. Also, as David just said, you have to remember that Python people have a much higher bar of coherence to jump over than the Perl guys. If they put a bunch of random stuff in the language in a way that didn't really feel right together -- then it would be just like Perl 5 only with more features. Whereas we spend a week debating how the 'yield' keyword should interact with the 'def' keyword. Damian also said that Perl 6 has to be faster than Perl 5 or nobody will use it. Neil Bauman asked him why Perl wasn't being written in Perl (Neil's opinion is that Perl is literally the greatest language ever created). Damian responded with a great quote: "Performance. If Performance wasn't an issue, I'd probably write Perl 6 in Python or something like it with wonderfully beautiful OO abstractions and it would run like a dog." -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook
My sense was "Second System Syndrome" but Damian Conway is confident that they don't have that problem.
Yeah, right. It has second system syndrome written all over it. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
At 03:38 PM 8/22/2001 -0400, Guido van Rossum wrote:
My sense was "Second System Syndrome" but Damian Conway is confident that they don't have that problem.
Yeah, right. It has second system syndrome written all over it. :-)
You underestimate the amount of black-hearted cynicism we can muster. ;-P Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk
"Paul" == Paul Prescod <paulp@ActiveState.com> writes:
Paul> Also, every time we'd point to a feature of Python (OO Paul> syntax, exception handling, generators, *) that was clearly Paul> better than Perl, Randal claimed it was already slated to be Paul> fixed for Perl 6. We suggested he print t-shirts with that Paul> refrain. The funny thing is, you can make it to almost rhyme (enough for a pop song at least... you could do a filk on that, maybe). "Slated to be fixed / in Perl 6". ;-) Bye, J PS: Do I have to mention I'm behind in my email? ^___^ PPS: I don't have any SF-fandom and/or filking experience... I don't even know if I used the term correctly (do you call such a song a "filk"?). But I think the meaning is clear... -- Jürgen A. Erhard (juergen.erhard@gmx.net, jae@users.sf.net) MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html Life's Better Without Braces (http://www.python.org) Comes in two sizes: huge and Oh-My-God.
participants (10)
-
"Jürgen A. Erhard" -
Andrew Kuchling -
Ask Bjoern Hansen -
Dan Sugalski -
David Ascher -
Guido van Rossum -
Jeremy Hylton -
Paul Prescod -
Simon Cozens -
Skip Montanaro