Winpdb, awesome debugger.. needs emacs interface tho..

 After working with horrible php but the awesome xdebug+geben for emacs, I finally found an equivalent for python: winpdb and rpdb2.

In your code all you need is

import rpdb2; rpdb2.start_embedded_debugger('asdf',fAllowRemote=True)

where 'asdf' is just some password you come up with so that other users can't start debugging on your code.

Then start winpdb, navigate to file->attach, enter the password you chose, point it at your host and then debug away.

Great!

Why use Python Properties?

The reasoning is here, but in short  "...[t]he answer is, that in [a simple] use case we would not. In fact, we would write thus:

>>> class MyClass(object):
...   x = 0
...
>>> my = MyClass()
>>> my.x = 4
>>> my.x
4

'But!', I can hear you scream, 'there's no encapsulation!'. What will we do if we need to control access to x, make it read-only or do something else to it? Won't we have to refactor everything to the getters and setters that we avoided?

No - we just switch to the property version, add whatever we want, and have not changed the interface one iota! The great thing about properties is not that they replace getters and setters, its that you don't have to write them to future-proof your code. You can start out by writing the simplest implementation imaginable, and if you later need to change the implementation you can still do so without changing the interface. Neat, huh?"

Python2's urllib2 is a miserable libary

Python2's urllib2 is a miserable piece of shit of a library.  Use requests instead.

Simple wsgi apps without using a framework.

Using apache and mod_wsgi, serve a dirt simple app (useful for mocking services that havent been created yet by other programmers).

After installing mod_wsgi (sudo apt-get install libapache2-mod-wsgi)

Apache conf:

WSGIScriptAlias /webdir/ /filesys/dir/

With this you can call wsgi scripts in 'webdir' as localhost/webdir/test.py

python WSGI code for the file /filesys/dir/test.py:

def application(environ, start_response):
   response_body = '{"fake-json":"temp-output"}'
   status = '200 OK'
   response_headers = [('Content-Type', 'application/json'),
                       ('Content-Length', str(len(response_body)))]
   start_response(status, response_headers)

   return [response_body]

Done. No stupid framework needed for stupid simple apps.

Alex Martelli on python vs ruby

From comp.lang.python

Erik Max Francis wrote:
> "Brandon J. Van Every" wrote:

>> What's better about Ruby than Python? I'm sure there's something.
>> What is it?

> Wouldn't it make much more sense to ask Ruby people this, rather than
> Python people?

Might, or might not, depending on one's purposes -- for example, if
one's purposes include a "sociological study" of the Python community,
then putting questions to that community is likely to prove more
revealing of informaiton about it, than putting them elsewhere:-).

Personally, I gladly took the opportunity to follow Dave Thomas'
one-day Ruby tutorial at last OSCON. Below a thin veneer of syntax
differences, I find Ruby and Python amazingly similar -- if I was
computing the minimum spanning tree among just about any set of
languages, I'm pretty sure Python and Ruby would be the first two
leaves to coalesce into an intermediate node:-).

Sure, I do get weary, in Ruby, of typing the silly "end" at the end
of each block (rather than just unindenting) -- but then I do get
to avoid typing the equally-silly ':' which Python requires at the
_start_ of each block, so that's almost a wash:-). Other syntax
differences such as '@foo' versus 'self.foo', or the higher significance
of case in Ruby vs Python, are really just about as irrelevant to me.

Others no doubt base their choice of programming languages on just
such issues, and they generate the hottest debates -- but to me that's
just an example of one of Parkinson's Laws in action (the amount on
debate on an issue is inversely proportional to the issue's actual
importance).

