Re: Passing by reference

2007-12-23 Thread Marc 'BlackJack' Rintsch
On Sun, 23 Dec 2007 03:10:48 -0800, MartinRinehart wrote:

> Bruno, right now I've got this:
> 
> def __init__ ( self, t ):
> """ Constructor, called with array of strings. """
> 
> self.text = t
> ...
> 
> Some other program will say:
> tok = Toker( text_array )
> tokens = tok.tokenize()
> 
> So how does the constructor make the array of strings available to the
> tokenize() method?

Assuming the `__init__()` above belongs to the `Toker` class then the
`tokenize()` method can access it via `self.text` of course.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-23 Thread MartinRinehart


Bruno Desthuilliers wrote:
> [EMAIL PROTECTED] a �crit :
> >
> > Bruno Desthuilliers wrote:
> >
> >>...  that's definitively not
> >>something I'd store in global.
> >
> >
> > So where would you put it?
>
> You don't have to "put" functions arguments anywhere - they're already
> local vars.

Bruno, right now I've got this:

def __init__ ( self, t ):
""" Constructor, called with array of strings. """

self.text = t
...

Some other program will say:
tok = Toker( text_array )
tokens = tok.tokenize()

So how does the constructor make the array of strings available to the
tokenize() method?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Passing by reference

2007-12-23 Thread MartinRinehart


Dennis Lee Bieber wrote:
> Great if one is using a teletype as editor

The original Dartmouth computer room was a basement that featured 8
teletypes.

The original BASIC, Dennis, was implemented on a time-shared
"mainframe" with a gigantic 8k words (20-bit words, if I remember) of
core memory.  Designing a language for such a machine, I'd bet you,
too, would choose single-letter names. ('A' was a numeric. 'A$' a
string.)

If you compare the teletype to a tube it was lame. But that's not the
right comparison. The Fortran technology was cards, punched on a card
punch, carried to the operator. Wait your turn (hours more commonly
than minutes). Get a report off the line printer. Repunch the
offending cards.

Indeed, the teletype with line numbers was a giant step forward. No
operator. No waiting. Compiler complains. Retype the offending line. A
miracle in its day. You didn't even have to start your statements in
column 7!
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-22 Thread Bruno Desthuilliers
[EMAIL PROTECTED] a écrit :
> 
> Bruno Desthuilliers wrote:
> 
>>...  that's definitively not
>>something I'd store in global.
> 
> 
> So where would you put it?

You don't have to "put" functions arguments anywhere - they're already 
local vars.

def tokenize(text):
   do some work
   returns or (yields) a list of tokens or whatever

If you want the tokenizer module to work as a self-contained appliction 
*too*, then :

if __name__ == '__main__':
   text = reads the text from a file or stdin
   for token in tokenize(text):
 do something with token


HTH
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-22 Thread MartinRinehart


Steven D'Aprano wrote:
> Context is all gone, so I'm not sure that I remember what "it" is. I
> think it is the text that you're parsing.

Yes. I'm tokenizing today. Parsing comes after Christmas.

> TEXT = "placeholder"
>
> def parse():
> while True:
> token = get_next_token() # looks at global TEXT
> yield token

Classic, but I'm not going to go there (at least until I fail
otherwise).

My tokenizer returns an array of Token objects. Each Token includes
the text from which is created, locations in the original text and,
for something like CONSTANT_INTEGER, it has an intValue data member.

> # Run as many independent parsers as I need:
> parser1 = parse(open("filename", "r").read())
> parser2 = parse(open("filename2", "r").read())
> parser3 = parse("some text")

Interesting approach, that. Could have a separate parser for each
statement. Hmmm. Maybe my tokenizer should return a list of arrays of
Tokens, one array per statement. Hmmm.

I'm thinking about an OO language construction that would be very easy
to extend. Tentatively, I'll have Production objects, Statement
objects, etc. I've already got Tokens.

Goal is a really simple language for beginners. Decaf will be to Java
as BASIC was to Fortran, I hope.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-22 Thread Steven D'Aprano
On Sat, 22 Dec 2007 04:13:31 -0800, MartinRinehart wrote:

> Bruno Desthuilliers wrote:
>> ...  that's definitively not
>> something I'd store in global.
> 
> So where would you put it?

Context is all gone, so I'm not sure that I remember what "it" is. I 
think it is the text that you're parsing.

I believe you are currently doing something like this:

TEXT = "placeholder"

def parse():
while True:
token = get_next_token() # looks at global TEXT
yield token

# And finally actually run your parser:
TEXT = open("filename", "r").read()
for token in parse():
print token



