Planet Python

27.13. inspect — Inspect live objects — Python v2.7.5 documentation

The inspect module comes as part of the standard library of Python. It allows you to inspect live objects at run time by using its methods.

Here is an example:

import inspect
class Bar( object):
    def foo( self ):
        print "in Bar.foo 4"
        self .a = 1
        self .di = { 'b' : 2, 'c' : 3 }
        self .li = [  4, 5, 6 ]

bar = Bar()
bar.foo()
for member in inspect.getmembers(bar):
    print member

Running the above code gives this as (partial) output:

in Bar.foo 4

('__dict__', {'a': 1, 'li': [4, 5, 6], 'di': {'c': 3, 'b': 2}})
('__doc__', None)
('a', 1)
('di', {'c': 3, 'b': 2})
('foo', bound method Bar.foo of __main__.Bar object at 0x4035bfac)
('li', [4, 5, 6])

This shows both the bound methods and the member variables of the instance bar.

The inspect module can do a lot of other things too. Check the docs for it, linked at the top of this post.

You can also modify and run the above code snippet at this codepad.org URL:

http://codepad.org/dMLmkhQ6

It may not last there for too long, though, since they probably delete pastes to make room for new ones.

- Vasudev Ram
dancingbison.com

Vasudev Ram

Do you use PostgreSQL and truly believe it’s “the world’s most advanced open source database” and that its upcoming 9.3 release will make it even more awesome?

Do you also use Python and believe it’s “an easy to learn, powerful programming language” with “elegant syntax” that makes it an ideal language for developing applications and tools around PostgreSQL, such as Pyrseas?

Then we could use your help. For starters, we want to add support for the MATERIALIZED VIEWs and EVENT TRIGGERs coming up in PG 9.3.

We have also been requested to add the capability to load and maintain “static data” (relatively small, unchanging tables) as part of yamltodb, so that it can be integrated more easily into database version control workflows.

And for the next release, Pyrseas 0.7, we’d like to include the first version of the database augmentation tool which will support declarative implementation of business logic in the database–starting off with audit trail columns. Some work has been done on this already, but it needs integration with the current code and tests.

Or perhaps coding is not your forte, but you’re really good at explaining and documenting technical “stuff”. Then you could give us a hand with revamping the docs, maybe writing a tutorial so that users have a smooth ride using our tools.

Or maybe you have your own ideas as to how improve the PostgreSQL version control experience. We’d love to hear those too.

If you’d like to help, you can fork the code on GitHub, join the mailing list and introduce yourself, or leave a comment below.

Filed under: PostgreSQL, Python, Version control

It’s that time again! Planning for PyCon 2014 is well underway, and we’re currently preparing for the launch of our new site. With the launch comes a unique opportunity: Is your organization interested in being a launch day sponsor?

PyCon 2013 launched on July 9, 2012 with 21 sponsors pledging support, leading the charge that drew over 150 organizations to pitch in to the biggest and best Python conference yet. We’re planning a similar go-live date for the 2014 site, and we’re building up our cadre of supporters for the April 9-17 conference taking place in Montreal, Quebec, Canada.

Your organization’s support enables PyCon to do the awesome things. 2013 introduced a number of new events suggested by the community, so we’d like to keep doing those things and more. For example, the inaugural Young Coders tutorial was such a hit that there are already plans around the world for user groups to replicate it, and we’re looking forward to doing a PyCon 2014 rendition. Programs like Financial Aid, which saw its budget increased and then quickly doubled to reach $100,000 USD, are greatly enhanced by the giving of sponsors.

Along with benefiting the community, sponsorship of PyCon brings many benefits to its supporters. We hear it year after year that there is no better place to hire Python developers than at PyCon. We offer sponsors a place on our site to promote available positions, and we run a job fair on-site that has been a huge success. The Expo Hall is a great place to market your latest projects and to network with 2,000 eager Python developers. The value is unparalleled in the conference scene, especially after considering our flexibility to work with each and every organization. We even offer a 50% discount to organizations under 25 people. See https://us.pycon.org/2013/sponsors/whysponsor/ for more thoughts.

