jessenoller.com comments - Latest Comments

Re: PyCon 2010: Talks are live!

Jospeh Lisee — Thu, 05 Nov 2009 00:51:20 -0000

Thanks for going through effort organizing PyCon!

Re: SSH Programming with Paramiko | Completely Different

jnoller — Fri, 30 Oct 2009 17:48:55 -0000

Given the article was about SSH programming, and paramiko is for SSH
programming - I think it's a much better fundamental solution to SSH
programming than pexpect. I've had plenty of expect-like scripts, and
expect-base script break because assumption on output, regexes, etc
broke. I agree that paramiko isn't a generalized tool, but for the
problem it tries to solve it is the best tool (in my opinion).

If we were talking a general "watch something and react" tool, then
yeah - pexpect makes sense, but we're not.

Re: SSH Programming with Paramiko | Completely Different

mikepenn — Fri, 30 Oct 2009 17:35:54 -0000

Actually something expect-like doesn't care what the output is if you code the same way you do with paramiko. pexpect.expect takes a list of args... that list can be regular expressions or perhaps pexpect.TIMEOUT or pexpect.EOF. Based on that which one in that list matches, you make a decision; this is not an issue of a small decision tree. I'm ok with people using other tools, but lets be fair to the tools available. pexpect is a much more generalized solution than paramiko; paramiko gives you more granular visibility into stderr than pexpect does, but paramiko is limited to ssh.

Re: SSH Programming with Paramiko | Completely Different

jnoller — Fri, 30 Oct 2009 14:36:31 -0000

Personally, I've found any tool which waits for specific output from
commands to be terribly brittle. Output from remote sources can (and
does) frequently change - sure, something expect-like does the job if
you can count on the same output over and over again.

I know pexpect has gotten better since the time I used it, which
admittedly was awhile ago and at this point I go out of my way to
avoid it/expect-like tools unless I simply can't. I'm also much more a
fan of tackling things with tools like paramiko, which is more
programmatic/reliable in my mind.

Re: Dive Into Python 3: The Foreward

jnoller — Tue, 27 Oct 2009 23:00:56 -0000

Any text in the foreword is under the same license as the book itself! Go for it!

Re: Dive Into Python 3: The Foreward

Giulio Piancastelli — Tue, 27 Oct 2009 13:31:31 -0000

I have translated Dive Into Python 3 in Italian and I would like both to translate also your foreword and to put it alongside the book's translated text. First question: am I allowed to do it? Both the original and the translated book's text are licensed under CC-BY-SA 3.0. So, second question: have you attached / do you want to attach a specific content license to the foreword text as published on this page? (Possibly, a license that would allow me to translate it and publish it on similar terms?) Thanks!

Re: SSH Programming with Paramiko | Completely Different

mikepenn — Tue, 27 Oct 2009 11:47:05 -0000

I'm curious about something mentioned above... you seem to discourage use of pexpect for driving ssh sessions, but you launched into issues with 'subprocess' without specific comments about why pexpect isn't a winner for you. Have you had bad experiences with pexpect, and if so please elaborate...

Having used pexpect to drive cisco routers for the last 3 years, I have to say it's been nothing but pleasant to me.

Thoughts?
\m

Re: Dive Into Python 3: The Foreward

jnoller — Mon, 26 Oct 2009 21:10:58 -0000

Thank you; again

Re: Dive Into Python 3: The Foreward

Thijs — Mon, 26 Oct 2009 21:02:10 -0000

There's another 'foreward' typo in the first sentence of this blogpost..

Re: Dive Into Python 3: The Foreward

jnoller — Mon, 26 Oct 2009 09:06:43 -0000

Why are you bustin my balls? ;)

Actually, juggling work-work with open-source work and being a parent is a painful process for me, honestly. It doesn't help I'm a severe workaholic. I'd be perfectly fine with 12 hour workdays :|

Re: Dive Into Python 3: The Foreward

twitter-7645442 — Mon, 26 Oct 2009 08:35:46 -0000

Jesse,

Great foreword, but just one little thing:

If you're coding *between* your daughter's naps (e.g., when she's awake), what are you doing *during* her naps (when she's asleep)? And when do you find time to spend with her?

;-P

Congrats on the honor, and my experience "diving into" python mirrors yours.
brian

Re: Dive Into Python 3: The Foreward

jnoller — Mon, 26 Oct 2009 07:48:59 -0000