If I were doing this, I would do something like this:

def parse(text):
while True:
token = get_next_token() # looks at local text
yield token

# Run as many independent parsers as I need:
parser1 = parse(open("filename", "r").read())
parser2 = parse(open("filename2", "r").read())
parser3 = parse("some text")

for token in parser1:
print token
# etc.



Unless the text you are parsing is truly enormous (multiple hundreds of 
megabytes) you are unlikely to run into memory problems. And you gain the 
ability to run multiple parsers at once.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-22 Thread MartinRinehart


Bruno Desthuilliers wrote:
> ...  that's definitively not
> something I'd store in global.

So where would you put it?
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-22 Thread MartinRinehart


Hendrik van Rooyen wrote:
> I wonder if you have some COBOL data divisions under your belt?

Hendrik, I go way back but somehow I missed COBOL.

Martin
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-22 Thread Hendrik van Rooyen
MartinRinehart Wrote:


> More seriously, I can and do use lots of globals. In the tokenizer I'm
> writing, for example, all the token types(COMMENT_EOL = 0,
> CONSTANT_INTEGER = 1, ...) are global constants. The text to be
> tokenized is a global variable. (Actually, the text is unchanging once
> the Tok object is created, so this "variable" may be another
> constant.) Passing global constants to functions is a case of CPU
> abuse.
> 
> Structured purists gave globals a bad rap, years ago. Time to stick up
> for them. They're good citizens. Don't blame them if some dumb coder
> abuses them. It's not their fault.

*grin* 

It is good to see that I am not the only person in the squad who hears
the beat of this drum.

I wonder if you have some COBOL data divisions under your belt?

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-21 Thread Bruno Desthuilliers
[EMAIL PROTECTED] a écrit :
> Hi, Bruno. Merry Christmas!



> By "constant" I meant that it did not change during the lifetime of
> the Toker.

That's still a variable to me. It's even the essence of the variable, 
since it's the main input of your program. And that's definitively not 
something I'd store in global.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-21 Thread MartinRinehart
Hi, Bruno. Merry Christmas!

By "constant" I meant that it did not change during the lifetime of
the Toker.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-21 Thread Bruno Desthuilliers
[EMAIL PROTECTED] a écrit :
> 
> Sion Arrowsmith wrote:
>> Michael Sparks  <[EMAIL PROTECTED]> wrote:
>>> def bar():
>>>global x
>>>x[0] += " another"
>>>print id(x[0])
>> ... and for bonus marks, explain why the "global x" in this function
>> is not required.
> 
> Because x does not appear as an LHS in bar(), just about the first
> thing I learned here.
> 
> More seriously, I can and do use lots of globals.

We all do, FWIW - since everything is name/object binding, all the 
classes, functions, modules etc defined or imported in a module are, 
technically, globals (for the Python definition of 'global').

> In the tokenizer I'm
> writing, for example, all the token types(COMMENT_EOL = 0,
> CONSTANT_INTEGER = 1, ...) are global constants.

Technically, they are not even constants !-)

> The text to be
> tokenized is a global variable. 

Now *this* is bad. Really bad.

> (Actually, the text is unchanging once
> the Tok object is created, so this "variable" may be another
> constant.) 

It isn't.

> Passing global constants to functions is a case of CPU
> abuse.

Remember that Python doesn't copy objects when passing them as function 
params, and that function-local names are faster to lookup than global 
ones.

There are indeed reasons not to pass module constants to the module's 
functions, but that have nothing to do with CPU. And in your case, the 
text to be tokenised is definitively not a constant.

> Structured purists gave globals a bad rap, years ago. Time to stick up
> for them. They're good citizens.  Don't blame them if some dumb coder
> abuses them. 

Once you learned why you should not do something - and how to avoid 
doing it -, chances are you also know when it's ok to break the rule.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-21 Thread MartinRinehart


Sion Arrowsmith wrote:
> Michael Sparks  <[EMAIL PROTECTED]> wrote:
> >def bar():
> >global x
> >x[0] += " another"
> >print id(x[0])
>
> ... and for bonus marks, explain why the "global x" in this function
> is not required.

Because x does not appear as an LHS in bar(), just about the first
thing I learned here.

More seriously, I can and do use lots of globals. In the tokenizer I'm
writing, for example, all the token types(COMMENT_EOL = 0,
CONSTANT_INTEGER = 1, ...) are global constants. The text to be
tokenized is a global variable. (Actually, the text is unchanging once
the Tok object is created, so this "variable" may be another
constant.) Passing global constants to functions is a case of CPU
abuse.