While we’re still finalizing the sponsorship prospectus, it will be very similar to the one we used in 2013 at https://us.pycon.org/2013/sponsors/prospectus/. We’ll share the details as soon as we complete them, and any questions can be forwarded to our Sponsorship Chair, Jesse Noller.

For 2014, PyCon will have a maximum capacity of 2,000 attendees. We’ve sold out the last two conferences and we’re expecting a third, so mark your calendars for April 9-17, 2014. Other dates to remember are our Call for Proposals in July, and we’re looking forward to opening registration in September. We’re planning for the conference schedule to be laid out in December, just in time for the holidays.

If you don’t have a passport, don’t forget that entering Canada requires one. US residents should see http://travel.state.gov/passport/ for details.

French translation: http://montrealpython.org/fr/2013/05/pycon-day-sponsors/

It's that time again! Planning for PyCon 2014 is well underway, and we're currently preparing for the launch of our new site. With the launch comes a unique opportunity: Is your organization interested in being a launch day sponsor?

PyCon 2013 launched on July 9, 2012 with 21 sponsors pledging support, leading the charge that drew over 150 organizations to pitch in to the biggest and best Python conference yet. We're planning a similar go-live date for the 2014 site, and we're building up our cadre of supporters for the April 9-17 conference taking place in Montreal, Quebec, Canada.

Your organization's support enables PyCon to do the awesome things that it does. 2013 introduced a number of new events that we've heard great feedback on, so we'd like to keep doing those things and more. For example, the inaugural Young Coders tutorial was such a hit that there are already plans around the world for user groups to replicate it, and we're looking forward to doing a PyCon 2014 rendition. Programs like Financial Aid, which saw its budget increased and then quickly doubled to reach $100,000 USD, are greatly enhanced by the giving of sponsors.

Along with benefiting the community, sponsorship of PyCon brings many benefits to its supporters. We hear it year after year that there is no better place to hire Python developers than at PyCon. We offer sponsors a place on our site to promote their open positions, and we run a job fair on-site that has been a huge success. The Expo Hall is a great place to market your latest projects and to network with 2,000 eager Python developers. The value is unparalleled in the conference scene, especially after considering our flexibility to work with each and every organization. We even offer a 50% discount to organizations under 25 people. See https://us.pycon.org/2013/sponsors/whysponsor/ for more thoughts.

While we're still finalizing the sponsorship prospectus, it will be very similar to the one we used in 2013 at https://us.pycon.org/2013/sponsors/prospectus/. We'll share the details as soon as we complete them, and any questions can be forwarded to our Sponsorship Chair, Jesse Noller.

For 2014, PyCon will have a maximum capacity of 2,000 attendees. We've sold out the last two conferences and we're expecting a third, so mark your calendars for April 9-17, 2014. Other dates to remember are our Call for Proposals in July, and we're looking forward to opening registration in September. We're planning for the conference schedule to be laid out in December, just in time for the holidays.

If you don't have a passport, don't forget that Canada requires one. US residents should see http://travel.state.gov/passport/ for details.

Principle philosophy: a way to discuss our rules and beliefs that govern our actions. He tells it from his personal experience.

His parents wanted to raise him as a good person. So they thought him good principles (like don't be a quitter, don't steal, etc). This is quite black/white though. We are all more gray/gray.

What about the question "how can I be a good programmer"? Programmers use logic, which sounds black/white again: write tests, don't repeat yourself. Sigh.

Talking about things like this is impossible without Immanuel Kant. He differentiates between reason and instinct. If "be happy" were our life goal, we'd just follow our instincts. So what is reason for, then, apart for doing good? Reason has to do with moral. There are three ways of looking at "doing good":

• Duty. Good things can come from duty. Duty can also lead to non-good things, though. Hm, so this is not it.
• Make a difference between the goal and the outcome. The outcome might be bad even though the goal could be worthy.
• Universal lawfullness. Only do something if you know that everybody thinks it is a good idea.

Does this help with a question like "is testing good"?

Gandhi said that a man is the sum of his actions.

In a sense we are the sum of our experiences. So increase the amount of experience that you have. Either have the experiences yourself, or share them like on this conference. Everything looks different from the trenches: learn from eachother.

