5 ms·

Complaints around infelicities in the Python stdlib are fair enough - I don't think anyone would defend them, but what can you do? You can't change published AP

by tow21 17y ago

Complaints around infelicities in the Python stdlib are fair enough - I don't think anyone would defend them, but what can you do? You can't change published APIs. Fos most of the rest of his issues, I think Zed's problem is that he thinks there's one obvious answer, but lots of other people would disagree with his one answer. Python tends to be either very opinionated, or very agnostic. Where there's One Way To Do Things, that's what you must do; except where there's obvious disagreement in which case it doesn't bless a single answer. API doc autogeneration; I can guarantee that if anyone came up with a default tool with default output such that "doctool module html_directory" was all you needed (and indeed people have) then there would be widespread, perfectly legitimate, disagreement on any number of choices in the design of it. (Prsonally, I think API doc autogeneration is entirely pointless, and indeed fundamentally the Wrong Thing To Do for most Python libraries. When I come across pages of JavaDoc-ish API documentation, I groan internally and just look at the source instead.)

arohner 17y ago
>Complaints around infelicities in the Python stdlib are fair enough - I don't think anyone would defend them, but what can you do? You can't change published APIs. You're absolutely right, but that doesn't mean Zed isn't on to something. How many different ways are there to open a subshell in python? There's popen, popen2, popen3, popen4 (I think), plus more (subprocess?). Yes, the past can't be changed, but it's still a good idea to stop and ask why there are so many mistakes like this. Why is there a time module, and a date module, and a datetime module, and yet all three are broken? The main question is What factors allowed the stdlib to get so quirky, and what can be done to fix that? Pointing out the stdlib is quirky is the first step in fixing the problem.
- aston 17y ago
  Python 3 intends to fix a lot of the stdlib issues. For example, the subprocess module should obsolete all of the various popens. http://docs.python.org/library/subprocess.html http://docs.python.org/library/subprocess.html
  - dkarl 17y ago
    And subprocess is available in 2.6, too. It looks like a well-designed API and certainly makes it easy to run external filters on data. For example, to get the output of 'tidy -q' on a string s: proc = subprocess.Popen(['tidy', '-q'], stdin=PIPE, stdout=PIPE, stderr=PIPE) (tidyout, tidyerr) = proc.communicate(input=s) if proc.returncode != 0: ...
    - tdavis 17y ago
      Errr, subprocess has been around since 2.4...
- deleted 17y ago
  [deleted]
- stcredzero 17y ago
  If you have a quirky stdlib, this can be a big problem if its source is visible. This can be a tremendous source of bad examples to the community. This happened with the various Smalltalk images -- there was some rather good code, and then there was a lot of procedural/spaghetti code by junior programmers. A lot of it happened to get into places where it would be very visible to other junior programmers. (Database/OR tools.) I think that a lot of this quirky stuff is due to the "uncool" factor of cleaning up such infrastructure level stuff. It's much cooler to be working on a proxy framework that talks to some new protocol. Making sure dates and times work well seems pedestrian. But it is actually tremendously important.
