Disqus - Latest Comments for jnoller

Re: PEP 3003: “Python Language Moratorium” – Accepted

jnoller — Mon, 09 Nov 2009 20:27:25 -0000

It was brought up in the discussions of this pep on python-dev, I
don't remember ther arguments against it, but there were a few.

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: Python on Ice

jnoller — Fri, 30 Oct 2009 09:46:17 -0000

Most patches need only target 1 version - typically the committer applying the patch will back port/forward port as needed. Only core-dev is actively maintaining the two versions.

Re: Python on Ice

tag — Thu, 29 Oct 2009 16:04:46 -0000

Thanks for the extra information, Jesse. I think this change of focus is right, and important. I would argue, though, that it is the strength of the core language which has made so many people willing to contribute to the standard library, tests, documentation etc. Python is a pleasure to write and use.
Maintaining two versions of Python is less pleasant.

Re: Python on Ice

jnoller — Wed, 28 Oct 2009 21:37:21 -0000

Already brought up and rejected.

Re: Python on Ice

jnoller — Wed, 28 Oct 2009 20:03:52 -0000

We've added more features in the last few years than strictly necessary - many of those features have not seen widespread usage simply due to people/companies/OS Vendors being slow to update. A cooling off period, which only affects syntax, built-ins and things in the core will give us a greater idea of what has been added that works, and what doesn't.

Most places haven't even upgraded to 2.6 yet.

Now let's take into account 3.0 - 2.7 is slated to be the end of the line for python-core working on the 2.x codebase. 3.x is the future, from a core development standpoint - things are being done on 3k, which are not being back ported. 3.x is the way forward, and letting the world catch up to 2.6 (and 2.7 next year) with minimal syntax alterations, and then 3.0 which bring on a whole bunch of syntax and idiom changes also benefits us, and the ecosystem.

As Jason notes; the moratorium does not apply to docs, tests, the standard library or the interpreter. The hope is that minimizing focus on syntax in will add bandwidth and focus in favor of improving these other things - which helps *everyone*.

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

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

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

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

Typo, thanks for catching it - fixed

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.

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.

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

jnoller — Sun, 16 Aug 2009 13:23:31 -0000

Hey Brian-

I have no idea what you're talking about with regards to the python egg cache. I also didn't run into architecture related issues; so I'd be interested to hear what those are. Are you hand compiling it? Is it the built in version? I know Graham has outlined some of the issues here: http://code.google.com/p/modwsgi/wiki/Installat... - the biggest one is the fact the python.org versions of python don't ship 64 bit compatible.

Frankly, most of the issues I've run into are problems with the multi-architecture mess which is leopard+python builds - not mod_wsgi, mod_wsgi just shows the problems. Having a 64 bit apache, and a 32 bit version of Python (which python.org ships) doesn't exactly make things easy for mod_wsgi which has to work with both.

As for the dev vs. production issue - I run the same config on the server (+ or - minus some tweaks) as I do on the desktop.

I can understand your pain, which is why I tried to be explicit as possible. Have you talked to Graham (the mod_wsgi maintainer) about any of this?

Re: Interested in a Boston Python Conference?

jnoller — Tue, 04 Aug 2009 02:11:33 -0000

Yes, there are a few of us - Doug, James tauber, etc that live in MA.
Yes, there's probably enough in the state to put something together.
The point is, is to do something big enough to draw people outside the
state in.

Just based on trying to recruit python people in the area, there
aren't as many as I'd like.

I'd like to point out I live here again :)

If you want I can call it PyNortheast :)

Re: Interested in a Boston Python Conference?

jnoller — Tue, 04 Aug 2009 02:09:35 -0000

Oh, I want you to come, complaining is optional - but entirely
amusing :)

Re: Interested in a Boston Python Conference?

jnoller — Mon, 03 Aug 2009 23:59:16 -0000

Re: Interested in a Boston Python Conference?

jnoller — Mon, 03 Aug 2009 23:56:45 -0000

Oh, I want you to come, complaining is optional - but entirely
amusing :)

Re: Interested in a Boston Python Conference?

jnoller — Sun, 02 Aug 2009 09:18:57 -0000

Oh yeah, Doug and I talked a bit last night - my idea is not original, come to find out - doug's thought about it a bit. We're going to keep chewing on it as a side-thread due to PyCon 2010 and other stuff eclipsing everything else right now.

Re: Interested in a Boston Python Conference?

jnoller — Sun, 02 Aug 2009 09:10:24 -0000

Hey, hot isn't wretched. It's better than snow. And I know Ned, there's a handful of people in the immediate area I'd hit up for talks. There's about a dozen companies I'd hit up for sponsorship, even if that means I have to walk around dressed in a suit covered in sponsorships like Nascar :)

Re: Interested in a Boston Python Conference?

jnoller — Sun, 02 Aug 2009 09:08:33 -0000

I work 45 minutes outside of cambridge, and live an hour outside. I have a hard time explaining to the wife why I'm going to be MIA well past the kiddo's bedtime.