txAMQP

What is the gain from parsing XML specs on every program invocation?

Asked by Alexey

Why should python objects be regenerated from XML every time program starts?
Why not translate every possible XML spec file into python code once and use that?
Shouldn't that be faster?
Shouldn't that be clearer?
In the absence of documentation, static python code will be easier to read and dig into, IMHO.
At last, what about autogenerated code audit?

Question information

Language:
English Edit question
Status:
Solved
For:
txAMQP Edit question
Assignee:
No assignee Edit question
Solved by:
Esteve Fernandez
Solved:
Last query:
Last reply:
Revision history for this message
Best Esteve Fernandez (esteve) said : 		#1

> Why should python objects be regenerated from XML every time program starts?
> Why not translate every possible XML spec file into python code once and use that?

Because nobody wrote a patch for it! :-) I have a branch sitting in my laptop, where I started some work for dumping the autogenerated Python into text, but it's not recent. We have it planned, but it has a very low priority for now, if you want to send a patch, we'll happily review it!

> Shouldn't that be faster?

Faster in what sense? Once the XML is turned into Python code, there's no difference. Of course, you could save some seconds at startup time, but I don't know how important it is.

> Shouldn't that be clearer?

Maybe, but don't expect it to be much clearer. When you call a method in AMQChannel, what txAMQP actually does is to call AMQChannel#invoke with the appropriate arguments, all methods look like this:

def basic_publish(...):
    self.invoke(...)

def exchange_declare(...):
    self.invoke(...)

> In the absence of documentation, static python code will be easier to read and dig into, IMHO.

There's a lot of documentation in the spec files. When the txAMQP parser could dump Python code into text, the comments in the XML files will be turned into docstrings for each method. But, in any case, you can already consult the spec files.

Revision history for this message
Alexey (a-launchpad-subscribed-udmvt-ru) said : 		#2

> > Shouldn't that be faster?

> Faster in what sense? Once the XML is turned into Python code, there's no difference. Of course, you could save some seconds at startup time, but I don't know how important it is.
Yes, I mean the startup time ofcourse.
That is really important for short-living client applications, that post one message at a time or retrieve one message at a time.

>> In the absence of documentation, static python code will be easier to read and dig into, IMHO.

>There's a lot of documentation in the spec files. When the txAMQP parser could dump Python code into text, the comments in the XML files will be turned into docstrings for each method. But, in any case, you can already consult the spec files.

Sorry, but I'm not interested in AMQP protocol documentation, but rather I'm searching the txAMQP code documentation,
which is not the same, obviously.
It is not clear, from the AMQP spec files, what classes from txAMQP are intended to be subclassed by the users, what aren't and intended to be used as is, and what classes are not for public, but are only for internal txAMQP usage.
It is not clear either, what is the intended way of installing my own callback functions to be called on various protocol events.
There are a lot of such events, like reception of acknowledgements or exceptions from server.
I'm not sure, that AMQP Working Group should provide that kind of information in their specs.
So, in the absence of such documentation, the code is the only source of it, that's why I'm so bothered to see the static code. I just want to understand how txAMQP is working by looking at it's source. Comments from XML converted to docstrings do not help in doing that.

But thanks for the answer, I think everything is clear to me on the reasons for parsing the XML every time.

Thanks again!

Revision history for this message
Alexey (a-launchpad-subscribed-udmvt-ru) said : 		#3

Thanks Esteve Fernandez, that solved my question.