Some lessons he learned from a little baseball league experience (where he sucked) as a kid:

• Swing for the fences. Aim for a home run. It allows you take great risks (because you have great goals). It motivates you.
• Set reasonable goals, too. Incremental intermediate goals. Those intermediate goals help you progress.
• You suck... and that's totally OK. You're not good at everything. It gives you a different perspective. And you can still give it your best. Also to that almost-unused old project that you get a bug report for.

Some take-aways:

• Build a strong foundation of principles.
• One size doesn't fit all
• Learn from your experiences and share them.
• Build a great network.
• Ask all the right questions.

We're pleased to announce PyPy 2.0.1. This is a stable bugfix release over 2.0. You can download it here:

http://pypy.org/download.html

The fixes are mainly about fatal errors or crashes in our stdlib. See below for more details.

What is PyPy?

PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7. It's fast (pypy 2.0 and cpython 2.7.3 performance comparison) due to its integrated tracing JIT compiler.

This release supports x86 machines running Linux 32/64, Mac OS X 64 or Windows 32. Support for ARM is progressing but not bug-free yet.

Highlights

• fix an occasional crash in the JIT that ends in RPython Fatal error: NotImplementedError.
• id(x) is now always a positive number (except on int/float/long/complex). This fixes an issue in _sqlite.py (mostly for 32-bit Linux).
• fix crashes of callback-from-C-functions (with cffi) when used together with Stackless features, on asmgcc (i.e. Linux only). Now gevent should work better.
• work around an eventlet issue with socket._decref_socketios().

Cheers, arigo et. al. for the PyPy team

A plane flew over (noisily) at the start of his presentation. He put our work in perspective by saying that that was a 80 ton plane and that we're just building websites :-)

Possibilities

Computers used to take up whole rooms, now you have a smartphone. Big data is really big data now. Moore's lawworks both ways, though, so you have really small computers now. An arduino for instance.

He often makes comparison to the human body. All over our body, sensors give off signals that go into the central nervous system. The brain processes it and gives signals back to muscles if necessary. Sensing, feedback, understanding, reaction.

Stuff can talk to the cloud. Like a sensor in your body talks to your mind, stuff can treat the cloud as a brain. The cloud is what allows small tools to be smart.

Stuff does often need a human to interact with it. Like a smartphone. There's all sorts of people thinking about how to "liberate the computers from their human overlords". Why cannot computers sense and act on their own account?

So how do you bridge the gap betwen sensing and acting of stuff? How do you use Django for it? There's a lot available online about sensing and about acting, but not the communication in between.

The communication medium itself is a bit of a problem. You don't want to have a telephone data contract for every single small piece of stuff. A physical connection isn't always handy either.

His preferred communication medium is Twilio for sending SMSs. The stuff has low memory, so the message length limit is fine.

He showed a demo with a card reader that read his London transport card and sended an SMS to his Django site. The card reader was a combination between an arduino, a 'shield' sms sender and an RFID reader. The django app then submits it to foursquare. (The last part didn't work, probably due to a local foursquare problem, but the django app did have all the data he send from his card reader). Nice.

SUCCESS: after the lightning talks he did it again and now it worked!

Personal development

He had never done any hardware work until four months ago. No compiling for arduino. It sounded a bit scary to him.

It is normal, if you start as a beginner, you're slowly getting better if you keep at something. Then you automatically learn more and thus learn that there's a lot you don't know. That's the dip in the middle. Those are the people we need to keep on board so that they push through to the expert stage.

When you're in the middle, you know how bad you are (or how good you aren't yet). That's the risky phase were people quit.

Likewise documentation. Tutorials are useful for beginners. Reference material is useful for experts. There's not a lot in the middle and you're bound to be a bit frustrated in that stage.

So if you're going to start experimenting with electronics, you're bound to hit a wall, for instance when calculating complex electronic schemas. Push on anyway: the first time you make a phone call with your own device is totally worth it.

Two books he recommends to get you started:

• Getting started with Arduino.
• The art of electronics.

He shows us three kinds of (more or less) open source projects.

Type 1: public source

