Hi Python developers,
I am using python to write a testing tools, currently this tool only
supports skinny protocol. I am planning to add SIP and MGCP support as
well, wondering if you have written these protocol stacks before which
can be leveraged from.
thanks
Jenny
On Wednesday 27 December 2006 12:15, Jenny Zhao (zhzhao) wrote:
Hi Python developers,
I am using python to write a testing tools, currently this tool
only supports skinny protocol. I am planning to add SIP and MGCP
support as well, wondering if you have written these protocol
stacks before
It may have been discussed before, but there does not seem to have
been any resolution on the issue. Am I missing something or did the
discussion just kind of stop, with no solution or agreement ever
reached? In which case, reviving the question is not a bad idea, is
it?
On 12/29/06, Oleg
On Fri, Dec 29, 2006 at 09:55:46AM -0500, Calvin Spealman wrote:
It may have been discussed before, but there does not seem to have
been any resolution on the issue. Am I missing something or did the
discussion just kind of stop, with no solution or agreement ever
reached? In which case,
On Friday 29 December 2006 10:50, Oleg Broytmann wrote:
I don't remember any resolution. I think submitting a small module to
the patch tracker would be the simplest way to revive the discussion.
We have a handful of interesting descriptors we use for Zope 3 development:
On 12/19/06, tomer filiba [EMAIL PROTECTED] wrote:
to my understanding of the object model, the code of snippet 1
and snippet 2 should be equivalent. a class is just a special function
that returns its locals automatically and passes them to the metaclass
constructor:
--- snippet 1 ---
On 12/29/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
def spam():
x = 5
class eggs(object):
x = 6
def spam(self):
return x
return eggs
spam()().spam() should return 5.
the question that arises is -- is this what we wanted?
if i had to read such code, where i can't
On 12/29/06, tomer filiba [EMAIL PROTECTED] wrote:
On 12/29/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
def spam():
x = 5
class eggs(object):
x = 6
def spam(self):
return x
return eggs
spam()().spam() should return 5.
the question that arises is -- is this
Fred L. Drake, Jr. schrieb:
Speaking strictly for myself: I don't think I *have* to use them, but I do
prefer to use them because I don't like magic constants that affect what a
function does in code; I'd rather have a named constant for readability's
sake. Maybe I just can't keep enough
On 12/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Fred L. Drake, Jr. schrieb:
Speaking strictly for myself: I don't think I *have* to use them, but I do
prefer to use them because I don't like magic constants that affect what a
function does in code; I'd rather have a named constant
On Friday 29 December 2006 16:55, Guido van Rossum wrote:
If we want to make the seek API more 21st century, why not use keyword
arguments?
I'd prefer that myself. I'm not advocating the constants as a way to go
forward, but was simply expressing a preference for the named constant over a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 29, 2006, at 4:55 PM, Guido van Rossum wrote:
But my main objection to suggesting that these constants ought to be
used is that open() is a built-in but you would have to import os to
be able to call the seek method on the object it
Jeremy Kloth schrieb:
1) is subclassing Python classes in C as a static type supported? Even if
they
would be declared on the heap, they would be bound to the first loaded Python
class.
As you found out: no, this isn't supported.
To work around, you can wrap the extension module with
Jeremy Kloth schrieb:
I think you understand exactly what is happening. It is happening for
good reasons. Rather than asking for a change in semantics, I
recommend that you deal with it, either in your Python code, or in
your extension. It's not likely to change.
I don't believe I was
Brett Cannon schrieb:
I originally posted this list to python-3000 since I figured we could
be more aggressive with Py3K, but Guido said I should move it over
here and just be aggressive in 2.6.
Please follow PEP 11 in doing so. This means you cannot remove the code
in Python 2.6, only break
On 12/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Brett Cannon schrieb:
I originally posted this list to python-3000 since I figured we could
be more aggressive with Py3K, but Guido said I should move it over
here and just be aggressive in 2.6.
Please follow PEP 11 in doing so. This
Patch / Bug Summary
___
Patches : 413 open ( -7) / 3521 closed (+11) / 3934 total ( +4)
Bugs: 946 open ( +2) / 6400 closed ( +9) / 7346 total (+11)
RFE : 248 open ( -1) / 246 closed ( +1) / 494 total ( +0)
New / Reopened Patches
__
17 matches
Mail list logo
