Comments on: My Vision of Python 3000 — Back To Basics http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/ Just another WordPress weblog Tue, 31 Mar 2009 04:37:44 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Mathieu Fenniak http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-82 Mathieu Fenniak Thu, 21 Sep 2006 14:19:47 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-82 As far as I know, all those packages should be quite compatible with either distribution of Python. As far as I know, all those packages should be quite compatible with either distribution of Python.

]]> By: khebab http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-81 khebab Thu, 21 Sep 2006 14:13:34 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-81 Thanks for the quick response! Last question: Python Enthought seems to come with a lot of scientific packages (SciPy, PIL, etc.), is it the case for the ActiveState package? are those packages compatible between editions? Thanks for the quick response!

Last question: Python Enthought seems to come with a lot of scientific packages (SciPy, PIL, etc.), is it the case for the ActiveState package? are those packages compatible between editions?

]]> By: Mathieu Fenniak http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-80 Mathieu Fenniak Thu, 21 Sep 2006 13:15:18 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-80 Hi Khebab, I've always been a fan of the standard Python distribution from python.org. It can be enhanced for the Windows environment by downloading pywin32 as well. Hi Khebab,

I’ve always been a fan of the standard Python distribution from python.org. It can be enhanced for the Windows environment by downloading pywin32 as well.

]]> By: Khebab http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-79 Khebab Thu, 21 Sep 2006 13:04:18 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-79 Hi there, I'm a Python newbie and I'm wondering what edition of Python I should install: ActiveState Python or Python Enthought? Thanks! Hi there,

I’m a Python newbie and I’m wondering what edition of Python I should install: ActiveState Python or Python Enthought?

Thanks!

]]> By: Cliff Wells http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-78 Cliff Wells Mon, 31 Jul 2006 18:33:34 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-78 I actually have the opposite viewpoint, and yet agree in a rather backwards way: I think Python is too stagnant and yet at the same time, feel that the "features" being added recently are mostly cruft to cover up basic lacking in the language. I've recently come to appreciate the elegance and power expression-based languages (Ruby, Lisp) give their users, and the artificial distinction between statements and expressions in Python has begun to frustrate me. One of the mottos of Python is that "practicality beats purity". The part of me that wants to earn a living certainly agrees with this point. However, the part of me that loves to code disagrees vehemently. I've noticed an overall trend in Python (list comprehensions, decorators, the upcoming ternary operator) to add features that give you some, but not all of the power of an expression-based language. This cruft adds to the size of the language and the amount of syntax and special cases a programmer must hold in his head (that's where I agree with Mathieu). At the same time, they fail to deliver a fraction of the power that *removing* a "feature" of the language would. If I had one wish for Python 3000, it would be to see the arbitrary distinction between statements and expressions removed. I think this could be done in a mostly backwards-compatible way and would improve both the consistency and expressiveness of Python tremendously. And as a side benefit, we could lose a lot of other language "features" that have been crufted on to compensate for this shortcoming. A short time playing with Logix has convinced me that Python has one foot set squarely in the grave at this point. I know plenty of people who have moved to Ruby from Python and yet know of *nobody* migrating the other way. Most of the ones whom I've asked about it cite features such as anonymous code blocks and overall expressiveness (Rails, of course, being another reason, but I think our web framework guys have this in hand). I think that should be a loud and clear alarm in the Python camp. If Python became expression-based it would be far superior to Ruby in every way. I expect Ruby will inspire more (and better) expression-based languages and Python will start to look more and more like FORTRAN with its inflexible statement-oriented syntax. So yes, I'd like to see Python made simpler, but most definitely let's not let it stagnate. I actually have the opposite viewpoint, and yet agree in a rather backwards way: I think Python is too stagnant and yet at the same time, feel that the “features” being added recently are mostly cruft to cover up basic lacking in the language.

I’ve recently come to appreciate the elegance and power expression-based languages (Ruby, Lisp) give their users, and the artificial distinction between statements and expressions in Python has begun to frustrate me.

One of the mottos of Python is that “practicality beats purity”. The part of me that wants to earn a living certainly agrees with this point. However, the part of me that loves to code disagrees vehemently. I’ve noticed an overall trend in Python (list comprehensions, decorators, the upcoming ternary operator) to add features that give you some, but not all of the power of an expression-based language. This cruft adds to the size of the language and the amount of syntax and special cases a programmer must hold in his head (that’s where I agree with Mathieu). At the same time, they fail to deliver a fraction of the power that *removing* a “feature” of the language would.

If I had one wish for Python 3000, it would be to see the arbitrary distinction between statements and expressions removed. I think this could be done in a mostly backwards-compatible way and would improve both the consistency and expressiveness of Python tremendously. And as a side benefit, we could lose a lot of other language “features” that have been crufted on to compensate for this shortcoming.

A short time playing with Logix has convinced me that Python has one foot set squarely in the grave at this point. I know plenty of people who have moved to Ruby from Python and yet know of *nobody* migrating the other way. Most of the ones whom I’ve asked about it cite features such as anonymous code blocks and overall expressiveness (Rails, of course, being another reason, but I think our web framework guys have this in hand). I think that should be a loud and clear alarm in the Python camp. If Python became expression-based it would be far superior to Ruby in every way. I expect Ruby will inspire more (and better) expression-based languages and Python will start to look more and more like FORTRAN with its inflexible statement-oriented syntax.

So yes, I’d like to see Python made simpler, but most definitely let’s not let it stagnate.

]]> By: Mathieu Fenniak’s Weblog » Ever want to unwrite something? http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-77 Mathieu Fenniak’s Weblog » Ever want to unwrite something? Mon, 31 Jul 2006 13:24:28 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-77 [...] In my last post, I kinda ranted about python development. I thought that I was being constructive and presenting a well thought out point-of-view, but it wasn’t really. There were probably some ideas in there somewhere, but I forgot a couple important actions in writing. I did not research the topic of Python 3000 very well, and I did not think about rational reactions to my “arguments”. [...] [...] In my last post, I kinda ranted about python development. I thought that I was being constructive and presenting a well thought out point-of-view, but it wasn’t really. There were probably some ideas in there somewhere, but I forgot a couple important actions in writing. I did not research the topic of Python 3000 very well, and I did not think about rational reactions to my “arguments”. [...]

]]> By: Bob Ippolito http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-76 Bob Ippolito Mon, 17 Jul 2006 22:45:06 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-76 I'm going to have to agree with Pete and David here. If CPython weren't adapting to problems that people are trying to solve, then it would fade away. I'd certainly switch to something else pretty quickly if it were stagnant. I don't know what kind of code you write, but lots of code would be better off (as in shorter and more correct) with the "with" statement. Perhaps you just don't understand what it's for. Also, what the heck does this have to do with Python 3000? The majority of the 3000 effort is to make the language smaller and more consistent... throwing out deprecated stuff that 2.x needs to keep for compatibility. I’m going to have to agree with Pete and David here. If CPython weren’t adapting to problems that people are trying to solve, then it would fade away. I’d certainly switch to something else pretty quickly if it were stagnant.