Once upon a time there was an "open source project" called the facebook SDK. Basically it just stopped working one day and nobody could help, despite offers for help on the issue tracker. Hacker news got wind of it and it was on the front page for a while. Facebook's reaction? Disabling the issue tracker... (Later on they fixed it).

That's not open source, that's public source. Often it is abandoned due to loack of interest, change of focus or so. The motivation for having it as open source simply is not clear.

Type 2: shared investment

A different example: gittip. They aim to be the world's first open company. There's a github issue for everything, even the company name. Major decisions are voted for on github. The code is open source, of course. All interviews with journalists are filmed and live-streamed. And all otherwise-often-backdoor-cooperation-agreements are fully open.

Projects like gittip are shared investment projects. Shared ownership, extreme transparency. There is very little questioning of motivations. The motivation is clear and public. There's a documented process for new contributers. The advantage? It is low risk. There's a high bus factor.

Type 3: dictatorship project

Kenneth is the author of requests. An open source project, very succesful. But all the decisions are made by Kenneth.

That's really more of an dictatorship project. A totalitarian BDFL that owns everything. The dictator is responsible for all decisions. Requests' values lie in its extreme opinions. If he'd involve more people, the value would be dilluted. There are drawbacks. A low bus factor. High risk of burnout: Kenneth is the single point of failure.

Lessons learned

• Be cordial or be on your way. As a user, you need to keep all your interactions with the maintainer as respectful as possible. The maintainer put a lot of work in it and they don't owe you any of their time.

  As a maintainer, you also must be cordial. Be thankful to all contributions. Feedback is the liveblood of your project, even the negative. You'll need to ignore non-constructive comments. Be careful with the words you choose, sometimes contributors take what you say VERY personally. You might have to educate your users. And: a bit of kindness goes a long way.

• Sustainability is almost the biggest challenge. Don't burn out. Try to get others to help.

  He quotes Wes Beary: "open source provides a unique opportunity for the trifecta of purpose, mastery and autonomy". Pay equal attention to all of these three. Learn to do less, focus more on your purpose, for instance.

• Learn to say no. People ask for crazy features. Or they submit quite sane pull requests that, if you allow them all in, makes your project slow and unfocused. Kenneth wants as few lines of codes in his project. Negative diffs are the best diffs!

• Open source makes the world a better place. Don't make it complicated!

Metaclasses are a handy feature of Python and Django makes good use of them.

When you create certain kinds of classes in Django, a metaclass will do something to the class before it is created. For forms, the various attributes of the class are converted into a base_fields dictionary on the class.

Similarly, a subclass of Model also fires up a metaclass that does some registering. A foreignkey to another model adds a relation back on that other model, for instance.

As a recap, a class is something that can be instantiated into an object. It can have an __init__() method that does something upon instantiation. type(your_instance) will return the class.

Did you know that you can create classes dynamically? See for yourself:

>>> name = 'ExampleClass' >>> bases = (object,) >>> attrs = {'__init__': lambda self: print('Hello from __init__')} >>> ExampleClass = type(name, bases, attrs) >>> example = ExampleClass() Hello From __init__ >>> type(example) <class '__console__.ExampleClass'>

So... we can actually control how classes are created! You could create a create_class() method that calls type but that modifies, for instance, the name. Or we could take all the attributes and add them to a base_fields dictionary on the instance. Hey, that's what we saw in the first Django form example!

Now, what is type exactly? It is a class that creates classes.

This also means we can subclass it! The most useful thing to override in our subclass is the __new__() method. The __init__() method creates instances from the class, the __new__() creates classes. So again we can modify the name and/or the attributes.

How do you use it in practice? Normally you'd set a __metaclass__ attribute on a class. This tells python to use that metaclass for creating the class. The same for subclasses. This is how our Django form classes use the metaclass specified in Django's base Form class.

Django uses metaclasses in five places: admin media, models, forms, formfields, form widgets. Grep for metaclass in your local django source code once to get a better feel for how Django uses it.

Note on python 3: it uses a slightly different syntax for specifying metaclasses. So Django 1.5 uses six to support both ways in a single codebase.

Warning: don't overuse metaclasses. They can make code difficult to debug and follow. Use Django as a good example of how to use metaclasses. Django saves you a lot of work by using metaclasses in a few locations.