I already read Guido's proposal - I volunteered to draft the PEP (it's in progress) for the moratorium. I know that the 2/3 split will mark a pause - I'm for pausing. Being in core dev, my boogeyman has been the standard library - I'd like to see more focus on that, improving, cleaning, testing and other areas outside of the syntax and builtins.

It will be interesting ;)

Re: Dive Into Python 3: The Foreward

jnoller — Mon, 26 Oct 2009 07:46:22 -0000

Argh. Fixed.

Re: Dive Into Python 3: The Foreward

tag — Mon, 26 Oct 2009 05:09:49 -0000

Great intro, Jesse. It comes at a time when I'm reassessing Python 3 (nearly a year since the first official release) and what it means for the language. I hope to post these thoughts on my own blog soon. In the meantime:

Python 3 also doesn’t end the evolution of the language – not by any stretch. New features, syntax and libraries are still being added, and will probably be added, tweaked and removed for as long as Python itself lives on.

You will have read Guido van Rossum's recent proposal which recommends a moratorium on changes to Python syntax. He also says:

The main goal of the Python development community at this point should be to get widespread acceptance of Python 3000.

Reading between the lines, I think the Python 2/3 fork will mark a significant pause in the evolution of the language. The overhead of developing, supporting and maintaining two versions of everything is high. New features would have to be backported. Libraries need to work on two platforms. Alternative implementations have two targets. Etc.

I'm interested to see how things pan out. Certainly, it's refereshing to read a book like Mark Pilgrim's, which really does dive right in.

Re: Dive Into Python 3: The Foreward

technomalogical — Mon, 26 Oct 2009 00:25:52 -0000

Also, did he really ask if you'd be "interesting"? :)

Re: Dive Into Python 3: The Foreward

jnoller — Sun, 25 Oct 2009 14:35:07 -0000

Typo, thanks for catching it - fixed

Re: Dive Into Python 3: The Foreward

mattchaput — Sun, 25 Oct 2009 14:33:54 -0000

It's actually the foreWORD.

Re: Get with the program as contextmanager | Completely Different

bestchai — Fri, 16 Oct 2009 11:16:02 -0000

"This makes it so that when we call it on line 20 in Listing 5, we get the reference to the queue we need." should be line 18.

Re: SSH Programming with Paramiko | Completely Different

xav.vijay — Wed, 23 Sep 2009 21:18:33 -0000

Hi

I followed ur example for paramiko and my code is like this..

import paramiko
import os

ssh = paramiko.SSHClient()
ssh.load_system_host_keys()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('server-name',22,'root','password')
stdin, stdout, stderr = ssh.exec_command("ssh -V")
stdout.readlines()

But, I am getting the following error!! ... I am not sure why...Can u please help!!
Traceback (most recent call last):
File "C:\Documents and Settings\aannas01\My Documents\Downloads\ssh-ver.py", line 18, in
in <module>
ssh.connect('server-name',22,'root','password')
File "C:\Python26\lib\site-packages\paramiko\client.py", line 309, in connect
self._auth(username, password, pkey, key_filename, allow_agent, look_for_keys)
File "C:\Python26\lib\site-packages\paramiko\client.py", line 463, in _auth
raise saved_exception
BadAuthenticationType: Bad authentication type (allowed_types=['publickey', 'keyboard-interactive'])

I have no clue why the error is asking for a different set of parameter. I am on a Windows XP machine, and trying to login to a Linux machine...

Re: Python 3to2: Go check it out.

donspaulding — Mon, 21 Sep 2009 12:42:09 -0000

The py-postgresql project might be a good starting point for getting a realistic Python 3.X codebase backported via 3to2.

http://python.projects.postgresql.org/

It seems like 3to2 needs to learn how to remove annotations and dictionary comprehensions first. Unfortunately hacking 3to2 is a bit beyond me. Sounds like a great idea though.

EDIT: Actually, 3to2 does handle annotations correctly, it was just barfing on ParseErrors in certain files and then not running any fixers on those files. Protip: READ THE OUTPUT.

Re: Python 3to2: Go check it out.

andrew cooke — Tue, 01 Sep 2009 11:03:00 -0000

