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

61–70 of 108 posts

Re: Python for Humans

#62

Post by peter_l_downs »

teyc wrote: post #57

I blame GOF for making Python Standard Libs hard. The patterns described were for an OO system where functions were not first class. Python didn't need to be complicated. 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) note the absence of…

I'm making an attempt [1] at simple logging. Thoughts on the basic design so far?

[1] https://github.com/peterldowns/lggr

Re: Python for Humans

#63

Post by jonmulholland »

bpierre wrote: post #24
dspeyer wrote: post #16

Anybody have a text version of this? I got maybe 30 slides in before I got too annoyed to continue.

You can read the Markdown file: https://github.com/kennethreitz/python-for-humans/blob/maste...

Just use arrow keys on your keyboard to navigate.

Re: Python for Humans

#64

Post by teyc »

peter_l_downs wrote: post #62
teyc wrote: post #57

I blame GOF for making Python Standard Libs hard. The patterns described were for an OO system where functions were not first class. Python didn't need to be complicated. 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) note the absence of…

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 smtplib
    ...    smptlib.SMTP('mail.test.com').send('syslog@test.com',
    ...   'no-reply@mysystem.com', module + ' ' + message)
    ...
    >>> log.configuration.append(send_mail)
    >>> log.log(log.CRITICAL, 'PrintModule', 'Printer failure', sys.exc_info())
    etc.
Next, configuration must be straightforward.

    >>> import log
    >>> log.configuration.extend([
    ...  log.sendmail,
    ...  log.syslog,
    ...  log.rotatinglog])
    ...
    >>> log.sendmail.to = 'admin@test.com'
Notice how this can easily be captured into a file you might name as logconfig.py

You might be wondering how to assign an attribute to a function, like sendmail.to?

In this particular case, sendmail is actually a class that masquerades as a function.

    >>> class Sendmail:
    ...    to = None
    ...
    ...    def __call__(self, level, module, msg, exc):
    ...       # et. c
    ...
    >>>  sendmail = Sendmail()
This way, the most common use-case, i.e. to be notified when something happens is easy to apply, while more complicated ones are only a short step away.

Re: Python for Humans

#65

Post by antoncohen »

joshbaptiste wrote: post #23
engtech wrote: post #13

Earlier quoted context omitted.

I agree that people should use a good package manager, but the reality of the corporate env world is that you'll be trying to use the latest Python on some ridiculously old unix install without root access, and you'll never be able to get IT to install the latest for all users.

+1 for you sir, we are constantly fighting with Unix admins who refuse to install anything but the generic terribly old 2.3 - 2.4 Python versions that are bundled with their default enterprise Suse packages, which only leads to full /home issues since everyone just downloads their own versions, compiling extensions manually.

Or you could write the applications for the systems they will run on. Why develop in the latest Ubuntu with Python 2.7 when you know your company runs RHEL 5 or SUSE with Python 2.4?

I know it was annoying how long RHEL lasted with Python 2.4, but now the latest RHEL, Debian-stable, and Ubuntu LTS all have Python 2.6, so write to Python 2.6 if your company uses those OSs, there's not excuse to write incompatible code targeted at Python 2.7.

In many Linux distributions it is impossible to replace the Python version, core parts of the OS like package management will break. It is possible to install another version in parallel and use "virtualenv --python=" to use it for an application. If you are using RHEL/CentOS 5 you can install the python26 package from the EPEL repository.

Re: Python for Humans

#66

Post by arjn »

I can confirm that the python subprocess api is a pain to use and also documented poorly. I recently had to use (no choice) python 2.5.x to write a script that extensively called external programs and ran into several problems. It strange that a language such as python which I find so easy to use in many cases does not already have a good as in simple, safe and well documented subprocess api.

Re: Python for Humans

#67

Post by tbatterii »

d0mine wrote: post #43
tbatterii wrote: post #33

Earlier quoted context omitted.

What's the package manager for windows? Mostly I agree with you, but installing python on windows is a PITA compared to *nix. PIP works until you need something that requires compiling extensions which is also a PITA on windows. IIRC easy_install can install binaries, but I could be wrong about that since I don't do windows development anymore and thus pip works for me 99% of the time. Regardless, my point is, though…

PIP works until you need something that requires compiling extensions You could use *.exe installers such as http://www.lfd.uci.edu/~gohlke/pythonlibs/ Advanced users could use mingw to compile extensions.

"You could use *.exe installers" yeah I know, but then you aren't using PIP, and how's that work with virtualenv? Again, not as simple as some would have you believe.

Re: Python for Humans

#68

Post by Lazare »

tbatterii wrote: post #67
d0mine wrote: post #43

Earlier quoted context omitted.

PIP works until you need something that requires compiling extensions You could use *.exe installers such as http://www.lfd.uci.edu/~gohlke/pythonlibs/ Advanced users could use mingw to compile extensions.

"You could use *.exe installers" yeah I know, but then you aren't using PIP, and how's that work with virtualenv? Again, not as simple as some would have you believe.

Actually, the windows binary installers work perfectly with virtualenv, and is perfectly simple: http://stackoverflow.com/questions/3271590/can-i-install-pyt...

(It is, however, poorly documented.)

Re: Python for Humans

#69

Post by peter_l_downs »

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…

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.
Post reply on HN