See https://github.com/inglesp/Metaclasses

Nice way of giving a presentation, btw. Some sort of semi-interactive python prompt. The software is online at https://github.com/inglesp/prescons

Amjith Ramanujam recently wrote a thread profiler in Python and it was rediculously simple. He works for New Relic, which is all about performance and expecially performance measuring.

Python comes with batteries included, so it also includes a C profiler that works pretty well. But it doesn't work nice for django because the output is so huge. If you use the GUI RunSnakeRun, it is more managable that way.

Additional problem with cProfile: it has about 100% overhead, so you can't run it in production (which they need).

You can do more targeted profiling. For instance in Django. The way a web framework processes requests is normally always in the same way. You can use that during profiling.

There are two important stages: interrupt and inquire.

Interrupt

A statistical profiler looks how often a function is called and by who. For this it needs to interrupt the regular process. You could set an OS-level signal to call your profiler every x miliseconds so that it can do something. It only works in linux, btw. Another way is to create a python background thread that wakes up every x miliseconds. It is cross-platform and mod_wsgi compatible. It is less accurate for CPU tasks and it cannot interrupt C extensions.

Inquire

You can use sys._current_frames() to get yourself the frames ("stack trace") from the current thread. Here you can extract the filename, line number and so of the most interesting frames. He's building a "call tree" structure, mapping how often a function is called, preserving the parent/child relation between functions. The tricky part was visualizing it :-) In the end they did it with d3.js.

There's some 3% overhead in the thread approach, so that's real good. They can switch it on for a type of request and it'll profile the next 100 requests of that type.

Brandon Rhodes mentions Nicolai Kopernik, a famous Polish scientist. He "lifted Earth into Heaven" by his book where he put the sun in the center of our universe instead of Earth. We're no longer at the bottom.

The near-earth environment was pretty well mapped out. 300BC, the size of the spherical earth was already known. Around 100BC the distance to the moon was known.

But what about those planets? They were harder. Stars did move around the sky more or less linearly. But those planets. They seemed to move back and forth a bit. Did they need to have a different model? The sun-centric model was already known, but it didn't catch on. The reason? Medieval science was too emperic: the earth cannot be moving, it seems to stay in place. Throw a ball and it falls down again towards the earth, it doesn't career off into space. The church wasn't totally idiotic by later convicting Galileo: there was just no solid emperical evidence :-)

One of the pieces of evidence that was missing was that there was no observable stellar parralax; visible movement between stars because of earth movement. It was only in 1838 that the instruments were good enough to actually observe parralax. Only then did we figure out how far away the stars were. So it took 200-300 year to get real evidence.

So why did Kopernik trust his theory despite the lack of evidence? Because of beauty. Brandon showed Kopernik's theory as Python code; an algorithm for planet movements. And showed his theory as a code refactoring. The end result was quite simple and nice once you factored out Earth's motion. The code looks nicely ordered.

There's truth in beauty.

Brandon proposes a new term: Kopernican refactoring: making a system simpler by moving something new into the center.

It is so easy to behave according to a rule that's not even really there. You look at a problem in a certain way and you're stuck. Once you put something else in the center, you look at the problem in a different way.

For instance, you can use argparse to generate a help message when you pass --help. You can also do it the other way around: using docopt which generates a parser from your help message! You get a much nicer help message.

So if you're stuck, think of Copernicus and his refactoring.

His goal: teach programmers to be more creative.

He's got a love/hate relationship with creativity. The first part of his talk was impossible to summarize. You'll have to watch the video later on :-)

• Artists tell him he's not artistic because he works on developing technical skills.
• Guitarists tell him he's not a real guitarist as he doesn't play in a band. And 'cause he builds his own guitars he's a programmer, not a Real Guitarist.
• Writers tell him he's not a writer because he writes technical books.
• Programmers tell him he's not a programmer because he doesn't work on their project. And by the way, he's a (technical) writer now, so he's not a programmer.

He's not creative enough. Or so the others say. Or he's not acceptable. How to deal with creativity? In a way, you can re-phrase creativity. Programmers are always making something from nothing, right? Isn't that the pinnacle of creativity?