One syntax difference that I do find important, and in Python's
favour -- but other people will no doubt think just the reverse --
is "how do you call a function which takes no parameters". In
Python (like in C), to call a function you always apply the
"call operator" -- trailing parentheses just after the object
you're calling (inside those trailing parentheses go the args
you're passing in the call -- if you're passing no args, then
the parentheses are empty). This leaves the mere mention of
any object, with no operator involved, as meaning just a
reference to the object -- in any context, without special
cases, exceptions, ad-hoc rules, and the like. In Ruby (like
in Pascal), to call a function WITH arguments you pass the
args (normally in parentheses, though that is not invariably
the case) -- BUT if the function takes no args then simply
mentioning the function implicitly calls it. This may meet
the expectations of many people (at least, no doubt, those
whose only previous experience of programming was with Pascal,
or other languages with similar "implcit calling", such as
Visual Basic) -- but to me, it means the mere mention of an
object may EITHER mean a reference to the object, OR a call
to the object, depending on the object's type -- and in those
cases where I can't get a reference to the object by merely
mentioning it I will need to use explicit "give me a reference
to this, DON'T call it!" operators that aren't needed otherwise.
I feel this impacts the "first-classness" of functions (or
methods, or other callable objects) and the possibility of
interchanging objects smoothly. Therefore, to me, this specific
syntax difference is a serious black mark against Ruby -- but
I do understand why others would thing otherwise, even though
I could hardly disagree more vehemently with them:-).