Structured purists gave globals a bad rap, years ago. Time to stick up
for them. They're good citizens. Don't blame them if some dumb coder
abuses them. It's not their fault.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-21 Thread Sion Arrowsmith
Michael Sparks  <[EMAIL PROTECTED]> wrote:
>def bar():
>global x
>x[0] += " another"
>print id(x[0])

... and for bonus marks, explain why the "global x" in this function
is not required.

-- 
\S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/
   "Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
   her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Passing by reference

2007-12-20 Thread Aahz
In article <[EMAIL PROTECTED]>,
 <[EMAIL PROTECTED]> wrote:
>
>Is the following correct?

Sort-of, but I would say that it's misleadingly correct.  Try this:
http://starship.python.net/crew/mwh/hacks/objectthink.html
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-20 Thread Terry Reedy

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| Is the following correct?
|
| x = "some string"
|
| x is a reference to "some string"

x is a name bound to a string object with value 'some string'.
Some people find is useful to call that a 'reference', as you seem to have.
Others get confused by that viewpoint.  It depend on exactly what one means 
by 'reference'.

| foo(x)
|
| Reference is passed to function.

The first parameter name of foo gets bound to the object referred to by 
'x'.
Calling that 'passing by reference' sometimes misleads people as to how 
Python behaves.

| In foo:
|x += " change"
|
| Strings are immutable, so x in foo() now points to a different string
| than x outside foo().
| Right?

A function local name x has no particular relationship to a global name 
spelled the same, except to confuse things.  Best to avoid when possible.

The effect of that statement would be the same outside of the function as 
well, pretty much for the reason given.  In general, 'y op= x' is the same 
as 'y = y op x' except for any side-effects of expression y.  Lists are an 
exception.

tjr





-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-20 Thread Michael Sparks
[EMAIL PROTECTED] wrote:

> ... the first element of the list to which x refers is a reference to
> the new string and back outside foo, the first element of the list to
> which x refers will be a reference to the new string.

I'd rephrase that as:
   * Both the global context and the inside of foo see the same list
   * They can therefore both update the list
   * If a new string is put in the first element of the list, the can
 both see the same new string.

> Right?

You know you can get python to answer your question - yes? Might be slightly
more illuminating than twisting round english... :-)

OK, you're passing in a string in a list. You have 2 obvious ways of doing
that - either as an argument:

def foo(y):
y[0] += " other"
print id(y[0])

