Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Guido and Bruce Eckel Discuss Python 3000

CmdrTaco posted more than 7 years ago | from the guido-or-eckel-which-is-a-funnier-name-discuss dept.

Programming 305

Phoe6 writes "Leading author and programmer, Bruce Eckel, posted some of his concerns on Python 3000 stating that the Python community is failing to address some of the important issues with this major, backward incompatible release. Problems he mentions are concurrency support on multi-core CPUs, easy deployment support, and a standardized user interface, amongst others. He expresses his dissatisfaction at the post titled "Python 3K or Python 2.9?. Guido van Rossum addresses the concerns in a very pragmatic way with his response to Bruce Eckel and calls for more developers to contribute to Python to improve it further. Bruce Eckel concludes with his thoughts that he wants his favorite language to be better with his reply to Guido's reply."

Sorry! There are no comments related to the filter you selected.

Bruce, Just a Make a New Language Then (2, Interesting)

tjstork (137384) | more than 7 years ago | (#20625757)

I just don't see a reason for this conflict with Guido. Just make a new language, if you want something incompatible, but don't call it Python. Call it Anaconda or something. Or even Garter. Then you can do what you want. If you think you are better than Guido, then get typing, and prove it!

Re:Bruce, Just a Make a New Language Then (3, Insightful)

Aladrin (926209) | more than 7 years ago | (#20625847)

There's 2 sides to that, though.

While I agree, if he wants something that's fundamentally incompatible, but wants to still call it Python, that's silly.

On the other hand, they're saying 'We need more devs to work on Python' and pushing people away that -care- is exactly the opposite of that. If they want new devs, they'd better be resigned to the fact that the newcomers WILL have a different vision, just as this guy does. Finding code-slaves that will do everything you want exactly as it always has been is nearly impossible. You have to pay people to make them go through pain like that. (Coding in someone else's style is just as hard as painting in someone else's... Initially it's almost impossibly hard, and it gets easier with time... And there's always the alternative of working on something else without all that pain.)

Re:Bruce, Just a Make a New Language Then (-1, Troll)

Anonymous Coward | more than 7 years ago | (#20626107)

Python 3000 is fundamentally incompatible with the current Python, retard.

Re:Bruce, Just a Make a New Language Then (3, Insightful)

drgonzo59 (747139) | more than 7 years ago | (#20626167)

Finding code-slaves that will do everything you want exactly as it always has been is nearly impossible.

Good point! Managing developers is hard enough in a company where the devs are paid. Managing volunteers is much, much harder. I strongly believe that half of the success of many open source projects is not the brilliant ideas or the super cool code, but the personality of the lead developer. Linus and Guido have proven to be such personalities that managed to galvanize hoards of developers around them. That is quite impressive. How many managers out there would be able retain employees without any pay?

One distinctive feature of these open source project leaders is that they have to act like assholes sometimes. I proves that they are tough, have a vision and won't budge. At first it seems counter-intuitive that being disagreeable will accomplish more but it works because even if it pushes one developer way, it might attract others or make the ones who are left work harder. It's like a medieval army. Decimating 1% of the army is worth it because it will make the other %99 percent work harder.

Re:Bruce, Just a Make a New Language Then (1)

canuck57 (662392) | more than 7 years ago | (#20625901)

Anaconda is already in use.

I was thinking SAP, "Simply another Python". Oops, that is taken too.

Re:Bruce, Just a Make a New Language Then (4, Funny)

DigitalSorceress (156609) | more than 7 years ago | (#20626069)

Of course, since Python was named after Monty Python's Flying Circus, maybe it should be one of these:

  • Gumby
  • Nudge
  • Ni
  • Creosote
  • UnladenSwallow
  • Albatros
  • DeadParrot
  • CheeseShop
  • LiverDonor
  • CrimsonPermanentAssurance
  • AndNowForSomethingCompletelyDifferent
  • Spamalot
  • WhatsAllThisThen
  • NudgeNudge
  • Monty
  • KillerRabbit
  • Tim
  • Lumberjack
  • JudeanPeoplesFront
  • Gourd
  • Herring
  • Shrubbery
  • HungarianPhrasebook
  • Jabberwocky

Something along those lines anyway

Re:Bruce, Just a Make a New Language Then (3, Funny)

hey! (33014) | more than 7 years ago | (#20626173)

That's not right; you need to name the language after a comedy troupe or show. Then famous bits from that can be used to name features or releases.

So, Bruce's Python derived language could be called SNL (Selfless Notation Language). Libraries could have names like "Bassomatic" (XML processing) or "Cowbell" (Multimedia types).

Re:Bruce, Just a Make a New Language Then (1)

Anonymous Brave Guy (457657) | more than 7 years ago | (#20626615)

Surely we should first rename what we've already got to ExParrot, implying that has passed on, is no more, has ceased to be, has gone to meet its maker, etc. Then we'll be free to call its replacement whatever we like. :-)

Re:Bruce, Just a Make a New Language Then (1)

DohnJoe (900898) | more than 7 years ago | (#20626957)

please, don't be such a troll. There's no conflict here, simply someone voicing his opinions about the new python version. It's his favorite language and he'd like to see it become even better.

Just make a new language, if you want something incompatible
His point is that, since Python 3000 will be incompatible with the previous versions, this is the time to make some big changes which are currently not planned.

Re:Bruce, Just a Make a New Language Then (2, Insightful)

HiThere (15173) | more than 7 years ago | (#20627267)

Nah, he's already said he likes Ruby, so if Python won't go where he wants he could choose dRuby (distributed Ruby). He wants Python to do it because he's more productive in Python. That's a good reason.

Also, his main goal, changing the language to be more productive on multi-processor systems, is an extermely valid one in a "design for the future" sense. Right now it makes marginal sense, but multi-core & multi-processor systems are becoming more common...and the predictions is the trend will not only continue but intensify.

OTOH, I've seen arguments that a data-flow architecture is inherently better suited for that environment, and I've seen at least one decent language to program in that was data-flow. (Prograf. It showed up for the Apple][ lc, which only had one processor and not threading capability to speak of. It died attempting to transition to MSWind95. It had problems as well as a lot of promise.)

Perhaps Python could add a dataFlow library? The library would need to be coded in C or some such (C is traditional for Python libraries). Perhaps it would need to be an "along side" langauge, like Pyrex. That would tend to have the problem of never having the syntax match that of Python...quite, but there might be compensatory advantages.

At all events, I'm not sure HOW the problem should be solved, merely that it NEEDS to be solved. And this is the reasonable time to address any necessary changes.

P.S.: I also agree that threads, and processes that are handled like threads, are an inappropriate solution. This doesn't mean that I know what the best solution is, merely what it isn't.

N.B.: This is a more than trivial problem, because of all the different levels of parallelism that are out there. Some of them don't HAVE any shared ram. (Think computer clusters.) Some of them have LOTS of shared RAM (think multi-core machines). Some don't share cache ram, but share system ram (multi-processor). And a good solution will need to handle these cases transparently. When you write on one system, you can't be expected to know the environment in which you'll be running. (Perhaps clustered computers could be split out to be handled separately. Those who are running computer clusters are still expected to be knowledgeable at the hardware level.)

Python (-1, Flamebait)

Bastard of Subhumani (827601) | more than 7 years ago | (#20625787)

That's the one where the control structures are all invisible, right? I'll give it a miss, thanks all the same.

Invisible+Control+Structures (1)

Peaker (72084) | more than 7 years ago | (#20626637)

{
        Yeah,+I+just+hate+it+when+those+folks+think+that+white+on+white+can+be+readable;
}
{
        Or+that+positioning+text+properly+is+the+correct+way+to+make+it+parsable+by+humans;
}

Oh wait, this piece of text is a bit more readable.

Isn't it? :-)

Re:Python (2, Funny)

An Onerous Coward (222037) | more than 7 years ago | (#20627005)

This has been a public service announcement from the Society for the Preservation of Curly Braces.

With a song and a dance (3, Funny)

SEWilco (27983) | more than 7 years ago | (#20625805)

Shouldn't Python 3000 include a giant animated foot and silhouettes of the audience cracking jokes?

Solved problems (1)

Watson Ladd (955755) | more than 7 years ago | (#20625813)

Python, meet Haskell and Erlang.

Re:Solved problems (4, Interesting)

SanityInAnarchy (655584) | more than 7 years ago | (#20626837)

It's not even an issue of better support for concurrency in the language itself.

Personally, I like some of the ideas of Python better than Haskell and Erlang. There have been some very good ways of doing multithreading, even massive multithreading (see Stackless, some of which is now back in the main Python), and making it natural, even with an imperative style of programming. Some implementations (again, see Stackless) make threads so lightweight that you can spawn thousands without being concerned about performance, and the structures used make it natural to do that without any kind of locking issues -- sometimes, without explicit locks at all.

The problem is not with python, the language. It's with python, the interpreter, and all the associated C modules, embedded versions, etc, not to mention Python programs that might assume the same behavior.

Specifically, it's the Global Interpreter Lock. The GIL is the most retarded move I've ever seen in a language. Basically, Python said "We don't want to make the Python interpreter too complicated, so we're going to deliberately remove multicore support." They even support real OS threads, but only one Python instruction may be executed at a time. Which is fucking stupid.

There are a lot of really good things in Python. I'd like to be able to write a good, modern game with Python, but if you figure it may be half as fast as C already, I'm not going to lose another 50% speed because it can't use both cores. (Yes, psyco can make it MUCH faster, close to C. But, psyco doesn't work on 64-bit, which is another kick in the balls for performance.)

Re:Solved problems (1)

ubernostrum (219442) | more than 7 years ago | (#20626975)

Specifically, it's the Global Interpreter Lock. The GIL is the most retarded move I've ever seen in a language. Basically, Python said "We don't want to make the Python interpreter too complicated, so we're going to deliberately remove multicore support." They even support real OS threads, but only one Python instruction may be executed at a time. Which is fucking stupid.

Python has multicore support; it's called "spawn a process".

Down the road when you have, say, 200 cores, do you really want to be dealing with sharing data in memory between tens or hundreds of thousands of threads spread out over them? Having a program run as a single process with huge numbers of threads -- as practiced by the Java world and egged on by people who don't know any better -- is largely a hack designed to deal with running on operating systems which, at the time, didn't have true multitasking. Seeing as that's not so much of a problem these days, and seeing as how there are very good concurrency models based around lightweight IPC, do we really want languages to be chaining themselves to it?

Re:Solved problems (1)

GooberToo (74388) | more than 7 years ago | (#20627251)

I agree, in this day and age, not having a plug to remove the GIL is beyond stupid.

It is worth pointing out that the situation isn't as bad as you imply as multi-core support most definitely has not been removed. Threading works great when python is I/O bound. Anytime python is outside of the interpretor handling an I/O operation, the GIL is released and allows another thread to execute. Threads which are executing inside the interpretor, continue to run regardless of the GIL's state. CPU bound tasks, on the other hand, essentially means python is single threaded unless your work is being done outside of the interpretor, which likely means there is no point in writing it in python.

To add insult to injury, python's process model sucks so if you want to go the fork model, things which should be easy in a high level language like python are as much a pain as they are in C, or almost so. Thus ultimately means if I have a need to take advantage of multiple cores and CPU bound, you're probably better off writing it in C/C++ than python. If on the other hand, I'm IO bound, and threading is desired, python is still attractive. In fact, python is very attractive for network servers.

So yes, the GIL is brain dead in this day and age, and will continue to become even dumber as days roll by, but threading + multi-core is not completely without merit in python.

Re:Solved problems (1)

ubernostrum (219442) | more than 7 years ago | (#20627149)

Python, meet Haskell and Erlang.

One thing I like about Python is that it's not ashamed to steal good features from other languages. Even better, it usually makes them easier to use or gives them nicer syntax. So I'm OK with this. But I feel it's necessary to point out a couple problems with your thesis here:

Erlang is cool and all, but libraries are basically a dead end at this point. There are too many things missing that you have to go implement on your own, and if they don't catch up soon they're going to realize that other languages which already have great libraries available have nicked all the cool features.

Haskell.... is a mess. When you can write non-trivial programs in Haskell without needing a post-graduate degree in category theory, I'll take another look, but right now I read Haskell tutorials and I keep expecting Geordi to call up from Engineering and tell me I need to reconfigure the phase emitters for an inverse tachyon pulse; all of the Haskell documentation beyond extremely basic things basically consists of technobabble right now.

Python2Perl? (-1, Troll)

Doc Ruby (173196) | more than 7 years ago | (#20625843)

I like Perl. Is there a tool that converts Python scripts to Perl, or compiles them into the opcodes that Perl's interpreter actually executes? That could let Python scripts run on lots of other machines, possibly avoiding all those architecture limitations that the Perl engine has already solved.

Re:Python2Perl? (0)

afd8856 (700296) | more than 7 years ago | (#20626031)

What crack are you on? Where's Perl on JVM, or on DLR, btw?

Re:Python2Perl? (-1, Flamebait)

Doc Ruby (173196) | more than 7 years ago | (#20626123)

I'll do the stupid thing first

Perl has been compiling scripts to intermediary interpreted code since the beginning. You know nothing. Just how to do the stupid thing.
Shut the fuck up, asshole.

Re:Python2Perl? (1)

k8to (9046) | more than 7 years ago | (#20626649)

That was pretty cool the way you absolutely did not answer the question.

Various BASIC implementations had an intermediary representation. It's nothing to crow about, on its own. Sure the Perl implementation is pretty performant. It's a decent piece of work, but it's nothing desirable as a *target platform* for other code tools. It doesn't have some endless list of hardware it magically works on, it's just a C-implemented runtime you compile in different places. Thus, the idea of specially targetting it as a runtime is kinda loopy, when there *are* very widely deployed runtimes which go far beyond the "compile it you fool" level. The Java VM is the foremost among these.

PArrot (1)

goombah99 (560566) | more than 7 years ago | (#20626247)

I like Perl. Is there a tool that converts Python scripts to Perl, or compiles them into the opcodes that Perl's interpreter actually executes? That could let Python scripts run on lots of other machines, possibly avoiding all those architecture limitations that the Perl engine has already solved.
Isn't that exactly what Parrot was supposed to be about? Even the name was chosen to hint at monty python.

Re:PArrot (2, Funny)

zerblat (785) | more than 7 years ago | (#20626897)

Ah, you mean the Norwegian Blue? I don't know. Looks dead to me. Of course, 'e might just be resting. Beautiful plumage, though.

Re:Python2Perl? (1)

jma05 (897351) | more than 7 years ago | (#20626397)

> I like Perl. Is there a tool that converts Python scripts to Perl, or compiles them into the opcodes that Perl's interpreter actually executes? That could let Python scripts run on lots of other machines, possibly avoiding all those architecture limitations that the Perl engine has already solved.

There are plenty of ways to make Python and Perl talk to each other but there is NO tool that compiles either to each others byte code directly. You can embed the interpreters of each other. Inline::Python and PyPerl come to mind, not including cross language communication as in COM, CORBA etc. Of course, this means that you will still need to use the other interpreter but you could distribute that yourself. But all that is often not worth it for some minute advantages that are gained except as an interim solution.

staying with an old version -- how? (4, Interesting)

bcrowell (177657) | more than 7 years ago | (#20625871)

One thing I don't understand about Eckel's original article is that he says breaking compatibility isn't a big deal, because the programmers who don't want to use the new version will just stay with the old one. How does that work for the users? Do they (a) end up having to pick which version of the language to install on their machine, and lose the ability to run half the world's python software, (b) have to install multiple versions of python on their machine, or (c) ??? Eckel is comparing with Java, but since Java is a compiled language, it's much less of an issue; syntactical changes don't affect the end user who just wants to run the code. How would python handle this? Perl 6, for instance, will automatically detect if the code you're running is perl 5, and will run it correctly in a compatibility mode.

Re:staying with an old version -- how? (5, Informative)

Niten (201835) | more than 7 years ago | (#20626075)

You'd typically install multiple versions of python on the same machine. On Unix-like systems each Python version's executable will be named in the manner of python2.4, python2.5, and so on, with a symbolic link from /path/python to (usually) the newest version. Scripts can call for a specific version of Python by starting with a hash-bang line like #!/usr/bin/env python2.5.

Many operating systems facilitate this scheme by offering independent packages for different versions of Python. In particular, on Debian Etch the user can choose to install any of the python2.3, python2.4, and python2.5 packages, then use update-alternatives(8) to switch the system default between the three.

Re:staying with an old version -- how? (1)

afd8856 (700296) | more than 7 years ago | (#20626115)

Even more, on Ubuntu (but I think also on Debian), there's the pycentral folder in /usr/share, where folders (software) can be installed that provide python packages for several python versions.

Re:staying with an old version -- how? (1)

bcrowell (177657) | more than 7 years ago | (#20626551)

You'd typically install multiple versions of python on the same machine. On Unix-like systems each Python version's executable will be named in the manner of python2.4, python2.5, and so on, with a symbolic link from /path/python to (usually) the newest version. Scripts can call for a specific version of Python by starting with a hash-bang line like #!/usr/bin/env python2.5.
Wow, they break compatibility with every dot release? That sounds crazy to me. It means you have to have a ton of versions of the languages installed (I checked, and I have 3 versions of python installed on my ubuntu box), and I would think it would produce huge problems with libraries. What if you write an open-source library using python 2.4, it's done, it's solid and debugged -- then python 2.5 comes out, and programmers start complaining because they can't use it with their python 2.5 projects. Are you just expected to keep on fiddling with your code for the rest of your life, whenever a new dot-release of python comes out? And you also presumably end up maintaining the old versions of your library as well, since some people are depending on those...? Ouch.

Re:staying with an old version -- how? (1)

Chandon Seldon (43083) | more than 7 years ago | (#20626761)

Are you just expected to keep on fiddling with your code for the rest of your life, whenever a new dot-release of python comes out?

What? You thought you could just write software and then it would work forever?

It'd be great if the world worked like that, but it never does. People are always making incompatible changes somewhere (even if they're just obvious bug fixes), and so software always needs to be maintained to keep up with the platform it's written for. This is one of the key practical advantages of "open source" software - the person who keeps a program up to date can be different from the person who initially wrote it.

Re:staying with an old version -- how? (1)

creimer (824291) | more than 7 years ago | (#20626101)

It'll be like the current situation with PHP. PHP4 and PHP5 been out for ages, but only recently has the death knell for PHP4 been announced. The fun comes when your development system has the latest version but your target server has the previous version. You quickly become expert in compromising hacks.

Compiled type-safe python (3, Interesting)

goombah99 (560566) | more than 7 years ago | (#20626339)

As long as they are going to break things here's my wish list for python. Make it possible for a compiler to compile it. Yes I realize that's essentially impossible for a dynamic language that does not enforce types in the function prototypes.

However, it could be done like this. First recognize that nearly all uses of python do not take any advantage of the dynamic typing, and nearly all calls to functions happen with arguments whose type is not varying. Thus why not have a mechanism, an optional one, that could hint at the expected typing for a function and its args. I realize there are ways with "decorators" to add type checking, but that's not the point. I'm talking about type hinting. The reason for this would be to allow a compiler to examine the code, read the hints, and then compile the code or translate it to C++.

The problem with existing python accelerators is that they bend overbackwards to avoid stepping on the dynamic typing. Why not allow the user to forego that if they want to and have static typing if they want to go to the effort of indicating it.

Re:Compiled type-safe python (1, Funny)

Anonymous Coward | more than 7 years ago | (#20626413)

Make it possible for a compiler to compile it. Yes I realize that's essentially impossible for a dynamic language that does not enforce types in the function prototypes.

I see someone's never heard of Lisp.

Re:staying with an old version -- how? (-1)

Anonymous Coward | more than 7 years ago | (#20626493)

Yes, and I understand Perl 7 will automatically correct syntax errors!
Don't get me started on Perl 8. Sweet, sweet stuff.

documentation (2, Insightful)

Anonymous Coward | more than 7 years ago | (#20625963)

If they really want to help Python, build some online documentation that doesn't suck donkey balls. Seriously, I've never had more trouble learning a language than with Python. I have to go google it, because every site is missing info, so you have to put them all together. Does anyone know of a site with ALL the info, that lists ALL the methods in ALL the classes along with what those methods are expecting? Because I sure as hell could never find anything like that. Learn from PHP guys, the reason PHP took off so fast was because the php.net website kicks royal ass as far as documentation and you can learn it quickly. Just my 2 bits.

Re:documentation (1)

afd8856 (700296) | more than 7 years ago | (#20626061)

I used to think something along these lines as well, when I moved from php to python, long time ago. But now it's really not an issue if you download the Python CHM help file and either use its index or navigate the Library Modules section. Also, I used to like that the php help section on the site has comments with code and everything, but looking back, these just really promote stupid recipes, with stupid tricks, full of bugs and insecurities. My 2 (euro)cents.

Re:documentation (4, Interesting)

Niten (201835) | more than 7 years ago | (#20626171)

Huh. One of the things that really attracted me to Python was the (perceived) quality of the Web documentation. The Python Tutorial [python.org] and Python Reference Manual [python.org] are very complete and provide an excellent high-level overview of the language, something which can be rather difficult to come across in, for example, the land of Perl. Granted, the Library Reference [python.org] could be stronger, but I can still usually find what I need in there; and if not, it's easy enough to invoke dir() and view the __doc__ string on any objects of interest from Python's command line.

I guess it's just a matter of personal taste. But for what it's worth, I found it much easer to pick up Python without resorting to any third-party books or reference materials than to start fresh with either Ruby or Perl.

Re:documentation (1)

TheLink (130905) | more than 7 years ago | (#20627225)

I personally found the perlfaq(s) and the various other perl manpages (e.g. perlipc) a lot more useful than docs for practically any other programming language I've encountered.

The syntax and "Computer Science/Academic style description" of a language are not usually the most difficult bits (there are some exceptions of course ;) ). It's the nitty gritty details in the perlfaqs and similar that I find more useful.

I mean, after reading "formal/academic" docs I'd know how to do "Hello World", "fibonacci", etc in the language but how about stuff that doesn't look like someone's CS homework ;)?

e.g.
Signal handling: "Handling the SIGHUP Signal in Daemons", "How do I avoid zombies on a Unix system?"
Or making diagnostics easier (esp for others):
"How do I tell the difference between errors from the shell and perl?"
Or:
"How do I do fancy stuff with the keyboard/screen/mouse"
"How do I use an SQL database?"

man perltoc for more. A lot of stuff covered and probably already included on the system if you're running a typical Linux distro or FreeBSD.

Some of the stuff covered is not so easy to find/figure out for other languages.

Re:documentation (2, Insightful)

psavo (162634) | more than 7 years ago | (#20626179)

i dunno, every piece of documentation is just a starting point. I only use docs.python.org to find a suitable module and then just look around it in IPython shell (import module; module. etc.).

As for PHP.net, it's full of buggy, halfassed examples written by morons and more often push you wrong way than not.

Re:documentation (4, Informative)

Waffle Iron (339739) | more than 7 years ago | (#20626205)

Does anyone know of a site with ALL the info, that lists ALL the methods in ALL the classes along with what those methods are expecting?
/usr/share/doc/python/html/lib/lib.html

searching the online docs (1)

goombah99 (560566) | more than 7 years ago | (#20626439)

While python org has documentation, python documentation lacks three critical aspects.

1) searching and finding only relevant results. When I don't know exactly what I'm looking for, say how to parse an input string to numerical variables, and try to search python.org I get all kinds of crap at the top of my search. Discussions, posts, Peps, and deprecated crap. There ought to be a way to search for things relevant to the current python commands.

2) documetnation that teaches. Too often when I find the documentation of a method it's just a terse self-referential explanation and a list of args. No understanding is returned. If you want to see doucmentation that explains how to use a function look at Perl's man pages. There commands are explained.

3) local documentation. Again I point to perl's man pages as the right balance between compactness, richness, and completeness.

Re:searching the online docs (0)

Anonymous Coward | more than 7 years ago | (#20626519)

Thank you for clarifying my for mentioned frustrations :)
You put it much better than I did.

Re:documentation (1)

Cheesey (70139) | more than 7 years ago | (#20626483)

That's a very unusual complaint about Python, which has great documentation. http://docs.python.org/ [python.org] has info about everything bundled with Python (this is big -- "batteries included"). You can also get help from the Python interpreter by calling the built-in help() function, which takes a module, class or method name as a parameter. help() also works for many third party Python extensions.

I am surprised that none of your searches took you to docs.python.org. But perhaps you were using lots of third party extensions with their own documentation.

Re:documentation (2, Insightful)

jadavis (473492) | more than 7 years ago | (#20626817)

If they really want to help Python, build some online documentation that [isn't bad]

There are a few under-documented libraries that I've run into before, but largely I've been happy with the python docs.

I could swear you were talking about Ruby, because that's exactly the way I feel about Ruby (a language I love, but the docs are disorganized, decentralized, and generally poor).

Re:documentation (1)

rg3 (858575) | more than 7 years ago | (#20627129)

It is insulting that you say that, and you deserve being modded down. I started learning Python with the official tutorial, which is completely clear and exposes you all the language features in an afternoon. There is also a module index that contains the documentation for the different modules, exposing the objects, functions and constants from every module, as well as a list of modules. There's the library reference, that exposes all the modules (again, grouped by topic), all the built-in functions, data types and operations, etc. There is also a document describing the syntax in detail. There is also a document explaining how to embed and extend Python. Complain about its syntax, the way it does some things. Whatever you like to whine about. However, the Python documentation is excellent. No discussion allowed, coward.

http://www.python.org/doc/ [python.org]

losing the print statement (4, Interesting)

mathgenius (526070) | more than 7 years ago | (#20625993)

My main problem with python 3.0 is the loss of the print statement! I have pestered Guido about it (including booing his talk on python3000 at europython this year) and, he said "well i brought this up last year and nobody seemed to object" and then to me personally "well no other language has a print statement".. I think the dumb simplicity of python's print statement is one of my favourite python things. It makes the language friendly (and I am a pepper-print debugger). As Mr. Hettinger says "you can't break 'hello world!'".

I also think, more generally, that people are in for a world of pain, converting to python 3000. There needs to be tools that are %100 reliable that can convert code from 2.6->3.0. Otherwise, there will just be too much code mass, and it will take a long long time for 3.0 to be accepted. Such a stall is bad news for an OSS project.

Simon.

even odder. (3, Funny)

slashnot007 (576103) | more than 7 years ago | (#20626587)

I'm even more perplexed why Guido is removing the "+" sign. HE says he's reserving it for an unnamed future use. In the mean time using two minus signs in a row is how all additions will be done in python 3000. I'm baffled by this.

Re:losing the print statement (1, Insightful)

Anonymous Coward | more than 7 years ago | (#20626813)

My main problem with python 3.0 is the loss of the print statement!

Why? I was a Python programmer for 3 years, and the print statement was one of the most obvious warts.

I think the dumb simplicity of python's print statement is one of my favourite python things. It makes the language friendly (and I am a pepper-print debugger).

Is print("hello, world") unfriendly? I don't see why. Plus, if you're new to the language, it'll save a lot of explaining later when you ask "Why do I not need parens for print?".

There needs to be tools that are %100 reliable that can convert code from 2.6->3.0.

In general, it's impossible to convert code from one language to another 100% reliably, unless the differences are truly trivial. And if the differences between 2.6 and 3.0 were truly trivial, there'd be no reason to break compatibility and call it "3.0".

Otherwise, there will just be too much code mass, and it will take a long long time for 3.0 to be accepted. Such a stall is bad news for an OSS project.

Oh darn? It's happened before, and they lived. I'm sure Guido would be interested in your ideas on how to run a successful open-source language implementation, 'mathgenius'.

in mother russia (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#20626001)

python codes you!

version number or marketing? (0)

Anonymous Coward | more than 7 years ago | (#20626009)

Usually such a big jump in version number is done in two steps. For example you'd go from 3.1 to 95, and then from 98 to 2000.

Compiled Python 3000? (0)

Anonymous Coward | more than 7 years ago | (#20626013)

I love Python, but it's often just too slow! Based on the profiling I did, it is the interpreted nature of Python that is at fault. What I think would be great is if Python 3000 were to also include a native code compiler. Maybe it could be built off of GCC or LLVM to make the work go faster? In college I had to use OCaml, and it had both a bytecode and a native code compiler, and they were both well supported. OCaml is a lot like Python in many ways, so I think maybe it could be possible to do the same with Python. I would do it, but I just don't have the skills necessary. :( If I wasn't so busy as a nurse, I'd try to learn more about compiler design.

Python++? (3, Funny)

Zackbass (457384) | more than 7 years ago | (#20626041)

Why not just call it Python++? Oh, that's right, Python doesn't do that.

Re:Python++? (1)

Anonymous Brave Guy (457657) | more than 7 years ago | (#20626643)

You want to add something to Python, but only wind up with what you had before anyway? :-/

Decimal point is wrong... (2, Funny)

creimer (824291) | more than 7 years ago | (#20626065)

The python mathematics algorithms must have a bug if they're going from version 2.9 to version 3000.

Just rename interpreter to phyton3 (0)

Anonymous Coward | more than 7 years ago | (#20626077)

... I have the following symlinks:
java13 => /opt/jre13/bin/java
java14 => /opt/jre14/bin/java
java15 => /opt/jre15/bin/java
java16 => /opt/jre16/bin/java
java => java16
Guess what - it is simply perfect.

Syntactic whitespace (0, Troll)

metamatic (202216) | more than 7 years ago | (#20626125)

To anyone else who was curious and potentially interested:

No, they're not fixing the syntactic whitespace problem.

Move along, nothing to see.

Re:Syntactic whitespace (4, Insightful)

Waffle Iron (339739) | more than 7 years ago | (#20626241)

Probably because the syntactic whitespace "problem" only exists in the heads of people who have never used Python.

Re:Syntactic whitespace (1)

Ostsol (960323) | more than 7 years ago | (#20626405)

Yeah, I've never understood why some people have such a problem with Python's use of whitespace. I think that it makes Python great as a language for teaching programming to beginners. Anyone who has had to try and read a student's unindented code will surely sypathize.

Re:Syntactic whitespace (1)

pclminion (145572) | more than 7 years ago | (#20626453)

RIGHT ON THE HEAD. Python is the perfect language for student homework. If they don't indent properly, their code doesn't even WORK.

Re:Syntactic whitespace (1)

metamatic (202216) | more than 7 years ago | (#20626475)

Yeah, and the GIMP UI "problem" only exists in the heads of people who have never used the GIMP.

Re:Syntactic whitespace (1)

Waffle Iron (339739) | more than 7 years ago | (#20626915)

Nope, I've used the GIMP a good bit, and its UI problems are real.

In theory, it seems like significant whitespace in syntax would be a problem. In practice, I've never seen any problems with it in the years that I've been using Python. OTOH, I've seen a lot of bugs caused by mishandling the optional C-style "if" blocks in those languages that use them.

Re:Syntactic whitespace (1)

bperkins (12056) | more than 7 years ago | (#20626949)

I've used Python.

The syntactic whitespace is hard to get used to and causes hard to find bugs.

Re:Syntactic whitespace (4, Funny)

ubernostrum (219442) | more than 7 years ago | (#20627021)

The syntactic whitespace is hard to get used to and causes hard to find bugs.

You do know about Python's block delimiter support, right? You can use the block delimiters from any language you like, just prefix them with '#' and Python will handle them automatically.

Re:Syntactic whitespace (1, Funny)

Anonymous Coward | more than 7 years ago | (#20626297)

Meanwhile, those of us who use Python in our work will continue to be productive and prosperous, while I guess you can go back to writing your unbelievably boring "blog". What a loser.

Re:Syntactic whitespace (1)

Ilan Volow (539597) | more than 7 years ago | (#20626471)

Or to look at it another way, they're making sure that the problem of people using their own personal messy indentation style stays fixed.

Flamewars (0)

Anonymous Coward | more than 7 years ago | (#20626967)

I understand that it is inevitable for the same old flamewars to start on slashdot.

But must we give modpoints to idiots?

Re:Syntactic whitespace (1)

marcello_dl (667940) | more than 7 years ago | (#20627161)

They fixed the whitespace problem in a fork:

http://clisp.cons.org/ [cons.org]

Sounds familiar. (2, Funny)

markov_chain (202465) | more than 7 years ago | (#20626135)

Bruce complained that Python3K is not modular enough. Guido, always the pragmatist, and having just watched Reservoir Dogs, retorted that anyone who wants a modular language should get his head examined.

Some guy on the mailing list proposed a new and better syntax, but Guido declined to merge it; he explained that he doesn't trust the new guy as much as Bob, whose Context-Free Syntax (CFS) is going into the next development version (odd-numbered, of course).

Re:Sounds familiar. (4, Interesting)

m2943 (1140797) | more than 7 years ago | (#20626227)

Guido, always the pragmatist, and having just watched Reservoir Dogs, retorted that anyone who wants a modular language should get his head examined.

So why does Python scatter its standard libraries across half a dozen packages? Probably one of the biggest problems beginners have with Python is that they can never remember whether something is in os, os.path, sys, string, re, or whether it's maybe just a method on an object, or maybe it changed in some recent release. And you can't just safely import everything from those packages either.

Re:Sounds familiar. (1)

k8to (9046) | more than 7 years ago | (#20626803)

The problem here is that you are insisting on thinking of these tools by the wrong names. If you remember that python has a stdin file object and then have to hunt around for it, you've done yourself a disservice. The name of this object is sys.stdin.

Just call things by their full names. They're short, they're unambiguous, and they say what they are.

Re:Sounds familiar. (0)

Anonymous Coward | more than 7 years ago | (#20626927)

So why does Python scatter its standard libraries across half a dozen packages?

The Python standard library is actually many dozens of packages [python.org] . If you have a suggestion for a way to improve library design, I'm sure we'd all be happy to hear it.

Probably one of the biggest problems beginners have with Python is that they can never remember whether something is in os, os.path, sys, string, re, or whether it's maybe just a method on an object, or maybe it changed in some recent release.

os / sys: OK, this one is a bit weird (similar to Java's System/Runtime weirdness)
os.path: dealing with paths
re: dealing with regular expressions
string: you basically never need this; it's a holdover from Python 1.something, and string instances now have most of the interesting functionality themselves

And you can't just safely import everything from those packages either.

Sure you can. It'll cause a lot of extra files to be loaded when your program starts, but it won't break anything. Later you can run pylint on your program, to get a list of packages you're not using, and remove those imports.

BS argument (4, Insightful)

henrypijames (669281) | more than 7 years ago | (#20626165)

A lot of what Eckel is saying is basically "Python should be more like other languages" - not because they're better, but because I'm more used to them. Obviously that's totally ridiculous, yet not surprising: If you look at his resume, it seems he's far more familiar with other languages than Python. I seriously doubt his credential - let alone objectiveness - to question Python's design.

both are right, sort of (5, Insightful)

m2943 (1140797) | more than 7 years ago | (#20626197)

Guido is right that Bruce's comments are mostly not core language issues.

But that's also the problem the Python language is fine the way it is; it doesn't need any major overhaul. Before hacking away on P3K, Guido should concentrate on getting things like the UI, the standard libraries, and package management straightened out. Community contributions won't fix those; in fact, community contributions are the source of many of the problems of Python because often, there are multiple, mutually incompatible libraries and tools trying to do the same thing and stepping on each other.

Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.

Mod parent up. (1)

Animats (122034) | more than 7 years ago | (#20626311)

Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.

That says, in one line, what I wrote in a much longer post.

Re:Mod parent up. (1)

sigzero (914876) | more than 7 years ago | (#20626665)

I thought straightening up the libraries was one of the goals of PY3K?

They are both wrong! (2, Interesting)

pigiron (104729) | more than 7 years ago | (#20626251)

The right answer is here: http://newlisp.org/ [newlisp.org]

Re:They are both wrong! (0)

Anonymous Coward | more than 7 years ago | (#20627255)

newLISP is a great little scripting language, though it could be better. I hope that in one of the upcoming releases it gets implicit fixnum->bignum conversion, without the bullshit of using the gmp.lsp library. I also hope (but this time I'm more certain) that the 64-bit builds will use 'long double' instead of 'double' to support larger numbers without the need to use bignums.

Those aren't the real problems with Python (5, Insightful)

Animats (122034) | more than 7 years ago | (#20626279)

Actually, those aren't the real problems with Python. They're not the ones that keep it from, say, replacing Perl.

  • Multicore support is a nonissue. CPython is too slow to need it. It's helpful to distinguish between the Python language, which isn't bad, and the CPython implementation, which is a slow, naive intepreter. CPython is about 60x slower than C. Compare Java, which, with modern just-in-time compilers, is about 2-3x slower than C. What's needed is a Python compiler with some smarts. There's Shed Skin, but it doesn't work yet.

    One side effect of the speed problem is a tendency to try to write C modules to do things that take significant time. Unfortunately, CPython's interface to C is terrible, bug-prone, and changes with each new release.

  • The "dynamic language" thing is overdone. CPython is a demonstration of the fact that if you make everything a dictionary, it's easy to implement a dynamic language. It's also a demonstration of "if the only tool you have is a hammer, everything looks like a nail". Too much time is wasted in Python checking to see if something changed that probably didn't change. You can add or change functions or data of a running object or a running function. From outside the object or functionor thread, even! It's cool! It's l33t! It means you can't have an optimizing compiler. (Well, maybe you could, with one that goes to immense lengths to detect when "something funny" is going on and reworks the code on the fly. Won't be easy to implement.) Those features just don't get used that much, except to patch around bugs in the buggy Python libraries. The troubles with the "global interpreter lock" stem from this problem. The "global interpreter lock" is mostly protecting all those dictionaries which define the program. After all, one thread might want to patch the code in another thread.

    Years ago, LISP hackers used to talk about how great it was that LISP programs could modify themselves while they were running. Few useful programs ever actually did so. Java has a certain amount of dynamism; you can, if you really have to, create Java code from within a program, compile it, and load it. Few programs need more dynamism than that. The Shed Skin implementation imposes some restrictions on dynamism, and they're on the right track.

  • Libraries are someone else's problem. Python is better than Perl as a language, but CPAN is better than Python's Cheese Shop. Many key modules aren't part of the main Python distribution and aren't synchronized with it. Examples are the interfaces to databases like MySQL and the interface to SSL. These lag months or years behind the base system. Modules outside the small "core" are not supported in any coherent way. Each is supported by a developer or two, working in isolation. If they lose interest, the module languishes, and nobody else can change it. This sometimes leads to multiple libraries for the same purpose, each with different bugs, and none good enough to obsolete the others.

The overall effect is that if you try to write something complicated in Python, everything goes along just great until you hit some library bug that can't easily be fixed. Or you discover that you need racks of servers to compensate for the painfully slow implementation.

That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.

Re:Those aren't the real problems with Python (1)

slashnot007 (576103) | more than 7 years ago | (#20626651)

Wow. You nailed it. Those are my feelings exactly. Espeically about Dynamic typing being too much of a good thing since it screwes with optimization.

Python needs to go on a diet (1)

Ilan Volow (539597) | more than 7 years ago | (#20626317)

For python to be healthy in the future, it needs to cut out all the added syntactic sugar bloating the syntax since 2.2 and substitute it with complex XML support.

Re:Python needs to go on a diet (0)

Anonymous Coward | more than 7 years ago | (#20627131)

XML support would be a library issue. Syntactic sugar bloat? What, you mean descriptors. Woah! All that bloat. Yeah it's amazing how Python can still do anything with one whole character taking on a new meaning.

Regarding GUI (3, Interesting)

Brandybuck (704397) | more than 7 years ago | (#20626409)

Regarding the GUI: don't.

This is a language, so keep it as such. I realize it's hard to market a language without a rich set of standardized libraries, but the UI should be an exception. This is an area where the technology is slowly but constantly changing. In addition, GUIs tend to have somewhat "religious" supporters. Also, as Bruce mentioned, all of the toolkits have their advantages and disadvantages. One "disadvantage" they all share is a changing API. Nothing stays the same forever. Tying your language standard to a third party API is problematic.

One language tried to do this (Java), but it's original GUI was universally reviled, and it's current "official" GUI (Swing) is competing with an extremely popular third party solution (SWT), and another third party solution (Jambi) is starting to gain enthusiastic users.

So in my opinion, leave the UI unstandardized.

Why do people pile on Guido (2, Insightful)

pclminion (145572) | more than 7 years ago | (#20626421)

He's not that different from Linus. He does things in ways that some people seem to really dislike. When they complain, he doesn't mind. "Tough cookies." I guess when Linus does it, it's a noble independent spirit, when Guido does it he's being an asshole.

I use Python as a test, actually. Hating the language is okay by me, we've all got tastes. Lucky for you, we don't write our code in Python so you won't suffer. But saying you hate it because of enforced whitespace? That fails your interview, right there. Ohhhh boy. You've got a problem with having to make things line up the way their supposed to? Just wait until you hit some actual PROJECT REQUIREMENTS.

Re:Why do people pile on Guido (-1, Troll)

Anonymous Coward | more than 7 years ago | (#20626631)

saying you hate it because of enforced whitespace? That fails your interview, right there. Ohhhh boy. You've got a problem with having to make things line up the way their supposed to? Just wait until you hit some actual PROJECT REQUIREMENTS.
I hate tabs and anything other than 2 space indentation. My usual response when pushed to adopt stupid indents is to use a single space out of pure malice. I've never been unemployed for longer than 2 days in 15 years, so you can frankly take your precious PROJECT REQUIREMENTS and shove 'em. How's that sound, would I pass your interview process?

Re:Why do people pile on Guido (0)

Anonymous Coward | more than 7 years ago | (#20627081)

You must have been working alone in your basement. I can't imagine anybody would want you on their team. (PS: I'm not the GP)

Strange Guido's reply (3, Insightful)

renoX (11677) | more than 7 years ago | (#20626433)

He said that 'self == whitespace indentation' whereas for me I see that as exactly the oposite:
- using whitespace for indention remove 'visual noise' at the cost of 'language magic'
- using self adds 'visual noise' with the (dubious IMHO) benefit of language 'simplicity'.

IMHO removing self would be a big plus for Python, sure self makes things more explicit but if developers really wanted to use explicit language, they would stay with C instead of using Python, Ruby..

Re:Strange Guido's reply (1)

Simias (953970) | more than 7 years ago | (#20626487)

Or make it optional like "this" in C++, you could fully qualify the name (self.content) or just make it implicit (content).

Re:Strange Guido's reply (4, Interesting)

Cheesey (70139) | more than 7 years ago | (#20626655)

You have touched on a problem with Python that has always annoyed me. It's not "self", but it is one of the reasons why "self" has to be explicitly specified.

The problem is that Python does not distinguish between creating a variable and assigning a new value to an existing variable. This means that scoping doesn't work as well as it should. In particular, you can't do this:

def Parent():
  v = 0
  def Child():
    v += 1
  Child()
because Python cannot tell that the second v is the same as the first. You can access v from the Child() function, but you can't update it. There are ways around this problem, but they are ugly. That's why Python really uses self: so it knows which scope each variable belongs to. And it's a pain. There should be a way to explicitly specify the scope of variables without having to resort to ugly hacks. I am a big fan of Python, but it could be so much better...

Re:Strange Guido's reply (0)

Anonymous Coward | more than 7 years ago | (#20627147)

Actually, no. That's an orthogonal issue altogether, and is being addressed in Python 3000 with the new "nonlocal" keyword. Thus your code would be written as:

def Parent():
    v = 0
    def Child():
        nonlocal v
        v += 1
    Child()

self being explicit is actually pretty amazingly powerful, if slightly rough on the fingers. For example, you can invoke a method from a class on a different object by providing self:

class Foo(object):
    def bar(self):
        print self.x

Foo().bar() automatically supplies self, but let's say you wanted to call Foo.bar on an object of class Jimmy. This is easy:

myjimmy = Jimmy()
Foo.bar(jimmy)

Now inside Foo.bar(), self == myjimmy. Neat!

Re:Strange Guido's reply (1)

renoX (11677) | more than 7 years ago | (#20627247)

Am-I the only one to find that nonlocal is ugly?
Granted, its use should be pretty rare so that's not a big deal.

Myself I would have used Limbo's notation for declaration:
def Parent():
        v := 0 #declaration
        v = 5 #assignment
        def Child():
                v += 1
        Child()

But I know that Pythoners don't like variable declaration..

It's not the langauge, stupid (2, Informative)

Aminion (896851) | more than 7 years ago | (#20626513)

The Python Software Foundation (PSF) needs to realize that there's so much more to a language than the syntax. There needs to be a major effort in making it easier to install, get started with, and deploy Python, and much more advocating and marketing needs to be done. For example, PSF should start campaigning so that web hosting providers support Python out of the box. Why do you think PHP, despite it's obvious drawbacks, is so popular? Because it's ubiquitously supported and requires nil efforts to get started!

It's great that Python is constantly evolving into a cleaner and more competent language, but I fear that the Python 3000 efforts could result in a pyrrhic victory in the war between programming languages because it simply fails to attract enough new people. There's so much that the PSF could do, but there seems to be too much "But that's not our job!"-thinking.

Re:It's not the langauge, stupid (1)

Aminion (896851) | more than 7 years ago | (#20626607)

"langauge"? I spell checked everything besides the subject, so obviously it got misspelled.

Blow my mind. (1)

Verte (1053342) | more than 7 years ago | (#20626611)

Give me multiply indexed arrays and array slicing! that would be something.

Re:Blow my mind. (2, Informative)

slashnot007 (576103) | more than 7 years ago | (#20626715)

Your wish is granted already. import numpy

Significant whitespace (0, Flamebait)

tylersoze (789256) | more than 7 years ago | (#20626735)

Well if one of the incompatibilities is getting rid of the goddamn significant whitespace I'm all behind it. It might even encourage me to give the language a chance. If it weren't for Civ IV I would have never used it for anything. A good slashdot poll would be how many people haven't even bothered with the language because of "the whitespace thing".

Re:Significant whitespace (1)

An Onerous Coward (222037) | more than 7 years ago | (#20627221)

You're right. Another good poll would be "How many people haven't bothered with Java because of the whole VM thing?" Or, "How many people haven't tried LISP because of the whole 'no side effects' thing?" Or "how many people refuse to use C because of the whole compiler thing?" Or "How many people reject Ruby because of the whole 'ability to pass blocks of code as arguments' thing?"

My point is, these things are kind of central to their respective languages. If you truly despise one of these central features, chances are good that there are a dozen other things about the language you won't like either. The Python people could jettison every feature you didn't like, until they finally wound up with a bastardized knockoff of Your Favorite Language. Then you'd end up ignoring Python in favor of Your Favorite Language anyways.

If the whitespace thing is a big deal to you, then either your editor of choice isn't doing anything to help you, or you're just whining that Python isn't exactly the same as YFL.

Yeah, well (2, Informative)

stonecypher (118140) | more than 7 years ago | (#20627027)

Bruce Eckel is looking for Erlang. That's not what Python is for.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?