Here are four hypothetical persons:

• Technique, no imagination: a stereotypical programmer.
• Imagination, no technique: stereotypical biz dude.
• No imagination, no technique. Probably doesn't exist.
• Both imagination and technique. Zed's goal.

Zed's imaginative programmer process. Everyone has a process (if they're good), here's the one he proposes to help you be more creative:

• You start with an idea.
• You establish a concept that helps form the idea. It gives your idea clothes.
• Research techniques or tools. Do some research or you'll pay for it later on.
• Refine the concept through composition. So put a box around the vast world of available possibilities. Just mark which features are inside and outside the concept.
• Explore through prototypes. Throw away code or use paper prototypes for instance. This saves you so much time later.
• You make it real.

We are programmers, so we should iterate this process.

He tried this process with http://projectzorn.com/, going through all the stages. And he's probably going to work on it

He started with a little history lesson. The sea battle of mobile bay. The admiral (Faragut) ordered the ships straight through the minefield (called "torpedoes" at the time). "Damn the torpedoes, full speed ahead". And it worked.

What does this to have to do with Django? Well, "damn the torpedoes, full speed ahead" feels a bit like how rapid prototyping feels afterwards. He's often involved with hackathons. Lot of quick coding in limited time with a lot of people. He learned a lot about his tools that way (and he often used Django).

There's a time to make a distinction between production and prototype. Sometimes it is better to just try something with a prototype. Throw-away code.

Aaargh! Throw-away code?!? We never throw code away. But it is something we must learn. It is good to let go once in a while. Let your code go. It isn't yourself, it is just some code.

The danger is that prototype code is put into action as production code. With some work, this danger can be prevented.

What about Django? Django is the best for prototyping. For rapid prototyping, Django is better than micro-frameworks like Flask that might seem better at first glance. Here are some reasons:

• Django was build for rapid prototyping. It originated at a newspaper! 24 hours to build something.

• It is flexible. It was build to bend. He can prepare something for the other people programmign with him and get them going and still keep the code in reasonable shape.

• Us. The strength of Django is the community that supports it. Stack overflow questions and answers. The django websites. Books like two scoops of Django (see my review). That's not something you have with many other frameworks!

  Tip: read especially chapter 2 and 3 of the two scoops book.

  One thing he'd add to the book is stuff like fabfiles and makefiles. Handy for rapid prototyping.

Use stuff that's available. For instance Django's staticfiles app for grabbing together all the css/js/png. Whether it is in one directory or split out over multiple apps. It also helps with production.

Also look at brunch for setting up your javascript app's structure. It works well with Django.

Deployment: you need to show your prototype. Heroku is very quick for prototypes. (He mentioned that they have a data center in Europe now in case you need it).

Deployment: use chef. Lots of recipes. You could also use Salt if you're more into Python. Also lots of stuff available. Both take a while to learn, but it is a very good investment.

Configuration management is an extremely useful skill. Do it well.

Tastypie is the quickest way to get a REST api out of your Django. It is the best for rapid prototyping. Another good one is django-rest-framework. It will take a little bit longer to set up, but once done you're working with actual Django views. And django-rest-framework's browseable API is very helpful when you're working with a couple of others

Social auth connectors: everyone makes one and there are way too many half-working ones. He's got two that he can recommend. django-social-auth is very complete. The other is django-allauth for when speed is important for you.

If you don't want to play fair to others during a hackathon: use celery. It is very unfair to use celery, python and Django. The combination with Django is pretty OK to set up. You can do a lot what others cannot do easily. So use it for rapid prototyping. (Regarding setting it up: there are good chef recipes for it).

TEST. Yes, even during a hackathon. He doesn't advocate full test driven development. It is a balance. But the errors that kill you during a hackathon are the errors you make twice. So, for instance, test that all your views simply return a 200 Ok. This already helps prevent a lot of problems.

Look at AngularJS. Even if you don't use the framework itself. Why? It has a great javascript test runner. Good for testing while rapid prototyping.

I am excited to announce that my book, Write Your First Program is finally available for public consumption. In this day and age, when there are easily accessible programming books galore (in the context of both, price and availability), why write a new book? Through this post, I hope to reach out to the prospective readers and […]