deleted 17y ago
[deleted]
pmjordan 17y ago
Complaints around infelicities in the Python stdlib are fair enough - I don't think anyone would defend them, but what can you do? You can't change published APIs. I was under the impression that Python 3 broke a lot of backwards compatibility, so could they not introduce new APIs with that? Or is that in fact what they did, and Zed is just complaining about 2.x? I apologise if I'm mistaken on this, I've hardly used python at all. (though I keep meaning to learn it so I can finally stop writing bash scripts)
- jmillikin 17y ago
  Python 3 removed old, deprecated APIs, but did not change any existing APIs. Probably the most extreme re-organization was the urllib/urllib2 merger, which was at its core just removing old stuff. Because Python is dynamically typed, the "protocol" of a library is extremely important, and the semantics of existing functions/classes are almost never changed. Of Zed's complaints, I feel that two are misguided (time handling seems quite reasonable to me, and I've never seen an easier documentation system than Sphinx). I think applying the "del" keyword to objects in a container is a mistake in the language, but that's how it was designed, so it probably wouldn't have been changed in the 2 -> 3 transition. It certainly won't be changed now -- the best that can be hoped for is for its use to be discouraged in the documentation. Install/Uninstall of modules is fairly easy, but requires all concerned parties to work together. Otherwise you end up with half-installed, broken modules. There are PEPs in progress to work on this, but it's a social/political problem rather than a technical one. Python's file-manipulation APIs are an ongoing calamity.
  - llimllib 17y ago
    > Python 3 removed old, deprecated APIs, but did not change any existing APIs. This is simply false. Modules were added, renamed, and modified. Module names now conform to pep 8 (Queue -> queue, SocketServer -> socketserver, etc). cPickle, cProfile and cStringIO are now accessible through their non-c counterparts instead of individually. Packages have been grouped - for example the http libraries are now in http.* instead of the top level. Examples of API changes include the removal of sys.maxint and sys.exitfunc and friends, many libraries returning unicode strings instead of byte strings by default, and lots lots more. Consult the "What's new in python 3.0" for a high-level overview: http://docs.python.org/3.0/whatsnew/3.0.html#library-changes http://docs.python.org/3.0/whatsnew/3.0.html#library-changes
rabidgnat 17y ago
"API doc autogeneration; I can guarantee that if anyone came up with a default tool with default output such that "doctool module html_directory" was all you needed (and indeed people have) then there would be widespread, perfectly legitimate, disagreement on any number of choices in the design of it." In my experience, the opposite actually happens. When something is written, people either use it and customize it over time, or they just find something else and say it didn't suit their needs. It's when an extremely useful/general library is PROPOSED that it becomes a huge disagreement. This is, for instance, why C++'s Boost still doesn't have logging or a unified XML library, and won't likely have a garbage collection library before a C++ TR defines the interface: everyone argues over the color of the bikeshed, and the people who try to write the libraries get caught up in infinite microdiscussions over details. Conversely, someone like Linus Torvald's success is that he just makes the things he needs/wants (ignoring bikeshed discussions), and people generally end up using his creations. When it comes to software design, a dictatorship is often more productive than a democracy! "When I come across pages of JavaDoc-ish API documentation, I groan internally and just look at the source instead." Amen :)
- derefr 17y ago
  > a dictatorship is often more productive than a democracy! "The only thing democracy has ever really been good for is making sure that things people don't like get vetoed. Democracy is no way to plan; it is merely a way to restrict one's choices, possibly to none at all."

by tow21 17y ago

arohner 17y ago

>Complaints around infelicities in the Python stdlib are fair enough - I don't think anyone would defend them, but what can you do? You can't change published APIs. You're absolutely right, but that doesn't mean Zed isn't on to something. How many different ways are there to open a subshell in python? There's popen, popen2, popen3, popen4 (I think), plus more (subprocess?). Yes, the past can't be changed, but it's still a good idea to stop and ask why there are so many mistakes like this. Why is there a time module, and a date module, and a datetime module, and yet all three are broken? The main question is What factors allowed the stdlib to get so quirky, and what can be done to fix that? Pointing out the stdlib is quirky is the first step in fixing the problem.

aston 17y ago
Python 3 intends to fix a lot of the stdlib issues. For example, the subprocess module should obsolete all of the various popens. http://docs.python.org/library/subprocess.html http://docs.python.org/library/subprocess.html
- dkarl 17y ago
  And subprocess is available in 2.6, too. It looks like a well-designed API and certainly makes it easy to run external filters on data. For example, to get the output of 'tidy -q' on a string s: proc = subprocess.Popen(['tidy', '-q'], stdin=PIPE, stdout=PIPE, stderr=PIPE) (tidyout, tidyerr) = proc.communicate(input=s) if proc.returncode != 0: ...
  - tdavis 17y ago
    Errr, subprocess has been around since 2.4...
