I've recently started teaching myself Python in anticipation of the upcoming Python support for Construct. I figured if I'm going to be any sort of Construct "power user" I should probably know my way around all the features it has to offer.

So far I'm liking what I've seen of Python. It seems to be a good language for beginning programmers.

Just curious if there's anyone else here who's decided to pick up Python for he same reason...

I started a few days ago with some tutorials. Since i've never programmed before, and since i don't know any advanced math i guess i will progress pretty slow. But it was far easier then i expected! I'll definately try to learn more of it.

You want y to equal x, and expect it to be it's own variable from there on. but when you sort y (to put it in numerical order) it affects x too because x and y are just two different names for the same friggin variable. They both point to the same list. WTF? To make y separate from x you have to

[code:m6cjgmng]y = x[:][/code:m6cjgmng]

to create a duplicate of the list. So far Python is fairly intuitive, but there are a few little things like this that go against the grain of it.

Another for-instance: problems arising from non-declarative variable types. x can equal 12, or x can equal "dog." Fine. That makes things easy on the face of it. I don't have to declare variable types with $ or % or whatever, like in BASIC. But then you can do weird stuff like this:

[quote:2yi4f932]but when you sort y (to put it in numerical order) it affects x too[/quote:2yi4f932]
This is pretty much how C++ works, by default it uses reference semantics on arrays. I guess Python's x[:] is a way of explicitly calling the copy constructor (if Python calls it that), which is probably a good idea, so you don't accidentally end up copying around large arrays unnecessarily. In real world apps, the majority of the time arrays will be passed around by reference semantics.

As for mixing strings and ints, it's generally a grey area anyway. It works pretty similarly to Construct (you can't add or perform operations on mixed types usually, except for special operators like string concatenation &). Operations like "50" + 1 are intrinsically ambigious, do you want to get 51 or 501? Rather than allow something that may be unexpected, the general solution is to disallow it - this is not any particular language's fault. You should use explicit string or integer conversion functions to make it work how you want.

[quote="Ashley":1r5oy4lh]As for mixing strings and ints... blah blah blah.. You should use explicit string or integer conversion functions to make it work how you want.[/quote:1r5oy4lh]

I know, my point on that was that making variables handle multiple types doesn't necessarily make them easier to use. Sure, I don't have to say x% = 12 and x$ = "dog", but the trade-off is I have to keep track of what the type is myself.

I suppose I could just get into the habit of naming my variables xN and xS to keep from getting a type mismatch.

As for the array issue, I guess it just seems like saying y = x should be explicitly stating I want to copy array x to array y. Otherwise, I'd just refer to array x. I don't really see any reason why I'd need two different names to refer to the same array, but maybe that will become clear as I continue to work with Python...

The reason they do this is if you were to pass an array to a function, it's faster to pass by reference than to duplicate the array.

But this is simply how Python is by design. It's a dynamically typed language, so everything is a reference to an object. Even primitive types like int, float, and string are objects. Even the types themselves are objects, which means you can do this:
arr = [int, float, str]