... or as a global: (which of course you wouldn't do :-)

def bar():
global x
x[0] += " another"
print id(x[0])

So let's see what happens.

>>> x = ["some string"]  # create container with string
>>> x[0]  # Check that looks good & it does
'some string'
>>> id(x[0])  # What's the id of that string??
3082578144L
>>> foo(x)# OK, foo thinks the new string has the following id
3082534160
>>> x[0]  # Yep, our x[0] has updated, as expected.
'some string other'
>>> id(x[0])  # Not only that the string has the same id.
3082534160L
>>> bar() # Update the global var, next line is new id
3082543416
>>> x[0]  # Check the value's updated as expected
'some string other another'
>>> id(x[0])  # Note that the id is the same as the output from bar
3082543416L

Does that perhaps answer your question more precisely ?


Michael.




-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-20 Thread MartinRinehart
... the first element of the list to which x refers is a reference to
the new string and back outside foo, the first element of the list to
which x refers will be a reference to the new string.

Right?
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-20 Thread John Machin
On Dec 21, 5:57 am, [EMAIL PROTECTED] wrote:
> Is the following correct?
>
> x = "some string"
>
> x is a reference to "some string"
>
> foo(x)
>
> Reference is passed to function.
>
> In foo:
> x += " change"
>
> Strings are immutable, so x in foo() now points to a different string
> than x outside foo().
> Right?
>
> Back outside foo.
>
> x = ["some string"]
>
> x is a reference to a list whose first element is a reference to a
> string.
>
> foo(x)
>
> Within foo:
>
> x[0] += " other"
>
> Another string is created, the first element of x is modified to point

Somewhat colloquial/abbreviated. x is a reference. It does not have
elements. You mean "... the first element of the list to which x
refers is modified ...".

> to the new string and back outside foo(), x[0] will point to the new
> string.
>
> Right?

Close enough.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Passing by reference

2007-12-20 Thread Ben Finney
[EMAIL PROTECTED] writes:

> Is the following correct?
> 
> [lots of references to "references"]

All good so far.

> x[0] += " other"
> 
> Another string is created, the first element of x is modified to point
> to the new string and back outside foo(), x[0] will point to the new
> string.

Change these to talk about "references" again and it'll be true also:

"Another string is created, the first element of x now refers to
the new string and back outside foo(), x is still a reference to
the same list (so its first element is a reference to the same
string)."

> Right?

Right. In Python, all names, and all elements of container objects,
are references to the corresponding objects. Python has no concept of
"pointers" in the style of C-like languages.

-- 
 \"I fly Air Bizarre. You buy a combination one-way round-trip |
  `\ticket. Leave any Monday, and they bring you back the previous |
_o__)  Friday. That way you still have the weekend."  -- Steven Wright |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list


Passing by reference

2007-12-20 Thread MartinRinehart
Is the following correct?

x = "some string"

x is a reference to "some string"

foo(x)

Reference is passed to function.

In foo:
x += " change"

Strings are immutable, so x in foo() now points to a different string
than x outside foo().
Right?

Back outside foo.

x = ["some string"]

x is a reference to a list whose first element is a reference to a
string.

foo(x)

Within foo:

x[0] += " other"

Another string is created, the first element of x is modified to point
to the new string and back outside foo(), x[0] will point to the new
string.

Right?
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Embedding Python - Passing by Reference

2007-11-29 Thread andy
Thanks for the replies - I see that I completely misunderstood
"passing by reference" when discussing Python. It looks like wrapping
the object up in a list will be the path I go down as it remains
closer to the C API I am wrapping.

Thanks again!

Andy
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Embedding Python - Passing by Reference

2007-11-29 Thread Neil Cerutti
On 2007-11-29, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I understand the parameters to Python functions are passed by
> reference:
>
> def foo(a):
>   a = a + 1
>
> Will change the value of a in the calling function. How do I
> implement the equivalent in C when extending Python?

You've got the passing convention basically correct, but the
semantcs of 'a + 1' wrong.

'a + 1' evaluates to a new integer object equal to a+1. Then the
= binds the local a to that new integer. The object that
the calling a refers to is never modified, and the name that is
bound to it is not rebound.

If you had modified the object that the local a was bound to, it
would have the effect you are after. As it happens, some objects
are immutable and thus cannot be modified.

> I know how to write a function that can be called from Python
> and I know how to use PyArg_ParseTuple to get the value of a.
> But how do I update the value of a in C? I tried (greatly
> simplified):

You cannot do it. You'll have to insist on a boxed value of some
kind, like one stored in a list or an object.

Python equivalent:

>>> def foo(x):
...   x[0] = 'foo'
...
>>> a = [0]
>>> foo(a)
>>> a
['foo']

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Embedding Python - Passing by Reference

2007-11-29 Thread Terry Reedy

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
|I understand the parameters to Python functions are passed by reference:

Nope.  Python's name-object model is so far different from the named memory 
block model of Fortran/C/etc that terms invented for the latter are 
misleading when applied to Python.  Argument objects (or the contents 
thereof, or lists or dicts constructed therefrom) are bound to parameter 
names.  (See the archives for endless discussion of what to call this.)

| def foo(a):
|  a = a + 1
|
| Will change the value of a in the calling function.

Nope.  Try it with the interactive interpreter (or IDLE, etc, equivalent).
Only takes a minute to test whatever you meant by that.tjr


| 



-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Embedding Python - Passing by Reference

2007-11-29 Thread Jean-Paul Calderone
On Thu, 29 Nov 2007 14:39:52 -0800 (PST), [EMAIL PROTECTED] wrote:
>I understand the parameters to Python functions are passed by
>reference:
>
>def foo(a):
>  a = a + 1
>
>Will change the value of a in the calling function. How do I implement
>the equivalent in C when extending Python?

You misunderstand how parameters are passed in Python:

>>> x = 10
>>> def foo(y):
... y = y + 1
...
>>> foo(x)
>>> x
10
>>>

So there's no behavior here to attempt to emulate when embedding or extending.

Jean-Paul
-- 
http://mail.python.org/mailman/listinfo/python-list


Embedding Python - Passing by Reference

2007-11-29 Thread andy
I understand the parameters to Python functions are passed by
reference:

def foo(a):
  a = a + 1

Will change the value of a in the calling function. How do I implement
the equivalent in C when extending Python?

I know how to write a function that can be called from Python and I
know how to use PyArg_ParseTuple to get the value of a. But how do I
update the value of a in C? I tried (greatly simplified):

PyObject *a;
int value;
PyArg_ParseTuple(args, "O", &a);
value = PyLong_AsLong(a);
value++;
a = PyLong_FromLong(value);

but this doesn't work. Any suggestions?

Note that I am trying to wrap an existing C based API as closely as
possible, so I can't return the value using return (this example is
greatly simplified and I'm already using the return value for other
things).

Thanks! Andy
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: C API: passing by reference

2007-06-23 Thread [EMAIL PROTECTED]
Thanks for that clarification Martin. When I googled it before, the
first page I read said "Python passes all arguments using 'pass by
reference'." However, after seeing your reply and further searching I
see that this is not true.

I have a python function insertEdge which takes to 2-tuples of
(faceid,vertexid) and returns the edgeid. But upon execution of the
function the two vertexid's end up sharing the same faceid. So right
now my solution is just to also return the two new (faceid,vertexid).
These will both have the same vertexid as before, but have a different
faceid then before (sharing the same faceid).

Here for example is a script to create a triangle:

  v1 = createVertex((0,0,0))
  v2 = createVertex((1,0,0))
  e1,v1,v2 = insertEdge(v1,v2)
  v3 = createVertex((0,1,0))
  e2,v2,v3 = insertEdge(v2,v3)
  e3,v3,v1 = insertEdge(v3,v1)

Here is the C++ code:

static PyObject *
dlfl_insert_edge(PyObject *self, PyObject *args)
{
  uint faceId1;
  int vertId1;
  uint faceId2;
  int vertId2;
  int edgeId = -1;

  if( !PyArg_ParseTuple(args, "(ii)(ii)", &faceId1, &vertId1,
&faceId2, &vertId2) )
return NULL;

  if( currObj ) {
edgeId = DLFL::insertEdge( currObj, faceId1, vertId1, faceId2,
vertId2 );
currObj->clearSelected( );
  }

  return Py_BuildValue("i,(ii)(ii)", edgeId, faceId1, vertId1,
faceId2, vertId2 );
}

This works, but...
Any suggestions if there is a cleaner way?

Thanks!

On Jun 23, 1:31 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] schrieb:
>
> > I'm writing my own python extension module with the C API. In python
> > all functions pass arguments by reference
>
> Can you please show an example what you mean by that? There is no
> "pass-by-reference" in Python: a function can not normally modify
> the variable in the caller.
>
> When you show what precisely you want to achieve, it should be easy
> to say how to do that in C.
>
> Regards,
> Martin

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C API: passing by reference

2007-06-23 Thread Carsten Haese
On Sat, 2007-06-23 at 18:25 +, [EMAIL PROTECTED] wrote:
> I'm writing my own python extension module with the C API. In python
> all functions pass arguments by reference,

"Pass by reference", while correct from a certain standpoint, is to be
taken with a large grain of salt. It is correct in so far as the value
is not copied. It is incorrect in so far as, in general, you may not be
able to modify the object that's passed.

The reference you receive can only be used to call methods of the
referenced object, if it has any, or manipulate attributes of the
object, if it has any. It can not be used to replace the object with
another object.

>  but how can I make use of
> this in C? Right now, I am using:

You can't.

> PyArg_ParseTuple(args, "(ii)(ii)", &faceId1, &vertId1, &faceId2,
> &vertId2)
> 
> I want the to change the faceId's in my function. From what I've seen
> you can't do this safely with PyArg_ParseTuple.

Not with PyArg_ParseTuple, not with anything. Your function receives a
reference to an int object. Since int objects are immutable, you can't
replace the number that's in the int object.

> Do I have another option?

Return the value instead of trying to produce side-effects in the
caller's name space.

HTH,

-- 
Carsten Haese
http://informixdb.sourceforge.net


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: C API: passing by reference

2007-06-23 Thread Martin v. Löwis
[EMAIL PROTECTED] schrieb:
> I'm writing my own python extension module with the C API. In python
> all functions pass arguments by reference

Can you please show an example what you mean by that? There is no
"pass-by-reference" in Python: a function can not normally modify
the variable in the caller.

When you show what precisely you want to achieve, it should be easy
to say how to do that in C.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list


C API: passing by reference

2007-06-23 Thread [EMAIL PROTECTED]
I'm writing my own python extension module with the C API. In python
all functions pass arguments by reference, but how can I make use of
this in C? Right now, I am using:

PyArg_ParseTuple(args, "(ii)(ii)", &faceId1, &vertId1, &faceId2,
&vertId2)

I want the to change the faceId's in my function. From what I've seen
you can't do this safely with PyArg_ParseTuple.

Do I have another option?

Otherwise, I just have to return an extra variable. But it would be
much much nicer to just have the faceId's change if the arguments
passed were variables.

Thanks!

-- 
http://mail.python.org/mailman/listinfo/python-list