Python offers many different template engines for web application development to turn your view logic to HTML code on the server and then send the resulting HTML code to a web browser. When you are dealing with complex page templates, especially when using third party libraries, it often gets confusing what template context variables are available and what they have eaten.  In this case, the best method of debugging is to insert a breakpoint into your page template and inspect the variables in runtime context. This very useful “advanced” debugging method is not known to many people, especially if they come from the background where command-line debugging tools have not been the norm.

Table Of Content

1. Python debugging

2. Setting a breakpoint in Django templates

3. Other templating engines

1. Python debugging

Python offers pdb command-line debugger out of the box. I recommend to use more advanced version ipdb, which comes with proper command history, colored tracebacks and tab completion / arrow key support (though there seems to be an issue using ipdb with multithreaded / autoreloading programs). There also exist more GUIful, but still terminal based, pudb. Eclipse + PyDev offer remote debugging support with full GUI.

Read some command-line debugging tutorials if you are not familiar with the concept. Especially how to inspect local variables with commands of locals(), dir(object), for i in dict.items(): print i come to hand.

2. Setting a breakpoint in Django templates

Here is an example how to create a breakpoint tag for Django templates and then go around and debug your templates. In the example, I debug the field rendering look of django-crispy-forms.

First we need to create a custom Django template tag invoking pdb, because you cannot run arbitrary Python snippets directly from Django templates. The code here is based on the example on djangosnippets.org.

templatetags/debug.py

# -*- coding: utf-8 -*- # # http://djangosnippets.org/snippets/1550/ # import pdb as pdb_module from django.template import Library, Node register = Library() class PdbNode(Node):     def render(self, context):         pdb_module.set_trace()         return '' @register.tag def pdb(parser, token):     return PdbNode()

Then we use this tag our template:

{% load crispy_forms_field %} {% load debug %} {% if field.is_hidden %}     {{ field }} {% else %}     <div>         <div>             {{ field.long_help }}             {% pdb %}         </div>     </div> {% endif %}

We run Django normally with manage.py runserver and encounter this breakpoint when rendering a template.

Now we can go around and see what variables are avaialble in the template and what they have eaten.

(Pdb) locals().keys() ['self', 'context'] (Pdb) context.__class__ <class 'django.template.context.RequestContext'>

Ok, so we have available template variables in a local variable called context (makes sense, we are now in our templatetag.py code).

(Pdb) for i in dir(context): print i ... _reset_dicts autoescape current_app dicts get has_key new pop push render_context update use_l10n use_tz

There seems to be a way to access all template variables:

(Pdb) for d in context.dicts: print d.keys() [] ['csrf_token'] ['request'] ['perms', 'user'] ['debug', 'sql_queries'] ['LANGUAGES', 'LANGUAGE_BIDI', 'LANGUAGE_CODE'] ['MEDIA_URL'] ['STATIC_URL'] ['TIME_ZONE'] ['messages'] ['downtime'] ['block'] ['flat_attrs', 'inputs', 'csrf_token', 'form_id', 'form_error_title', 'form_action', 'error_text_inline', 'html5_required', 'help_text_inline', 'formset_error_title', 'form_style', 'form_method', 'form_show_errors', 'is_formset', 'form_tag', 'attrs', 'form_attrs', 'form_class']

Now we can see what come through to our template as the field and widget in the field rendering loop.

(Pdb) context["field"] <django.forms.forms.BoundField object at 0x1038ae590> (Pdb) for i in context["field"].__dict__.items(): print i ('html_initial_name', u'initial-ad-xxx_type') ('form', <xxx.Form object at 0x103064c10>) ('html_name', 'ad-xxx_type') ('html_initial_id', u'initial-ad-id_ad-xxx_type') ('label', u'Foobar') ('field', <django.forms.fields.TypedChoiceField object at 0x103062e50>) ('help_text', '') ('name', 'xxx_type')

And after you see this, you can figure out if your data is coming through the templating stack and is it coming through correctly and what you need to do in order to bend it to your will.

3. Other templating engines

