Neal Norwitz schrieb:
> There are several failures with both the trunk and 2.5 branch. I have
> fixed one problem that allows the tests to run on Windows. That was
> fixed by reverting 54407 on the trunk. It still needs to be reverted
> on the 2.5 branch. You can go back in the buildbot logs to
[Facundo Batista]
> Remember that this function primary use is for
> higher level libraries
Yes, I see that clearly now.
But remember that by adding a new function to the socket module to
support httplib et al, you are also adding a function to the socket
module that will be used directly by end
Greg Ewing wrote:
> Gregory P. Smith wrote:
>> I prefer the default of "clean up after itself" as is to avoid leaving
>> temporary file turds on systems caused by us lazy programmers.
>
> Maybe instead of an option there should be a separate
> function with a different name, such as NewUniqueFile.
Scott Dial wrote:
> Greg Ewing wrote:
>
>> Maybe instead of an option there should be a separate
>> function with a different name, such as NewUniqueFile.
>
> I'm in favor of adding such a function.
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in TitleCase, when the
Greg Ewing wrote:
> A tangential question -- why are TemporaryFile and
> NamedTemporaryFile named in TitleCase, when they're
> functions and not classes?
>
I wondered the same. At first draft of my email I wrote "class"
operating under the assumption that only classes got to be camel-cased.
If
On 3/21/07, Scott Dial <[EMAIL PROTECTED]> wrote:
Greg Ewing wrote:
> A tangential question -- why are TemporaryFile and
> NamedTemporaryFile named in TitleCase, when they're
> functions and not classes?
>
I wondered the same. At first draft of my email I wrote "class"
operating under the assum
Alan Kennedy wrote:
> The proposed new function does not belong in the socket module. In
> contrast to all of the other socket creation and management
> functionality in the socket module, the new function does not handle
> non-blocking IO.
The rest of the socket module isn't going anywhere. If yo
Greg Ewing schrieb:
> Scott Dial wrote:
>> Greg Ewing wrote:
>>
>>> Maybe instead of an option there should be a separate
>>> function with a different name, such as NewUniqueFile.
>>
>> I'm in favor of adding such a function.
>
> A tangential question -- why are TemporaryFile and
> NamedTemporar
Alan Kennedy wrote:
> But remember that by adding a new function to the socket module to
> support httplib et al, you are also adding a function to the socket
> module that will be used directly by end users.
>
> I vote to reject this patch.
Well, you can vote to name it _create_connection(), if
Facundo> Voting is open, ;)
...
Facundo> So, as a resume of the choices we still need to settle:
Facundo> a) Repeat the same functionality in 5 other libraries
Facundo> b) Write the function in socket.py, public
Facundo> c) Write the function in socket.py, non publi
[Facundo]
> Voting is open, ;)
So what are we voting on exactly? The patch as it currently is? The
patch has not been updated to reflect recent discussions on the list.
Will the patch be updated before the vote?
I have one more issue with the patch.
I think that the exception handling in the fun
Georg Brandl wrote:
> Greg Ewing schrieb:
>
>> Scott Dial wrote:
>>
>> A tangential question -- why are TemporaryFile and
>> NamedTemporaryFile named in TitleCase, when they're
>> functions and not classes?
>>
>
> Probably because they are factory functions potentially returning a
> _T
Alan Kennedy wrote:
> I think this patch is poorly designed and poorly implemented. There
> are multiple problems in its 17 lines of socket module code; every
> time I look I find a new problem.
Code which is copied verbatim from httplib, and also occurs with slight
variations in several other st
Alan Kennedy wrote:
> So what are we voting on exactly? The patch as it currently is? The
> patch has not been updated to reflect recent discussions on the list.
> Will the patch be updated before the vote?
The voting is on a, b or c.
The patch will be updated after I know what python-dev want t
Aaron Bingham schrieb:
> Georg Brandl wrote:
>> Greg Ewing schrieb:
>>
>>> Scott Dial wrote:
>>>
>>> A tangential question -- why are TemporaryFile and
>>> NamedTemporaryFile named in TitleCase, when they're
>>> functions and not classes?
>>>
>>
>> Probably because they are factory fun
On 3/21/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> So, as a resume of the choices we still need to settle:
>
> a) Repeat the same functionality in 5 other libraries
> b) Write the function in socket.py, public
> c) Write the function in socket.py, non public
The fact that it's needed i
[Facundo]
> Talk is cheap.
I'm sorry if you see my attempts to review your patch as "cheap talk".
Maybe I should have just kept my opinion to myself.
You'll get your chance to return the favour when I check in my
upcoming 1000+ line change to jython 2.3 to bring the jython socket,
select and asyn
[Facundo]
> Talk is cheap.
I'm sorry if you see my attempts to review your patch as "cheap talk".
Maybe I should have just kept my opinion to myself.
You'll get your chance to return the favour when I check in my
upcoming 1000+ line change to jython 2.3 to bring the jython socket,
select and asyn
Facundo Batista <[EMAIL PROTECTED]> wrote:
> Alan Kennedy wrote:
> > I recommend modifying the patch to remove *all* proposed changes to
> > the socket module. Instead, the patch should restrict itself to fixing
> > the httplib module.
>
> -1 to repeat the same functionality in 5 other libraries.
[Josiah]
> In regards to 'there is no way to
> create a blocking socket this way', Alan is off his rocker.
I am not off my rocker.
And I never wrote the words you place in quotes (except in relation to
an earlier defect in the patch where the timeout=None value was
ignored).
What I clearly state
> test_posixpath is failing in: test_relpath
This is due to #1339796, r54419. I left a comment in the tracker.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
On 3/21/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > test_posixpath is failing in: test_relpath
>
> This is due to #1339796, r54419. I left a comment in the tracker.
This is my check-in. I'll have a fix shortly.
Collin Winter
___
Python-Dev mail
I updated the patch #1676823, reflecting discussion here:
- The function name changed, now it's _create_connection(). Its
signature also changed: now, timeout is mandatorily named.
- HTTPConnection has the posibility to call timeout with a number, and
also with None. In both cases, it updates so
> Patch 1490190 causes test_posix to fail on Tru64 due to chflags().
I have a potential fix for that in the tracker.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>Alan is off his rocker.
To me, this sort of ad hominen comment is anti-productive and out-of-place
in technical discussion.
"Facundo Batista" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>It's better
"| On 3/20/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
| > Brett Cannon wrote:
| > > old and had not been touched in ages. Hopefully you will be able to
| > > easily port this over to the new tracker once it's up (that should
| > > happen 2-4 weeks after 2.5.1 is released).
| >
| > You can be
On 3/21/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> >Alan is off his rocker.
>
> To me, this sort of ad hominen comment is anti-productive and out-of-place
> in technical discussion.
>
> "Facundo Batista" <[EMAIL
On 3/21/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> > So, as a resume of the choices we still need to settle:
> >
> > a) Repeat the same functionality in 5 other libraries
> > b) Write the function in socket.py, public
> > c) Write
Georg Brandl wrote:
> Aaron Bingham schrieb:
>
>> Georg Brandl wrote:
>>
>>> Greg Ewing schrieb:
>>>
>>>
Scott Dial wrote:
A tangential question -- why are TemporaryFile and
NamedTemporaryFile named in TitleCase, when they're
functions and not classes
What are the current thoughts on when Py2.5.1 will go out?
Do we need a bug-day beforehand?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
Guido van Rossum wrote:
> (like httplib before the patch), I am personally in favor of going
> back to defaulting timeout to None and skipping the settimeout() call
> in _create_connection() if timeout is None. IMO the use case where
> there is a global timeout set and one library wants to overrid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 21, 2007, at 1:51 PM, Raymond Hettinger wrote:
> What are the current thoughts on when Py2.5.1 will go out?
> Do we need a bug-day beforehand?
That might not be a bad idea. I've been working on some email
package fixes in the background. W
On 3/21/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > (like httplib before the patch), I am personally in favor of going
> > back to defaulting timeout to None and skipping the settimeout() call
> > in _create_connection() if timeout is None. IMO the use case where
Facundo Batista wrote:
> It works, but my only issue is that it gets ugly in the help():
>
> >>> sentinel = object()
> >>> def f(a, b=sentinel):
> ... pass
> ...
> >>> help(f)
> ...
> f(a, b=)
>
> I know I can use a class with __str__ instead of object, but
> what would one print in that
On Wed, Mar 21, 2007 at 01:51:37PM -0400, Raymond Hettinger wrote:
> What are the current thoughts on when Py2.5.1 will go out?
> Do we need a bug-day beforehand?
A bug day would be a great idea! I have a mailbox bug that'd
greatly benefit from discussion about how to fix the problem.
--amk
Guido van Rossum wrote:
> This is why I proposed to *get rid of* the distinction between
> timeout=None and timeout not specified. Let an unspecified timeout
> default to None, and if timeout is None, skip the settimeout() call.
+1
I'll abuse of your dictatorship, and let's see if we can finall
[Raymond]
>> What are the current thoughts on when Py2.5.1 will go out?
>> Do we need a bug-day beforehand?
[AMK]
>A bug day would be a great idea! I have a mailbox bug that'd
>greatly benefit from discussion about how to fix the problem.
How about Sunday, April 1st?
Raymond
_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 21, 2007, at 3:28 PM, Raymond Hettinger wrote:
> [Raymond]
>>> What are the current thoughts on when Py2.5.1 will go out?
>>> Do we need a bug-day beforehand?
>
> [AMK]
>> A bug day would be a great idea! I have a mailbox bug that'd
>> greatly
I'm soliciting feedback on my extended buffer protocol that I am
proposing for inclusion in Python 3000. As soon as the Python 3.0
implementation is complete, I plan to back-port the result to Python
2.6, therefore, I think there may be some interest on this list.
Basically, the extended buff
Is there any reason for test_bool to contain assertions like these?
self.assertIs({}.has_key(1), False)
self.assertIs({1:1}.has_key(1), True)
A significant portion of the file is devoted to making sure various
things return bools (isinstance, operator.*) or handle bools correctly
(pickle, marshal
>> How about Sunday, April 1st?
Barry> I could probably show up for a few hours that day.
I can likely spend a couple hours as well. Afternoon (Central Time) would
be better. Depends on Ellen's work schedule.
Skip
___
Python-Dev mailing list
[EMAIL PROTECTED] wrote:
> >> How about Sunday, April 1st?
>
> Barry> I could probably show up for a few hours that day.
>
> I can likely spend a couple hours as well. Afternoon (Central Time) would
> be better. Depends on Ellen's work schedule.
>
I'd like to put something back into Py
I think it was just expedient to group these together when the bool
type was added. I wouldn't lose sleep over it either way.
On 3/21/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Is there any reason for test_bool to contain assertions like these?
>
> self.assertIs({}.has_key(1), False)
> self.as
On 3/21/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Raymond]
> >> What are the current thoughts on when Py2.5.1 will go out?
> >> Do we need a bug-day beforehand?
>
> [AMK]
> >A bug day would be a great idea! I have a mailbox bug that'd
> >greatly benefit from discussion about how to fix t
Facundo Batista schrieb:
> I updated the patch #1676823, reflecting discussion here:
>
> - The function name changed, now it's _create_connection(). Its
> signature also changed: now, timeout is mandatorily named.
>
> - HTTPConnection has the posibility to call timeout with a number, and
> also
On Wed, Mar 21, 2007 at 03:37:02PM -0500, Collin Winter wrote:
> Is there any reason for test_bool to contain assertions like these?
>
> self.assertIs({}.has_key(1), False)
> self.assertIs({1:1}.has_key(1), True)
>
> A significant portion of the file is devoted to making sure various
> things ret
Raymond Hettinger schrieb:
> [Raymond]
>>> What are the current thoughts on when Py2.5.1 will go out?
>>> Do we need a bug-day beforehand?
>
> [AMK]
>>A bug day would be a great idea! I have a mailbox bug that'd
>>greatly benefit from discussion about how to fix the problem.
>
> How about Sunda
Attached is the PEP.
:PEP: XXX
:Title: Revising the buffer protocol
:Version: $Revision: $
:Last-Modified: $Date: $
:Author: Travis Oliphant <[EMAIL PROTECTED]>
:Status: Draft
:Type: Standards Track
:Content-Type: text/x-rst
:Created: 28-Aug-2006
:Python-Version: 3000
Abstract
This PE
Georg Brandl wrote:
> The class/function distinction is not so clear in Python from the user's
> point of view since there is no different calling syntax.
There *is* a visible distinction, though --
you can subclass classes but not functions.
If these are uppercased because they wrap
classes, wh
Facundo Batista wrote:
> So, as a resume of the choices we still need to settle:
>
> a) Repeat the same functionality in 5 other libraries
> b) Write the function in socket.py, public
> c) Write the function in socket.py, non public
or
d) Put it in another module
Is it time for a so
[EMAIL PROTECTED] wrote:
> Facundo> c) Write the function in socket.py, non public
Also this option has the problem that it would be
a strange usage of "non-public", since the function
would be designed for use by other modules and not
used at all in the module it's supposedly private
to.
Travis Oliphant:
> 3) information about discontiguous memory segments
>
>
> Number 3 is where I could use feedback --- especially from PIL users and
> developers. Strides are a common way to think about a possibly
> discontiguous chunk of memory (which appear in NumPy when you select a
> sub-reg
On 3/21/07, Neil Hodgson <[EMAIL PROTECTED]> wrote:
> Travis Oliphant:
>
> > 3) information about discontiguous memory segments
> >
> >
> > Number 3 is where I could use feedback --- especially from PIL users and
> > developers. Strides are a common way to think about a possibly
> > discontiguous
Neil Hodgson wrote:
>I think one of the motivations for discontiguous segments was for
> split buffers which are commonly used in text editors.
Note that this is different from the case of an array
of pointers to arrays, which is a multi-dimensional
array structure, whereas a split buffer is
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument checking for object.__init__ and object.__new__. I
think it probably isn't; but the strict version could be added to 3.0
and a warning issued
On 3/21/07, Alan Kennedy <[EMAIL PROTECTED]> wrote:
> [Greg Ewing]
> > or
> >
> > d) Put it in another module
> >
> > Is it time for a sockettools module, maybe?
>
> +1!
-1. The new module would be just as much a jumble of unrelated APIs as
the socket module already is, so there's no particul
[Greg Ewing]
> or
>
> d) Put it in another module
>
> Is it time for a sockettools module, maybe?
+1!
Alan.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
Nick Maclaren <[EMAIL PROTECTED]> wrote:
> Well, I have seen it hundreds of times on a dozen different Unices;
> it is very common. You don't always SEE the stuck process - sometimes
> the 'kill -9' causes the pid to become invisible to ps etc., and
> just occasionally it can continue to use CPU u
[Facundo]
> Talk is cheap.
I'm sorry if you see my attempts to review your patch as "cheap talk".
Maybe I should have just kept my opinion to myself.
You'll get your chance to return the favour when I check in my
upcoming 1000+ line change to jython 2.3 to bring the jython socket,
select and asyn
On Sat, Mar 17, 2007 at 08:09:06PM -0500, Collin Winter wrote:
> On 3/17/07, Ewan Mellor <[EMAIL PROTECTED]> wrote:
> >I have a problem being reported (by Xen users) where inspect.stack() is
> >throwing IndexError. I think that this is a bug in inspect.py --
> >findsource
> >generally throws IOE
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>See python.org/sf/1683368. I'd like to invite opinions on whether it's
>worth breaking an unknown amount of user code in 2.6 for the sake of
>stricter argument checking for object.__init__ and object.__new__. I
>think
ACTIVITY SUMMARY (03/11/07 - 03/18/07)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1645 open ( +1) / 8581 closed ( +0) / 10226 total ( +1)
Average duration of open issues: 738 days.
Medi
For some time I'm interested in regular expressions and Finite State Machine.
Recently, I saw that Python uses "Secret Labs' Regular Expression Engine",
which very often works too slow. Its pesymistic time complexity is O(2^n),
although other solutions, with time complexity O(n*m) ( O(n*m^2), m
The xxsubtype.c module gives an example of calling a parent method if it is in
a slot:
static int
spamlist_init(spamlistobject *self, PyObject *args, PyObject *kwds)
{
if (PyList_Type.tp_init((PyObject *)self, args, kwds) < 0)
return -1;
self->state = 0;
return 0;
}
How you c
Travis Oliphant wrote:
> The question is should we eliminate the possibility of sharing memory
> for objects that store data basically as "arrays" of arrays (i.e. true
> C-style arrays).
Can you clarify what you mean by this? Are you talking
about an array of pointers to other arrays? (This is
Greg Ewing:
> So an array-of-pointers interface wouldn't be a direct
> substitute for the existing multi-segment buffer
> interface.
Providing an array of (pointer,length) wouldn't be too much extra
work for a split vector implementation.
Guido van Rossum:
> But there's always a call to remo
Greg Ewing wrote:
> A tangential question -- why are TemporaryFile and
> NamedTemporaryFile named in TitleCase, when they're
> functions and not classes?
>
I wondered the same. At first draft of my email I wrote "class"
operating under the assumption that only classes got to be camel-cased.
If
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>
>>The question is should we eliminate the possibility of sharing memory
>>for objects that store data basically as "arrays" of arrays (i.e. true
>>C-style arrays).
>
>
> Can you clarify what you mean by this? Are you talking
> about an array of p
Jean-Paul Calderone wrote:
> Perhaps I misunderstand the patch, but it would appear to break not just
> some inadvisable uses of super(), but an actual core feature of super().
> Maybe someone can set me right. Is this correct?
>
> class Base(object):
> def __init__(self, important):
>
>
On 3/21/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> >See python.org/sf/1683368. I'd like to invite opinions on whether it's
> >worth breaking an unknown amount of user code in 2.6 for the sake of
> >strict
Guido van Rossum wrote:
> > > Is it time for a sockettools module, maybe?
> >
> > +1!
>
> -1. The new module would be just as much a jumble of unrelated APIs as
> the socket module already is, so there's no particularly good reason
> to create an arbitrary separation. Also, KISS.
I agree with Gui
Raymond Hettinger wrote:
> class List(list):
> def append(self, x):
> print x
> List.append(self, x) # What is the C equivalent of this call?
Something like
PyObject *meth, *result;
meth = PyObject_GetAttrString(PyList_Type, "append")
result = PyObject_CallFunctionObj
Guido van Rossum wrote:
> See python.org/sf/1683368. I'd like to invite opinions on whether it's
> worth breaking an unknown amount of user code in 2.6 for the sake of
> stricter argument checking for object.__init__
Personally I have never written code that relies on
being able to pass arbitrary
Bart³omiej Wo³owiec <[EMAIL PROTECTED]> wrote:
>
> For some time I'm interested in regular expressions and Finite State Machine.
> Recently, I saw that Python uses "Secret Labs' Regular Expression Engine",
> which very often works too slow. Its pesymistic time complexity is O(2^n),
> although
On Wed, Mar 21, 2007, Guido van Rossum wrote:
> On 3/21/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>>
>> I think I understand the desire to pull keyword arguments out at each
>> step of the upcalling process, but I don't see how it can work, since
>> "up" calling isn't always what's going
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| There are different philosophies about the correct style for
| cooperative super calls.
|
| The submitter of the bug report likes to remove "consumed" arguments
| and pass the others on, having something at the root
On 3/21/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > super() has always felt strange to me.
>
> When used in __init__? Or in general? If the former, that's because
> it's a unique Python wart to even be able to use super for __init__.
In g
On 3/21/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> > On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum <[EMAIL PROTECTED]>
> > wrote:
> > >See python.org/sf/1683368. I'd like to invite opinions on whether it's
> > >worth breaking an
On 3/21/07, Aahz <[EMAIL PROTECTED]> wrote:
> Maybe so, but this would massively break my company's application, if we
> were actually using new-style classes and the built-in super(). We have
> a web application that commonly passes all form fields down as **kwargs;
> the application uses lots of
At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote:
>On 3/21/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Every time I've considered using super, I've eventually
> > decided against it for reasons like this. I've always
> > found a better way that doesn't introduce so may
> > strange interactions
On 3/21/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Every time I've considered using super, I've eventually
> decided against it for reasons like this. I've always
> found a better way that doesn't introduce so may
> strange interactions between the classes involved.
I end up feeling the same way,
On 3/21/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
> It seems to me that to get the exact behavior one wants at the apex of a
> diamond structure, one should subclass object and override .__init__ with
> a function that does not call object.__init__ and use that subclass as the
> apex instead of
On 3/21/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> >See python.org/sf/1683368. I'd like to invite opinions on whether it's
> >worth breaking an unknown amount of user code in 2.6 for the sake of
> >strict
Travis Oliphant wrote:
> I'm talking about arrays of pointers to other arrays:
>
> i.e. if somebody defined in C
>
> float B[10][20]
>
> then B would B an array of pointers to arrays of floats.
No, it wouldn't, it would be a contiguously stored
2-dimensional array of floats. An array of pointe
At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote:
> Also make a big distinction between super calls of __init__ (which are
> a Pythonic wart and don't exist in other languages practicing multiple
> inheritance AFAIK)
Since I filed the bug, I should clarify that the primary reason I'm
using sup
> class List(list):
> def append(self, x):
> print x
> List.append(self, x) # What is the C equivalent of this call?
Always literally what you write in Python (assuming you meant
list.append):
PyObject_CallMethod(PyList_Type, "append", "OO", self, x);
HTH,
Martin
_
86 matches
Mail list logo
