Odd behavior regarding a list
vext01 at gmail.com
Thu Mar 26 18:01:40 CET 2009
First of all, thanks to everyone for replying. This has been a great
On Mar 26, 4:21 pm, Steven D'Aprano <st... at REMOVE-THIS-
> On Thu, 26 Mar 2009 08:36:49 -0700, Edd Barrett wrote:
> > My question is: why has 'parent_struct_sig' changed? I was under the
> > impression the assignment operator copies, not references.
> You are mistaken. Firstly, Python does not have an assignment operator.
> Assignment (technically, name binding) is not an operator in Python. You
> can't over-ride it.
> Secondly, assignment in Python *never* copies. Ever. The only time a copy
> is made is when you explicitly ask for a copy.
This explains it.
> e.g. to copy a list L, use one of:
> A few more comments, based on your code.
> > def __classdef_integer(self):
> Double-underscore name mangling is often more trouble than it is worth.
> Unless you really need it, not just think you will need it, it is
> generally considered poor style.
It was an attempt at encapsulation. I didn't want my parser to call
internals willy-nilly. Is there a better way?
> > # cache parent struct sig for later (when casting ptrs)
> If you're actually casting pointers in your code, I don't know what
> language you're using, but it isn't Python! Python is not C, you don't
> have direct access to pointers. I don't know what you're doing, perhaps
> the comment is misleading?
This is not reffering to anything python :P
I will be casting some pointer types in LLVM assembler. Python is
going to generate this code.
> > sys.exit(1)
> You do realise that this line tells your program to exit? Seems like a
> strange thing to include in a method.
I'm just debugging this part of code. Obviously this is removed now.
> Hope some of this is helpful.
Very! Many thanks.
More information about the Python-list