Earlier quoted context omitted.
So what? He gave you all his money.
Actually, he spent a big chunk of it before I could get it :(
Actually he borrowed a bunch of you money promising to pay it back in the future.
Python 3.0 Released
51–60 of 63 posts
Re: Python 3.0 Released
#52I'm ambivalent about changing so many functions to return iterators. It's cleaner for experienced coders, but harder to understand for beginners.
Most of those changes get masked behind loops that I don't think either is very different for understanding. I think the plusses outweigh the edge cases.
what are the edge cases? what are the advantages of iterators? less memoryuse?
Re: Python 3.0 Released
#53I loved it, but I still want better threading and multi-core support in CPython... Most desktops now have two cores and it doesn't seem likely that number will fall anytime soon...
Python 2.6 and 3.0 ship with a new library called multiprocessing which provides mechanisms for process control and intercommunication, which conveniently sidesteps the GIL limitation that prevents multiple core usage. The library is loosely based around the existing threading API, and allows for seamless transfer of Python objects between processes (unlike other forms of IPC).
Not so seemless. Things need to be serialised to transfer them. You need to specially craft code so that it is pickle safe... things don't just work automatically.
Also serialising 100MB or so worth of objects around is really slow. So the process module is not good for many cases of use.
Re: Python 3.0 Released
#54Earlier quoted context omitted.
Python 2.6 and 3.0 ship with a new library called multiprocessing which provides mechanisms for process control and intercommunication, which conveniently sidesteps the GIL limitation that prevents multiple core usage. The library is loosely based around the existing threading API, and allows for seamless transfer of Python objects between processes (unlike other forms of IPC).
I know. The library is available to 2.5 as "processing", but starting OS processes when all you wanted were threads is somewhat ugly. I agree it's not possible to do it properly with the GIL in place and attempts to remove it did have less than amazing results on single-thread applications. That's annoying... Even more annoying when I think it's easier to do in Java ;-)
If you're running on Linux, then all threads are processes.
Re: Python 3.0 Released
#55Earlier quoted context omitted.
I know. The library is available to 2.5 as "processing", but starting OS processes when all you wanted were threads is somewhat ugly. I agree it's not possible to do it properly with the GIL in place and attempts to remove it did have less than amazing results on single-thread applications. That's annoying... Even more annoying when I think it's easier to do in Java ;-)
If you're running on Linux, then all threads are processes.
For some definitions of "are" maybe. Fact is that processes don't share address spaces and thus pointers, which means that all data structures have to be serialised in some shape or form before they can be accessed by multiple processes. This makes some use cases infeasible in Python and other GIL based languages.
This is important and I'm concerned that so many advocates of Python (and Ruby and PHP) try to talk this huge issue away. I do use and love Python myself and I'd like to do more with it, so this is not pointless language war fighting.
Re: Python 3.0 Released
#56Re: Python 3.0 Released
#57Earlier quoted context omitted.
Most of those changes get masked behind loops that I don't think either is very different for understanding. I think the plusses outweigh the edge cases.
what are the edge cases? what are the advantages of iterators? less memoryuse?
Iterators get some of the benefits of lazy evaluation.
Re: Python 3.0 Released
#58Earlier quoted context omitted.
If you're running on Linux, then all threads are processes.
For some definitions of "are" maybe. Fact is that processes don't share address spaces and thus pointers, which means that all data structures have to be serialised in some shape or form before they can be accessed by multiple processes. This makes some use cases infeasible in Python and other GIL based languages. This is important and I'm concerned that so many advocates of Python (and Ruby and PHP) try to talk this…
Under Linux, the only difference between a thread and a process is not sharing the address space. Both POSIX threading libraries for Linux (NTPL is the current, LinuxThreads is the old one) do a clone() system call for every pthread_create(). The clone() system call is basically fork() with extra functionality (such as sharing the address space).
Inside the kernel, your "threads" and "processes" are both represented by the task_struct data structure. So, on Linux, threads and processes are the same thing in different flavors.
I brought this up since the parent said "starting OS processes when all you wanted were threads is somewhat ugly." My point is that on Linux, starting a "process" and starting a "thread" is fundamentally the same action and have the same cost.
Re: Python 3.0 Released
#59Earlier quoted context omitted.
For some definitions of "are" maybe. Fact is that processes don't share address spaces and thus pointers, which means that all data structures have to be serialised in some shape or form before they can be accessed by multiple processes. This makes some use cases infeasible in Python and other GIL based languages. This is important and I'm concerned that so many advocates of Python (and Ruby and PHP) try to talk this…
Under Linux, the only difference between a thread and a process is not sharing the address space. Both POSIX threading libraries for Linux (NTPL is the current, LinuxThreads is the old one) do a clone() system call for every pthread_create(). The clone() system call is basically fork() with extra functionality (such as sharing the address space). Inside the kernel, your "threads" and "processes" are both represented…
They are not the same thing. Threads share address space and processes don't and that's a crucial difference.
Re: Python 3.0 Released
#60Earlier quoted context omitted.
Under Linux, the only difference between a thread and a process is not sharing the address space. Both POSIX threading libraries for Linux (NTPL is the current, LinuxThreads is the old one) do a clone() system call for every pthread_create(). The clone() system call is basically fork() with extra functionality (such as sharing the address space). Inside the kernel, your "threads" and "processes" are both represented…
They are not the same thing. Threads share address space and processes don't and that's a crucial difference.
I said same thing with different flavors. Literally, they are both represented by the same data structure in the kernel. The salient point of the discussion - cost of forking a process versus cost of spawning a thread - is the same. They require different styles of programming, but I was responding to your point on cost.
If you ever need to reason about scheduling in the Linux kernel, then you need to understand this concept. In the eyes of the scheduler, they're all the same.