See also an example for Chameleon templates. Unfortunately Plone, out of the box, cannot support this debugging method due to the security.

 

 

 

 Subscribe to this blog in a reader Follow me on Twitter Follow me on Facebook Follow me Google+

The Python standard library comes with a module called wave.py. It allows you to read and write WAV format audio files.

Here is an example of reading WAV file info with Python:

import wave

wavf = wave.open('horse.wav', 'r')
print wavf.getnchannels()
print wavf.getsampwidth()
print wavf.getframerate()
print wavf.getnframes()
print wavf.getcompname()

The above code prints the number of channels (mono or stereo), the sampling width, the frame rate, the number of frames, and the name of the compression type (if any) of the WAV file horse.wav.

You can also write WAV files, but you need to know what data to write.

Wikipedia entry for WAV:

http://en.m.wikipedia.org/wiki/WAV

- Vasudev Ram
www.dancingbison.com

Vasudev Ram

This is summary of the Debugging chapter in The Practice of Programming by Brian Kernighan and Rob Pike. It was an absolute pleasure for me to read this paragraph, I have spent tons of time in debugging issues both in CPython and at work. The master programmers provide a great insight into the process of Debugging.

With the right attitude debugging can be fun, like solving a puzzle, whether we enjoy it or not, debugging is a art that you need to practise regularly. Still, it would be nice, if bugs didn't happen, so we try to avoid them by writing code well in the first place. Well written code has fewer bugs to begin with and those that remain are easier to find. Once a bug has been seen, the first thing to do is to think hard about the clues it presents. How could it have come about? Is it something familiar? Was something just changed in the program? Is there is something special about the input data that provoked it? A few well chosen test cases and few print statements in the code may be enough. If there aren't any good clues, hard thinking is still the best first step, to be followed by systematic attempts to narrow down the location of the problem. One step is cutting down the input data to make a small input that that fails; another is cutting out code to eliminate regions that can't be related. It's possible to insert checking code that gets turned on only after the program is executed some number of steps, again to try to localize the problem. All of these are instances of general strategy, divide and conquer, which as effective in debugging as it is politics and war. Use other aids as well. Explaining your code to someone else (even a teddy bear) is wonderfully effective. Use a debugger to get a stack trace. Use some of the commercial tools that check for memory leaks, array bound violations, suspect code and the like. Step through your program when it has become clear that you have the wrong mental picture of how the code works. Know yourself, and kinds of errors you make. Once you have found and fixed a bug, make sure you eliminate other bugs that might be similar. Think about what happened so you can avoid making that kind of mistake again.

And finally there was statement in the chapter which is very sums up what a good bug writing technique is.

Send the kind of bug report you'd like to receive yourself.

The Montreal Python team would like to invite you to two very special events regarding OpenStreetMap, the mapping project based on open data that anyone can edit.

First, on Wednesday May 22nd at 7:00pm, there will be a workshop on editing OpenStreetMap. This workshop will be held at Caravan Coop, located at 5334 rue de Gaspé. For more information and to register to the event, please visit http://www.eventbrite.ca/event/6553739411

Second, on Sunday June 2nd at 1:00pm, we invite you to an onsite mapping experience. The goal of this “mapping party” is to ensure the quality of the map in the neighbourhood of the Palais des congrès de Montréal. For more information and to register to the event: http://www.eventbrite.ca/event/6554826663

Why map the neighbourhood of the Palais des congrès?

You most certainly know that Montreal will be the host of the next PyCon in 2014, and that the Montreal Python’s team plays a central role in the event organization. About 2500 people are expected at the Palais des congrès in April 2014, and we would like to welcome them with due honor. To that effect, we wish to provide attendees an in-depth map of the surroundings of the Palais, to inform them of the various restaurants and shops to visit.

On a different matter, but still regarding PyCon 2014, we have begun an Insider’s Guide for the attendees: https://github.com/PyCon/2014/wiki/Insider’s-guide. We would like to have your feedback. If you know good restaurants or fun activities to do in Montreal, please write us at pycon-montreal@googlegroups.com.

So, what do you think? Ready for the adventure?

Python 3.2.5 and Python 3.3.2 regression fix releases have been released.