I don’t know what kind of code you write, but lots of code would be better off (as in shorter and more correct) with the “with” statement. Perhaps you just don’t understand what it’s for.

Also, what the heck does this have to do with Python 3000? The majority of the 3000 effort is to make the language smaller and more consistent… throwing out deprecated stuff that 2.x needs to keep for compatibility.

]]> By: Pete http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-75 Pete Mon, 17 Jul 2006 21:59:29 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-75 I can't agree with most of these points. It sounds like you've been following the Python 3k discussion, so you already know that the point is not brand new features, but more of a chance to drop support for things that should be dropped. You mention how all users have their own needs for the standard library, but the same is true for some of the new features in the python language. Just as nobody benefits from all parts of the standard library, nobody will benefit from all language features. The point is that there are problems out there, especially as people push computers and languages into new domains. Several of the new features you say you don't care about or need are going to be big wins for me and the code that I write. I can't wait for the new 2.5 features to help out my code. Looking forward to 2.6. I can’t agree with most of these points. It sounds like you’ve been following the Python 3k discussion, so you already know that the point is not brand new features, but more of a chance to drop support for things that should be dropped.

You mention how all users have their own needs for the standard library, but the same is true for some of the new features in the python language. Just as nobody benefits from all parts of the standard library, nobody will benefit from all language features.

The point is that there are problems out there, especially as people push computers and languages into new domains. Several of the new features you say you don’t care about or need are going to be big wins for me and the code that I write.

I can’t wait for the new 2.5 features to help out my code. Looking forward to 2.6.

]]> By: David Goodger http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-74 David Goodger Mon, 17 Jul 2006 21:01:06 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-74 There have been people saying this since Python 1.5, and probably earlier. If Guido and the python-dev team thought this way, Python would be a dead language. Anyone who thinks Python version X.Y is complete has an option (for their own code, at least): don't upgrade. When you're in the very-high-level open source programming language business, it's evolve or die. There have been people saying this since Python 1.5, and probably earlier.
If Guido and the python-dev team thought this way, Python would be a dead language.
Anyone who thinks Python version X.Y is complete has an option (for their own code, at least): don’t upgrade.
When you’re in the very-high-level open source programming language business, it’s evolve or die.

]]> By: Mathieu Fenniak http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/comment-page-1/#comment-73 Mathieu Fenniak Mon, 17 Jul 2006 20:31:48 +0000 http://mathieu.fenniak.net/my-vision-of-python-3000-back-to-basics/#comment-73 Lawrence, thanks for your feedback. I consider generator expressions to be "new syntax" because code written with them cannot be parsed by an earlier version of the Python compiler. Of course generator expressions are useful, just as list comprehensions are. But I don't consider them to be necessary. "with" being like C#'s "using" is better than being like VB's "with". But I'd still be quite happy programming in Python without it. If I know that a resource needs to be closed (which one assumes I must know if I chose to put it in a 'with'), then I'm quite content to have to call the close method on that object. Lawrence, thanks for your feedback.

I consider generator expressions to be “new syntax” because code written with them cannot be parsed by an earlier version of the Python compiler. Of course generator expressions are useful, just as list comprehensions are. But I don’t consider them to be necessary.

“with” being like C#’s “using” is better than being like VB’s “with”. But I’d still be quite happy programming in Python without it. If I know that a resource needs to be closed (which one assumes I must know if I chose to put it in a ‘with’), then I’m quite content to have to call the close method on that object.

]]>