Odd behavior regarding a list

[Edd Barrett]

Hi there,

First of all, thanks to everyone for replying. This has been a great
help.

On Mar 26, 4:21 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> 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:
>
> list(L)
>
> L[:]

Great :)


> 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.


--

Edd