Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Orange Wizard]

Well, it doesn't make any sense to store the data in two places at once. I suppose I could use pointers instead of the indexes I have now, but I don't like doing that in Python because half the time it just creates a new object instead of behaving properly.

[miauw62]

Learn how to use them properly, then. Keep your 2d array of references to tiles, each of which stores a reference to its province, and then just have every province store a list of tiles.
It'll probably be much faster and cleaner in the end, even if you're using more memory.

[Orange Wizard]

I should clarify. That's basically what I'm doing now, it just makes the code hard to read. Unless I use memory addresses, which Python isn't really designed for.

[miauw62]

world.provinces[world.tiles[(x, y)].province].adjacent is used twice there. Store it in a descriptive variable beforehand to increase readability and probably also speed.

[Orange Wizard]

Oh, right, that's what you meant. Derp.

[miauw62]

No, not really, I just didn't initially in the effort to try and read the code snippet and instead looked at your explanation :v

[breadman]

Sometimes I wonder if I even have the foggiest idea of what I'm doing.

Code: [Select]

if world.tiles[i].province not in world.provinces[world.tiles[(x, y)].province].adjacent:
    world.provinces[world.tiles[(x, y)].province].adjacent.append(world.tiles[i].province)


This particular example would be improved by letting .adjacent be a set instead of a list, but whether that's a good idea depends on the rest of the code.

It also looks like you're inside a loop that looks like

Code: [Select]

for i in len(world.tiles):
    process(world.tiles[i])That would probably be faster and cleaner as

Code: [Select]

for tile in world.tiles:
    process(tile)(Please tell me you're not using a while loop and incrementing manually.)

Well, it doesn't make any sense to store the data in two places at once. I suppose I could use pointers instead of the indexes I have now, but I don't like doing that in Python because half the time it just creates a new object instead of behaving properly.

Wait, what?  That sounds like PHP; Python doesn't create a new object when you assign one to a new name, pass it to a function, or add it to a memory structure.  When are you seeing it create a new object?

[Orange Wizard]

(Please tell me you're not using a while loop and incrementing manually.)

No, I'm just iterating over coordinates (which admittedly is inside a while loop but that's because it varies in how long it takes). The snippet looks bad because... well, it is bad.

...

Wait, what?  That sounds like PHP; Python doesn't create a new object when you assign one to a new name, pass it to a function, or add it to a memory structure.  When are you seeing it create a new object?

I'm... not sure, actually. I could have sworn that it did, but I also don't really know what I'm doing.

[jaked122]

I'm... not sure, actually. I could have sworn that it did, but I also don't really know what I'm doing.

That's generally not true. It'll only copy value objects, like integers and characters and floats. It won't make a copy of objects that are any more complicated than that, usually.


It broke my connect 4 AI so many times. Not that it would have worked in the first place.

[Skyrunner]

The copy module, and more specifically copy.copy and copy.deepcopy could be useful for you :v

[Bumber]

You'd find that you need more than one thread. I haven't looked into it deeply, but it appears that all gamemaker programs are limited to one thread.

Eh. So are python programs, no big deal.

https://docs.python.org/3.5/library/multiprocessing.html

Or for strict interpretation of thread:
https://docs.python.org/3.5/library/threading.html
https://docs.python.org/3.5/library/_thread.html

[jaked122]

From what I understand, the Global Interpreter Lock (GIL) is a source of many complaints about Python's multi-threading.


It does look to still be in place in 3.5, so it's still slower than it could be.


That being said, it looks like Jython doesn't have this issue, so maybe it would be profitable to look into that if you need multiprocessing.




In any case, it was just an example of how a programming language that doesn't do multithreading well can be useful and widely used. As it turns out, it wasn't a particularly good example.

[Telgin]

Python gets around the single thread issue by running multiple processes and communicating between them.  That's actually probably the approach that a lot of scripting languages can or will take, come to think of it.

I guess someone could implement Python without the global interpreter lock, but then you'd have to add extensions to it to provide for multithreading, like thread creation, pooling, events, mutexes and semaphores, and so on...

But in any case, yes, Python is still a very useful language despite its performance issues.

[jaked122]

Again, as I was saying, Jython can do just that.

There's also Erlang, which is probably a bit better for interprocess communication, as far as being faster and less prone to breaking.

It's certainly designed for it. Though if you hate functional programming, you probably hate Erlang.

[breadman]

Python gets around the single thread issue by running multiple processes and communicating between them.  That's actually probably the approach that a lot of scripting languages can or will take, come to think of it.

I guess someone could implement Python without the global interpreter lock, but then you'd have to add extensions to it to provide for multithreading, like thread creation, pooling, events, mutexes and semaphores, and so on...

Many Python programs run multiple processes like that, but not until 2.6 did it get standard library support in the form of the multiprocessing module.  In contrast, the threading module seems to have been added in 1.5.1, offering a simpler interface for the even older thread module.  And no, it's not simple in the slightest to communicate between processes; a general language-level solution would probably perform worse than the GIL.

Meanwhile, Python has been implemented without a global interpreter lock, a few times over.  And yes, thread creation, pooling, events, mutexes, and semaphores are also implemented in each one, as part of the standard library.  The main difference is that destructors are even less predictable, but that's why we have the with block these days.

Even with a GIL, threading makes it convenient to use blocking system calls or long-running C library calls without blocking the event loop, and enables interleaved processing that works on shared memory structures.  It's kind of like running the asyncio loop without leaving yields everywhere.  But yes, it makes Python slower than it should be for CPU-bound work on multi-core machines.

Then again, most programs are I/O-bound, which is why removing the GIL hasn't become a big enough priority for the core developers to overcome the issues that it was designed to solve.