Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python for Humans

python-for-humans.heroku.com

Post reply on HN
Print view View original

71–80 of 108 posts

Re: Python for Humans

#71

Post by obfuscate »

pnathan wrote: post #58
socratic wrote: post #31

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…

I have never been able to figure out how - in Python - to be able to stream asynchronously both stdout and stderr from the subprocess, both printing both of them as well as writing the data to a file.

I've done this using select.

Re: Python for Humans

#73

Post by mindrunner »

j_baker wrote: post #37
rmc wrote: post #11

This makes a lot of good points, but some bad ones. Esp. the "installing python" one. Just use your package manager to install all the versions you need. And for "Packaging and Dependencies", just use pip.

What if your package manager doesn't support the version of Python you're targeting? The most common place this happens is if you have some old RHEL 5 boxen that haven't been upgraded (and who that uses RHEL doesn't?). Or suppose you use python 2.7, which isn't supported by very many (any?) "stable" linuces (aka Debian stable, RHEL, Ubuntu LTR, etc). And installing packages into the system python (if that's what you'…

This problem really echoed with me. The one thing I hate about Python is the pain of compiling it from source.

Unlike startups, we enterprise dudes don't have the liberty of choosing the latest distros with better base Python versions.in some cases,the machines don't even have a compiler installed.

Try running your funky new admin script on these rhel5 boxen is a pain.

I've resorted to compiling with LD_RUN_PATH, -rpath & -r set.

I think this should be included in the python-guide for the sanity of other devops dudes

Re: Python for Humans

#74

Post by jacobolus »

peter_l_downs wrote: post #69
teyc wrote: post #64

Earlier quoted context omitted.

The acid test is to see if you can avoid terms like "Writer", "Printer", and whether someone is able to explore your API using the REPL. >>> import log >>> log.log(log.CRITICAL, 'PrintModule', 'Printer failure', sys.exc_info()) PrintModule: Printer failure >>> print log.configuration [ ] >>> log.configuration.clear() >>> print log.configuration [] >>> def send_mail(level, module, message, exception): ... import smtpl…

Thanks. I like the idea of classes masquerading as functions. And easier configuration. I had actually started writing this 2 days ago as something just for me, but after reading this decided to try something new.

With something that can happen as often as logging, make sure that you test it when accessed from multiple python threads, and pound the crap out of it in various typical configurations. Python’s default logging can be a real dog, and at least in one project I was working on a few years ago turned out to be a real bottleneck.

Re: Python for Humans

#75

Post by kansface »

teyc wrote: post #64
peter_l_downs wrote: post #62

Earlier quoted context omitted.

I'm making an attempt [1] at simple logging. Thoughts on the basic design so far? [1] https://github.com/peterldowns/lggr

The acid test is to see if you can avoid terms like "Writer", "Printer", and whether someone is able to explore your API using the REPL. >>> import log >>> log.log(log.CRITICAL, 'PrintModule', 'Printer failure', sys.exc_info()) PrintModule: Printer failure >>> print log.configuration [ ] >>> log.configuration.clear() >>> print log.configuration [] >>> def send_mail(level, module, message, exception): ... import smtpl…

You can assign an attribute to a function in Python since functions have a __dict__. for example:

def foo(): pass

foo.a="asdf"

>>> foo.a

'asdf'

>>> foo.__dict__

{'a': 'asdf'}

or alternatively:

>>> def bar():

... bar.a = "asdf"

...

>>> bar.a

Traceback (most recent call last):

  File "", line 1, in
AttributeError: 'function' object has no attribute 'a'

>>> bar()

>>> bar.a

'asdf'

Re: Python for Humans

#76

Post by pbreit »

mixmastamyk wrote: post #47

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.

That's precisely the problem: your wrapper helps you...and only you (ie, it's worthless).

Re: Python for Humans

#77

Post by Silhouette »

loevborg wrote: post #30

I was intrigued by the author's library "envoy", which is intended to provide a more intuitive interface to running processes from python. ( https://github.com/kennethreitz/envoy ) The back story is that the older APIs that Python comes with -- os.popen and os.system -- are deprecated. Programmers are urged to use the "subprocess" module instead. Although this doesn't have the problems of the original functions, it h…

> subprocess.call() accepts an array in the style of ["ls", "-l", "/mnt/My SD card"]. This has obvious advantages over having to deal with escaping shell characters.

Unless you're running on Windows, in which case IME it will corrupt your carefully constructed parameters in completely inappropriate ways that can be debugged only at the cost of (a) changing the call() to execute a script that dumps the actual parameters supplied verbatim, and (b) at least an hour of your life that you're never getting back.

This "feature" is about one step above MS Word's default autoreplace behaviour in irritation level. What happened to "Explicit is better than implicit" and "Special cases aren't special enough to break the rules"?

Re: Python for Humans

#78

Post by euccastro »

teyc wrote: post #64
peter_l_downs wrote: post #62

Earlier quoted context omitted.

I'm making an attempt [1] at simple logging. Thoughts on the basic design so far? [1] https://github.com/peterldowns/lggr

The acid test is to see if you can avoid terms like "Writer", "Printer", and whether someone is able to explore your API using the REPL. >>> import log >>> log.log(log.CRITICAL, 'PrintModule', 'Printer failure', sys.exc_info()) PrintModule: Printer failure >>> print log.configuration [ ] >>> log.configuration.clear() >>> print log.configuration [] >>> def send_mail(level, module, message, exception): ... import smtpl…

You can assign arbitrary attributes to a plain function:

  >>> def f():
  ...   print f.something
  ...
  >>> f.something = 'blah'
  >>> f()
  blah

Re: Python for Humans

#79

Post by pbreit »

frodwith wrote: post #26
ak217 wrote: post #22

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…

"There is no equivalent in any other language." I don't know, LWP is pretty easy to use.

Does Perl come with LWP?

Re: Python for Humans

#80

Post by Silhouette »

teach wrote: post #56
adeelk wrote: post #52

Earlier quoted context omitted.

If Python has a better standard library than the other languages you know, then you should learn some more languages.

Do you have some examples? I thought I knew a fair number of programming languages, and Python's got one of the most comprehensive. IMO, Python's stdlib beats C++, Ruby, Java, javascript and Perl....

Python's library is comprehensive "on paper".

Vast amounts of it are actually incomplete or outright broken when you try to use it in practice.

The reliable parts of Python's standard library are at a level little beyond C and C++ and far behind Perl/CPAN, Java, .Net and so on.

And even then, as the article we're discussing points out, the APIs aren't actually very good a lot of the time.

Post reply on HN