awesome indeed. thanks for this. saw an email ages ago to dev (which i don't read all of) suggesting this and then it seemed to disappear - gret to see it didn't get lost. i will give it a go on lepl (see my link) next release (coming up soon).

Re: Django, mod_wsgi, Apache and OS X - do it.

jnoller — Sat, 29 Aug 2009 08:48:26 -0000

By the way Graham; setting apache/python/mod_wsgi up with the default python2.6 interpreter was dirt simple.

Re: Django, mod_wsgi, Apache and OS X - do it.

grahamd — Sat, 29 Aug 2009 08:38:30 -0000

WSGIPythonEggs directive only applies to embedded mode and you are using daemon mode. For daemon mode you use python-eggs option to WSGIDaemonProcess. This is explicitly mentioned in the available documentation for the configuration directives. You can also set os.environ, but either way, Apache normally runs as a special user and so is still going to need write access to the directory you specify. As you find, just easier to use daemon mode and set the user as yourself.

The whole reason the 32/64 bit issues comes up is because 'python' command line program is only installed as 32 bit and so everything runs as 32 bit and when people are using it initially don't see any problems. The MacOS X version of Apache however is a 64 bit capable application and so will default to running 64 bit if you have 64 bit cpu. The distutils package in Python though only builds 32 bit extensions, so unless third party packages have been made MacOS X aware in some way to get around that problem, they will fail to build for all architectures. Some times the simplest thing to do is to install your own version of Apache from source code, as it will only be 32 bit and thus avoid all the problems.

Pretty well all the issues are documented some where as is a reference to mailing list for mod_wsgi. Of course, getting people to read documentation and asking questions on the correct forum is the challenge. :-)

Re: Python 3to2: Go check it out.

joeamenta — Fri, 28 Aug 2009 01:15:25 -0000

Haha, I would love to see what comes out of the 2to3 -> 3to2 generator. I had initially thought about making it a goal that 2to3 -> 3to2 code would look the same as the original, but as I learned more, I conceded that it would be unrealistic and impractical.

Re: Django, mod_wsgi, Apache and OS X - do it.

Brian — Sun, 16 Aug 2009 13:50:03 -0000

re: egg cache -- after firing things up the first time, I got an error that ended like this:

[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] The following error occurred while trying to extract file(s) to the Python egg
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] cache:
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1]
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] [Errno 13] Permission denied: '"'
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1]
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] The Python egg cache directory is currently set to:
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1]
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] "/.python-eggs/"
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1]
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] Perhaps your account does not have write access to this directory? You can
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] change the cache directory by setting the PYTHON_EGG_CACHE environment
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] variable to point to an accessible directory.

I fixed that by adding a "user=myuser" arg to the WSGIDaemonProcess directive (this after also creating 'chmod 777' dirs owned by the web user, which didn't work, and which I still don't understand). I also tried fixing this using os.environ('PYTHON_EGG_CACHE') in my myapp.wsgi script, and also using the WSGIPythonEggs directive mentioned here: http://code.google.com/p/modwsgi/wiki/Applicati... Nothing worked until I found "user=". BTW, I'm using mod_wsgi 2.5, installed (and dl'd for that matter) using your exact commands, because I was pretty sure going into it that we had near-identical macbook pros.

I'm using the Apple-supplied python installation. I initially created my virtualenv using your instructions exactly, but went back to add '--no-site-packages' when I started having issues loading mysqldb. Then I actually just uninstalled mysqldb from the system, did the "export ARCHFLAGS" like the modwsgi site says to do to get around arch issues, built a new version of the module from source, and now I'm getting:
"[Sun Aug 16 13:23:49 2009] [error] [client 127.0.0.1] raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
[Sun Aug 16 13:23:49 2009] [error] [client 127.0.0.1] ImproperlyConfigured: Error loading MySQLdb module: dynamic module does not define init function (init_mysql)
"
I guess it's progress, but again, hardly simple. I haven't finished googling the issue to see what the fix is. It's v. 1.2.3c1 of the module. I guess it's true that this is perhaps mostly an arch-level issue outside the control of modwsgi, but why is it that I can write CLI scripts with Python all day long and never run into any of these issues? I'm not blaming modwsgi or questioning what you've said, I really just want to understand this more clearly, because it's driving me insane, and that's not enjoyable.

I haven't given much thought to arch up to now. Perhaps it'd be easier to just build *everything* from source: apache, python, etc. Have a bare-bones base python install, and just easy_install modules in virtualenv as needed. Advice/opinion hereby solicited. I'm not sure how to reach Graham - I'm sure there's a mod_wsgi google group, so I'll see what I find.