51–60 of 108 posts
I guess I agree things could be simpler, although the cries of "garbage!" were a bit much. I wrote a wrapper function around urllib2 about 5 years ago and haven't looked back.
I like the presentation, but for me it just underlines how it's smart to stay far away from Python. It's great that it's improving, but many other languages have a much better library/API situation than Python has had for years already. Will Python catch up fast enough?
It's quite the opposite, actually. Python already has an extremely good and very capable standard library, arguably better than any other language. Python also has a community with a strong sense of what kind of API design best fits with the Python philosophy (which usually boils down to readability and consistency). So there are many efforts going on to improve the standard libraries. For example, the standard libra…
I guess I agree things could be simpler, although the cries of "garbage!" were a bit much. I wrote a wrapper function around urllib2 about 5 years ago and haven't looked back.
Wrappers are handy, but as soon as you need something beyond the basic use case they become useless. What’s great about Requests is that it seems to have minimal leakiness as an abstraction over HTTP.
Still I like these new projects; it's a shame they missed the python 3.x boat by only a year or two. That would have been a great time to include them in the stdlib.
Wow those libraries are indeed great, amazing compared to the standard libs. Hope they'll be included in the standard libs one day.
Libraries tend to move more quickly than the language and interpreter/compiler. Tying them together, while convenient, often leads to rot, clunky libraries, slow moving updates, and libraries being build to the interpreter/compiler instead of to the needs of the users.
I would like to see instead a somewhat canonical (widely accepted) list of the highest quality libraries for a given set of needs, with information and pro/con/caveats listed for each, instead of them being included in the mainline trunk.
I really applaud what Kenneth Reitz has been doing lately.
-- a very happy user of the `requests` library
Anybody have a text version of this? I got maybe 30 slides in before I got too annoyed to continue.
Earlier quoted context omitted.
It's quite the opposite, actually. Python already has an extremely good and very capable standard library, arguably better than any other language. Python also has a community with a strong sense of what kind of API design best fits with the Python philosophy (which usually boils down to readability and consistency). So there are many efforts going on to improve the standard libraries. For example, the standard libra…
If Python has a better standard library than the other languages you know, then you should learn some more languages.
IMO, Python's stdlib beats C++, Ruby, Java, javascript and Perl....
If you have a look at the older libraries, most of them were written in a procedural style. Not only that, it is very amenable to testing in the REPL.
import smtplib
s=smtplib.SMTP("localhost")
s.sendmail("me@my.org",tolist,msg)
If you have a look at the XML library, roughly when "patterns" became popular, this style of thinking infested standard library contributions. It also coincides with a time when camelCased function names crept into the python standard library.
Here's one in xml/dom/pulldom.py:
self.documentFactory = documentFactory
Here's more pain from libraries of the same era, some of these I'd argue un-Pythonic:
#xml/sax/xmlreader.py:
def setContentHandler(self, handler):
#wsgiref/simple_server.py:
class ServerHandler(SimpleHandler):
#urllib2.py:
class HTTPDigestAuthHandler(BaseHandler,
AbstractDigestAuthHandler):
Even logging is infected by the same over-patterning. logging/__init__.py:
class StreamHandler(Handler)
LoggerAdapter(someLogger, dict(p1=v1, p2="v2"))
#multiprocessing/managers.py:
class BaseManager(object)
Initially, buttons had to be subclassed just to handle click events, since functions were not first class objects. Then someone came up with a MouseListener interface, which proved too unwieldy to handle a single click. So the MouseEventAdapters came into being.
Therefore, to handle a click in a "pattern" manner involves
an anonymous class
which subclasses MouseAdapter
which implements MouseListener,
which overrides MouseClick.
Publishing how industry solves this problem of "MouseClick" over and over as a pattern [design pattern is a general reusable solution to a commonly occurring problem within a given context in software design] only gives legitimacy to an approach that has dubious wider applicability.
Heavens help the future developers who are forced to do it because it is now recognized as being industrially "good practice" and codified in a reknowned book.
It isn't!
It was a style that was forced by the constraints of a language.
This is neither pythonic nor necessary:
panel.addMouseListener
(
new MouseAdapter ()
{
public void mouseEntered (MouseEvent e) {
System.out.println (e.toString ());
}
}
);
def mouseEntered(event):
print event
panel.mouseEntered = mouseEntered
panel.mouseEntered.append(mouseEntered)
This presentation brings up a tangential point that has always confused me: how error-prone is starting a subprocess, really? I agree with the author's goals of making common tasks easier and more obvious. urllib2 is an easy target, as it was added to the standard library over a decade ago, long before REST was something people talked about. The best tools for packaging, versioning, and testing have always been a bit…
The portion that explains of how subprocess shuns dev/ops guys in the beginning is so true. Perl/Bash colleagues at work would basically ask me how to perform output=`command`. Once they seen subprocess, they would continue writing their script in Bash/Perl.
I like the presentation, but for me it just underlines how it's smart to stay far away from Python. It's great that it's improving, but many other languages have a much better library/API situation than Python has had for years already. Will Python catch up fast enough?
> It's great that it's improving, but many other languages have a much better library/API situation than Python has had for years already. As someone who has spent the last 5.5 years at a job where I didn't need anything but the standard library, I don't agree. What are these other languages that contain a better situation?