deleted 17y ago
[deleted]
stcredzero 17y ago
If you have a quirky stdlib, this can be a big problem if its source is visible. This can be a tremendous source of bad examples to the community. This happened with the various Smalltalk images -- there was some rather good code, and then there was a lot of procedural/spaghetti code by junior programmers. A lot of it happened to get into places where it would be very visible to other junior programmers. (Database/OR tools.) I think that a lot of this quirky stuff is due to the "uncool" factor of cleaning up such infrastructure level stuff. It's much cooler to be working on a proxy framework that talks to some new protocol. Making sure dates and times work well seems pedestrian. But it is actually tremendously important.

deleted 17y ago

[deleted]

pmjordan 17y ago

Complaints around infelicities in the Python stdlib are fair enough - I don't think anyone would defend them, but what can you do? You can't change published APIs. I was under the impression that Python 3 broke a lot of backwards compatibility, so could they not introduce new APIs with that? Or is that in fact what they did, and Zed is just complaining about 2.x? I apologise if I'm mistaken on this, I've hardly used python at all. (though I keep meaning to learn it so I can finally stop writing bash scripts)

jmillikin 17y ago
Python 3 removed old, deprecated APIs, but did not change any existing APIs. Probably the most extreme re-organization was the urllib/urllib2 merger, which was at its core just removing old stuff. Because Python is dynamically typed, the "protocol" of a library is extremely important, and the semantics of existing functions/classes are almost never changed. Of Zed's complaints, I feel that two are misguided (time handling seems quite reasonable to me, and I've never seen an easier documentation system than Sphinx). I think applying the "del" keyword to objects in a container is a mistake in the language, but that's how it was designed, so it probably wouldn't have been changed in the 2 -> 3 transition. It certainly won't be changed now -- the best that can be hoped for is for its use to be discouraged in the documentation. Install/Uninstall of modules is fairly easy, but requires all concerned parties to work together. Otherwise you end up with half-installed, broken modules. There are PEPs in progress to work on this, but it's a social/political problem rather than a technical one. Python's file-manipulation APIs are an ongoing calamity.
- llimllib 17y ago
  > Python 3 removed old, deprecated APIs, but did not change any existing APIs. This is simply false. Modules were added, renamed, and modified. Module names now conform to pep 8 (Queue -> queue, SocketServer -> socketserver, etc). cPickle, cProfile and cStringIO are now accessible through their non-c counterparts instead of individually. Packages have been grouped - for example the http libraries are now in http.* instead of the top level. Examples of API changes include the removal of sys.maxint and sys.exitfunc and friends, many libraries returning unicode strings instead of byte strings by default, and lots lots more. Consult the "What's new in python 3.0" for a high-level overview: http://docs.python.org/3.0/whatsnew/3.0.html#library-changes http://docs.python.org/3.0/whatsnew/3.0.html#library-changes

rabidgnat 17y ago

"API doc autogeneration; I can guarantee that if anyone came up with a default tool with default output such that "doctool module html_directory" was all you needed (and indeed people have) then there would be widespread, perfectly legitimate, disagreement on any number of choices in the design of it." In my experience, the opposite actually happens. When something is written, people either use it and customize it over time, or they just find something else and say it didn't suit their needs. It's when an extremely useful/general library is PROPOSED that it becomes a huge disagreement. This is, for instance, why C++'s Boost still doesn't have logging or a unified XML library, and won't likely have a garbage collection library before a C++ TR defines the interface: everyone argues over the color of the bikeshed, and the people who try to write the libraries get caught up in infinite microdiscussions over details. Conversely, someone like Linus Torvald's success is that he just makes the things he needs/wants (ignoring bikeshed discussions), and people generally end up using his creations. When it comes to software design, a dictatorship is often more productive than a democracy! "When I come across pages of JavaDoc-ish API documentation, I groan internally and just look at the source instead." Amen :)

derefr 17y ago
> a dictatorship is often more productive than a democracy! "The only thing democracy has ever really been good for is making sure that things people don't like get vetoed. Democracy is no way to plan; it is merely a way to restrict one's choices, possibly to none at all."