Below the syntax, we get into some important differences in
elementary semantics -- for example, strings in Ruby are
mutable objects (like in C++), while in Python they are not
mutable (like in Java, or I believe C#). Again, people who
judge primarily by what they're already familiar with may
think this is a plus for Ruby (unless they're familiar with
Java or C#, of course:-). Me, I think immutable strings are
an excellent idea (and I'm not surprised that Java, independently
I think, reinvented that idea which was already in Python), though
I wouldn't mind having a "mutable string buffer" type as well
(and ideally one with better ease-of-use than Java's own
"string buffers"); and I don't give this judgment because of
familiarity -- before studying Java, apart from functional
programming languages where _all_ data are immutable, all the
languages I knew had mutable strings -- yet when I first saw
the immutable-string idea in Java (which I learned well before
I learned Python), it immediately struck me as excellent, a
very good fit for the reference-semantics of a higher level
programming language (as opposed to the value-semantics that
fit best with languages closer to the machine and farther from
applications, such as C) with strings as a first-class, built-in
(and pretty crucial) data type.

Ruby does have some advantages in elementary semantics -- for
example, the removal of Python's "lists vs tuples" exceedingly
subtle distinction. But mostly the score (as I keep it, with
simplicity a big plus and subtle, clever distinctions a notable
minus) is against Ruby (e.g., having both closed and half-open
intervals, with the notations a..b and a...b [anybody wants
to claim that it's _obvious_ which is which?-)], is silly --
IMHO, of course!). Again, people who consider having a lot of
similar but subtly different things at the core of a language
a PLUS, rather than a MINUS, will of course count these "the
other way around" from how I count them:-).

Don't be misled by these comparisons into thinking the two
languages are _very_ different, mind you. They aren't. But
if I'm asked to compare "capelli d'angelo" to "spaghettini",
after pointing out that these two kinds of pasta are just
about undistinguishable to anybody and interchangeable in any
dish you might want to prepare, I would then inevitably have
to move into microscopic examination of how the lengths and
diameters imperceptibly differ, how the ends of the strands
are tapered in one case and not in the other, and so on -- to
try and explain why I, personally, would rather have capelli
d'angelo as the pasta in any kind of broth, but would prefer
spaghettini as the pastasciutta to go with suitable sauces for
such long thin pasta forms (olive oil, minced garlic, minced
red peppers, and finely ground anchovies, for example - but if
you sliced the garlic and peppers instead of mincing them, then
you should choose the sounder body of spaghetti rather than the
thinner evanescence of spaghettini, and would be well advised
to forego the achoview and add instead some fresh spring basil
[or even -- I'm a heretic...! -- light mint...] leaves -- at
the very last moment before serving the dish). Ooops, sorry,
it shows that I'm traveling abroad and haven't had pasta for
a while, I guess. But the analogy is still pretty good!-)

So, back to Python and Ruby, we come to the two biggies (in
terms of language proper -- leaving the libraries, and other
important ancillaries such as tools and environments, how to
embed/extend each language, etc, etc, out of it for now -- they
wouldn't apply to all IMPLEMENTATIONS of each language anyway,
e.g., Jython vs Classic Python being two implementations of
the Python language!):

1. Ruby's iterators and codeblocks vs Python's iterators
and generators;

2. Ruby's TOTAL, unbridled "dynamicity", including the ability
to "reopen" any existing class, including all built-in ones,
and change its behavior at run-time -- vs Python's vast but
_bounded_ dynamicity, which never changes the behavior of
existing built-in classes and their instances.

Personally, I consider [1] a wash (the differences are so
deep that I could easily see people hating either approach
and revering the other, but on MY personal scales the pluses
and minuses just about even up); and [2] a crucial issue --
one that makes Ruby much more suitable for "tinkering", BUT
Python equally more suitable for use in large production
applications. It's funny, in a way, because both languages
are so MUCH more dynamic than most others, that in the end
the key difference between them from my POV should hinge on
that -- that Ruby "goes to eleven" in this regard (the
reference here is to "Spinal Tap", of course). In Ruby,
there are no limits to my creativity -- if I decide that
all string comparisons must become case-insensitive, _I CAN
DO THAT_! I.e., I can dynamically alter the built-in string
class so that
a = "Hello World"
b = "hello world"
if a == b
print "equal!\n"
else
print "different!\n"
end
WILL print "equal". In python, there is NO way I can do
that. For the purposes of metaprogramming, implementing
experimental frameworks, and the like, this amazing dynamic
ability of Ruby is _extremely_ appealing. BUT -- if we're
talking about large applications, developed by many people
and maintained by even more, including all kinds of libraries
from diverse sources, and needing to go into production in
client sites... well, I don't WANT a language that is QUITE
so dynamic, thank you very much. I loathe the very idea of
some library unwittingly breaking other unrelated ones that
rely on those strings being different -- that's the kind of
deep and deeply hidden "channel", between pieces of code that
LOOK separate and SHOULD BE separate, that spells d-e-a-t-h
in large-scale programming. By letting any module affect the
behavior of any other "covertly", the ability to mutate the
semantics of built-in types is just a BAD idea for production
application programming, just as it's cool for tinkering.

If I had to use Ruby for such a large application, I would
try to rely on coding-style restrictions, lots of tests (to
be rerun whenever ANYTHING changes -- even what should be
totally unrelated...), and the like, to prohibit use of this
language feature. But NOT having the feature in the first
place is even better, in my opinion -- just as Python itself
would be an even better language for application programming
if a certain number of built-ins could be "nailed down", so
I KNEW that, e.g., len("ciao") is 4 (rather than having to
worry subliminally about whether somebody's changed the
binding of name 'len' in the __builtins__ module...). I do
hope that eventually Python does "nail down" its built-ins.

But the problem's minor, since rebinding built-ins is quite
a deprecated as well as a rare practice in Python. In Ruby,
it strikes me as major -- just like the _too powerful_ macro
facilities of other languages (such as, say, Dylan) present
similar risks in my own opinion (I do hope that Python never
gets such a powerful macro system, no matter the allure of
"letting people define their own domain-specific little
languages embedded in the language itself" -- it would, IMHO,
impair Python's wonderful usefulness for application
programming, by presenting an "attractive nuisance" to the
would-be tinkerer who lurks in every programmer's heart...).

Alex Martelli

Alex Martelli is a python encyclopedia..

http://www.aleax.it/python_mat_en.html

New Year's Python Meme

So I'm a bit late to the party, but there's meme going around python developers to discuss what they've done/discovered in the past year in a q/a manner. So here's mine.

1. What’s the coolest Python application, framework or library you have discovered in 2009 ?

Would have to be Twisted. I've avoided Twisted for a while now since I was always told that it'd hurt your head if you tried to get into it and that it wasn't very pep8 friendly, but it turns out it has some pretty good tutorials (the Finger tutorial) and that a lot of the stuff is useful right off the bat (such as the chatserver).

Non-Python:
The Lua language. It's not that it's all that cool, it's just another language and not as nice as python, but it's pretty cool in that it lets you create mods for games pretty quickly (in this case Demigod.. which is a great game that needs some help at this point).

2. What new programming technique did you learn in 2009 ?3. What’s the name of the open source project you contributed the most in 2009 ? What did you do ?
New programming technique would have to be constructor patterns that I learned from a very good Flash developer and the Refactoring book that he introduced me to. I mainly learned it by working through the refactoring example with my girlfriend on a automation project she had for her work.

The open source project I contributed the most to would have to be the PIL and python-payflowpro and only in the sense that I submitted bug reports (tho I submitted work around code for the issue with PIL).

For 2009, I worked entirely on two large web projects. One an online trivia game, and the other a credit offset reseller site. The credit offset site was fantastic in that the code was completely developed with TDD and had about 10-15 tests per function. I didn't start a single class or function without having the test code written beforehand. The trivia game had the potential to be fun, but I had to make accommodations for stupid managers and constant changes to what was wanted. I simply should have said 'No' more often, but it's hard to do when your excited and want to make everything cool.

4. What was the Python blog or website you read the most in 2009 ?

I read Planet Python which is an aggregation blog of a bunch of well known Python bloggers... so I guess I've been reading lots of blogs. Also, lots of StackOverflow.

5. What are the three top things you want to learn in 2010 ?

3 things for python in 2010?

1. Hadoop and map/reduce. I'm already familiar with the concepts, but I'd like to get some actual experience with it
2. pyGTK and pyGame. I'd really like to get into gui programming.. even tho cli rules.
3. Ctypes.. I've been meaning to read up or do a tutorial on ctypes for a long time.

Non-Python:

1. How to make mods for games (in particular, Demigod). For a long time I've played games and kept notebooks on what was cool, what was stupid and what I would do differently in the hopes that I would eventually learn how to create a mod of a game. I've been investing a lot of time in games and there's a lot of stuff that I'd like to tweak. Demigod is very open to modding with the Lua language so I'd like to finally start and complete a mod for a game.
   

How to uninstall python packages with easy_install.

`easy_install -m packagename` removes the file from your .pth file (and therefore removes it from your python path), then remove .egg file or directory from your site-packages, or dist-packages directory.


Thx to PJE via PL

Adding a field to the django auth user.

I've been trying to do this for a while and I keep finding how-to's such as Extending the Django User model with inheritance, but the problem with these methods is that you still cant sign-in to the django admin with any users you create (such as the admin you set up at the beginning of the project).

I finally got the monkey-patching method to work by doing the following.

You can add fields to the user class with the method add_to_class instead of inheriting the User class by doing the following in your models.py:

User.add_to_class('new_field', models.BooleanField(default=False))

Once that is done, in admin.py, modify the UserAdmin and add your new field

from django.contrib.auth.admin import UserAdmin

UserAdmin.list_display += ('new_field',)
UserAdmin.list_filter += ('new_field',)
UserAdmin.fieldsets[1][1]['fields'] = ('first_name','last_name','email','new_field')

Voilà, with that done, you're new fields should show up in the auth user on the django admin page.

TypeError: not enough arguments for format string

Got this error in some python code the other day:

TypeError: not enough arguments for format string

Essentially it means you have something like the following in your code:

"%s,%s,%s" % ('foo','bar')

Essentially it's saying there aren't enough strings to fill the placeholders. But it also means that there might be an errant % in the template string that you weren't anticipating such as:

"%s has 42% of the shares." % ('Bob')

which is annoying. A regex you can run on your code to roughly handle this is:

regex1 = re.compile('%(?![\(])')
regex2 = re.compile('%%+')
cooked_html = regex1.sub('%%', regex2.sub('%', raw_html))

I say roughly since if you're starting to run into these kinds of situations, you really need to start using a templating engine like jinja or mako. I'll switch to mako in the future.

RESTful Framework? ORM + CMS + Gateway Interface

Django works for RESTful backends to a flash frontend, but it's orm isnt that great and I'm not using the nice templating engine anyway. Its CMS on the other hand is killer.

I'm looking into what I can replace django with, ala cart like.

• ORM - SQLAlchemy
• CMS - FormAlchemy?
• Gateway - Werkzeug? CherryPy?

Werkzeug so far looks to be REALLY nice. I define 'application' in a file and then point WSGIScriptAlias to it in my apache conf and it works (granted I take in and return the correct values).