Re: [Python-Dev] Psyco for -OO or -O
Lie Ryan wrote: I'm sure probably most of you knows about psyco[1], the optimizer. Python has an -O and -OO flag that is intended to be optimization flag, but we know that currently it doesn't do much. Why not add psyco as standard library and let -O or -OO invoke psyco? This really belongs on Python-ideas and not Python-dev. The main reason why not is that someone(s) from the Python core team would then need to 'own' maintaining Psyco (which is x86 only as well). Psyco is so hard to maintain that even the original author wants to drop it. :-) Michael Foord [1] http://psyco.sourceforge.net/index.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?
Lennart Regebro wrote: On Fri, Dec 12, 2008 at 02:13, Sturla Molden wrote: I genuinely think the use of threads should be discouraged. It leads to code that are full of bugs and difficult to maintain - race conditions, deadlocks, and livelocks are common pitfalls. The use of threads for load balancing should be discouraged, yes. That is not what they are designed for. Threads are designed to allow blocking processes to go on in the background without blocking the main process. This, they are very useful for. Removing thread support would therefore be a very big mistake. It's needed, it has it's uses, just not the one *you* want. That's an interesting assertion about what threads were designed for. Do you have anything to back it up? Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Psyco for -OO or -O
On Sat, 13 Dec 2008 13:28:37 +, Michael Foord wrote: > Lie Ryan wrote: >> I'm sure probably most of you knows about psyco[1], the optimizer. >> Python has an -O and -OO flag that is intended to be optimization flag, >> but we know that currently it doesn't do much. Why not add psyco as >> standard library and let -O or -OO invoke psyco? >> >> > This really belongs on Python-ideas and not Python-dev. Ah yes, sorry about that, I'm new here. This will be my last post about this here... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?
Yes, this is what threads were designed for. As an abstraction to have multiple "threads of control" on a *single* processor (in a single process). The whole multi-core business came decades later. (Classic multi-processors have something called threads too, but they, too, came later than the original single-core-single-CPU thread concept, and often threads on those systems have properties that don't match how threads work on modern multi-core CPUs.) On Sat, Dec 13, 2008 at 5:32 AM, Michael Foord wrote: > Lennart Regebro wrote: >> >> On Fri, Dec 12, 2008 at 02:13, Sturla Molden wrote: >> >>> >>> I genuinely think the use of threads should be discouraged. It leads to >>> code that are full of bugs and difficult to maintain - race conditions, >>> deadlocks, and livelocks are common pitfalls. >>> >> >> The use of threads for load balancing should be discouraged, yes. That >> is not what they are designed for. Threads are designed to allow >> blocking processes to go on in the background without blocking the >> main process. This, they are very useful for. Removing thread support >> would therefore be a very big mistake. It's needed, it has it's uses, >> just not the one *you* want. >> >> > > That's an interesting assertion about what threads were designed for. Do you > have anything to back it up? > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?
If I remember correctly (when threading was invented in the mid-1980s) threads were originally described as "lightweight processes". The perceived advantage at the time was the ability to have multiple threads of control with shared memory: this was much faster than the available inter-process communication mechanisms. On a single-processor computer synchronization was much less of a problem. regards Steve Guido van Rossum wrote: > Yes, this is what threads were designed for. As an abstraction to have > multiple "threads of control" on a *single* processor (in a single > process). The whole multi-core business came decades later. (Classic > multi-processors have something called threads too, but they, too, > came later than the original single-core-single-CPU thread concept, > and often threads on those systems have properties that don't match > how threads work on modern multi-core CPUs.) > > On Sat, Dec 13, 2008 at 5:32 AM, Michael Foord > wrote: >> Lennart Regebro wrote: >>> On Fri, Dec 12, 2008 at 02:13, Sturla Molden wrote: >>> I genuinely think the use of threads should be discouraged. It leads to code that are full of bugs and difficult to maintain - race conditions, deadlocks, and livelocks are common pitfalls. >>> The use of threads for load balancing should be discouraged, yes. That >>> is not what they are designed for. Threads are designed to allow >>> blocking processes to go on in the background without blocking the >>> main process. This, they are very useful for. Removing thread support >>> would therefore be a very big mistake. It's needed, it has it's uses, >>> just not the one *you* want. >>> >>> >> That's an interesting assertion about what threads were designed for. Do you >> have anything to back it up? >> -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Psyco for -OO or -O
On 13-12-2008, Michael Foord wrote: > Lie Ryan wrote: >> I'm sure probably most of you knows about psyco[1], the optimizer. Python >> has an -O and -OO flag that is intended to be optimization flag, but we >> know that currently it doesn't do much. Why not add psyco as standard >> library and let -O or -OO invoke psyco? >> > > This really belongs on Python-ideas and not Python-dev. > > The main reason why not is that someone(s) from the Python core team > would then need to 'own' maintaining Psyco (which is x86 only as well). > Psyco is so hard to maintain that even the original author wants to drop > it. :-) It could be the killer feature wich will push python3 adoption ;-) Bloggers like so much benchings ! Sorry... -- William Dodé - http://flibuste.net Informaticien Indépendant ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] beginning developer: fastest way to learn how Python 3.0 works
I'd like to learn how Python 3.0 works. I've downloaded the svn. I am wondering what the best way to learn is: - Just jump in? - Or perhaps learn A before B? - Or maybe there is a tutorial for those new to the internals? What's the best way to learn how Python 3.0 works? Roy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?
Steve Holden schrieb: > If I remember correctly (when threading was invented in the mid-1980s) > threads were originally described as "lightweight processes". The > perceived advantage at the time was the ability to have multiple threads > of control with shared memory: this was much faster than the available > inter-process communication mechanisms. On a single-processor computer > synchronization was much less of a problem. Initially one of Java's main target platforms were set-top boxes. Back in the 90ties set-top boxes had limited hardware and dumb processors. Most of the boxes had no MMU and so didn't support multiple processes. Threads were the easiest way to have some kind of concurrency. Back in those days threads were the only solution for concurrency but today - about 15 years later with powerful processors even in cheap mobile phones - people are still indoctrinated with the same philosophy ... Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?
On Sat, Dec 13, 2008 at 9:13 AM, Christian Heimes wrote: > Steve Holden schrieb: >> If I remember correctly (when threading was invented in the mid-1980s) >> threads were originally described as "lightweight processes". The >> perceived advantage at the time was the ability to have multiple threads >> of control with shared memory: this was much faster than the available >> inter-process communication mechanisms. On a single-processor computer >> synchronization was much less of a problem. > > Initially one of Java's main target platforms were set-top boxes. Back > in the 90ties set-top boxes had limited hardware and dumb processors. > Most of the boxes had no MMU and so didn't support multiple processes. > Threads were the easiest way to have some kind of concurrency. Just let's not rewrite history and believe Java invented threads. They were around well before that. > Back in those days threads were the only solution for concurrency but > today - about 15 years later with powerful processors even in cheap > mobile phones - people are still indoctrinated with the same philosophy ... It's not so much indoctrination. Threads are a useful tool. The problem is that some people perceive threads as the *only* tool. There's a whole spectrum of tools, from event handling to multiple processes, and they don't all solve the same problem. (I guess it doesn't help that the word process is given new meanings by some languages.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3.0, unicode, and os.environ
On Fri, 12 Dec 2008 06:33:28 pm Toshio Kuratomi wrote: > Also interesting, if you point your browser at: > http://toshio.fedorapeople.org/u/ > > You should see two other test files. They're both > (one-half)(enyei).html but one's encoded in utf-8 and the other in > latin-1. For what it's worth, Konquorer 3.5 displays the two files as (1/2)(n+tilde).html (A+caret)(1/2)(A+tilde)(plusminus).html It doesn't seem to have any trouble opening either of them. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beginning developer: fastest way to learn how Python 3.0 works
On Sat, Dec 13, 2008, Roy Lowrance wrote: > > What's the best way to learn how Python 3.0 works? Post to the correct mailing list. ;-) Use comp.lang.python or python-tutor or python-help python-dev is for people creating new versions of Python -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beginning developer: fastest way to learn how Python 3.0 works
Maybe this is the correct list, as my inquiry is about how to learn how the current implementation works so that I could consider how to implement new features. So, here's a modified question: If you want to learn how python works (not how to program in the python language), what's a productive way to proceed? Roy On Sat, Dec 13, 2008 at 1:18 PM, Aahz wrote: > On Sat, Dec 13, 2008, Roy Lowrance wrote: >> >> What's the best way to learn how Python 3.0 works? > > Post to the correct mailing list. ;-) > > Use comp.lang.python or python-tutor or python-help > > python-dev is for people creating new versions of Python > -- > Aahz ([email protected]) <*> http://www.pythoncraft.com/ > > "It is easier to optimize correct code than to correct optimized code." > --Bill Harlan > -- Roy Lowrance home: 212 674 9777 mobile: 347 255 2544 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beginning developer: fastest way to learn how Python 3.0 works
Roy Lowrance wrote: Maybe this is the correct list, as my inquiry is about how to learn how the current implementation works so that I could consider how to implement new features. So, here's a modified question: If you want to learn how python works (not how to program in the python language), what's a productive way to proceed? There are developer pages on the site, a wiki page on the ceval loop, the extending and embedding manual, and the code itself. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Reindenting the C code base?
Hello, I remember there were some talks of reindenting the C code base (from tabs to 4-space indents) after py3k is released, but I can't find the discussion thread again. Was a decision ever taken about it? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reindenting the C code base?
On Sat, Dec 13, 2008 at 1:22 PM, Antoine Pitrou wrote: > I remember there were some talks of reindenting the C code base (from tabs to > 4-space indents) after py3k is released, but I can't find the discussion > thread > again. Was a decision ever taken about it? I think we should not do this. We should use 4 space indents for new files, but existing files should not be reindented. If you reindent, much of the history of the file is essentially lost -- "svn blame" will blame whoever reindented the code, and it's a pain to go back. There's also the issue of merging between the 2.x and 3.x branches, which we still do. As far as a decision, I think the de facto decision is to keep the status quo, and I'm all for sticking with that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reindenting the C code base?
Guido van Rossum python.org> writes: > > I think we should not do this. We should use 4 space indents for new > files, but existing files should not be reindented. Well, right now many files are indented with a mix of spaces and tabs, depending on who did the edit and how their editor was configured at the time. Perhaps a graceful policy would be to mandate that all new edits be made with spaces without touching other functions in the file. Then hopefully the code base would gradually converge to a tabless scheme. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [ANN] Python 2.4.6 and 2.5.3, release candidate 1
On behalf of the Python development team and the Python community, I'm happy to announce the release candidates of Python 2.4.6 and 2.5.3. 2.5.3 is the last bug fix release of Python 2.5. Future 2.5.x releases will only include security fixes. According to the release notes, over 100 bugs and patches have been addressed since Python 2.5.1, many of them improving the stability of the interpreter, and improving its portability. 2.4.6 includes only a small number of security fixes. Python 2.6 is the latest version of Python, we're making this release for people who are still running Python 2.4. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of bugs fixed; most of them prevent interpreter crashes (and now cause proper Python exceptions in cases where the interpreter may have crashed before). Assuming no major problems crop up, a final release of Python 2.4.6 and 2.5.3 will follow in about a week's time. For more information on Python 2.4.6 and 2.5.3, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.6 http://www.python.org/2.5.3 Highlights of the previous major Python releases are available from the Python 2.5 page, at http://www.python.org/2.4/highlights.html http://www.python.org/2.5/highlights.html Enjoy this release, Martin Martin v. Loewis [email protected] Python Release Manager (on behalf of the entire python-dev team) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reindenting the C code base?
> I think we should not do this. We should use 4 space indents for new > files, but existing files should not be reindented. If you reindent, > much of the history of the file is essentially lost -- "svn blame" > will blame whoever reindented the code, and it's a pain to go back. I believe "svn blame -x -w" ignores whitespace changes. -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [ANN] Python 2.4.6 and 2.5.3, release candidate 1
Martin v. Löwis schrieb: > 2.5.3 is the last bug fix release of Python 2.5. Future 2.5.x releases > will only include security fixes. According to the release notes, over > 100 bugs and patches have been addressed since Python 2.5.1, many of Do you really mean 2.5.1? Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?
> If I remember correctly (when threading was invented in the mid-1980s) > threads were originally described as "lightweight processes". According to http://www.serpentine.com/blog/threads-faq/the-history-of-threads/ that's when threads where *reinvented*. They were originally invented in 1965, on Multics (1970) they were used to perform compilation in the background. When Unix came along, it *added* address space separation, introducing what is now known as processes. > The > perceived advantage at the time was the ability to have multiple threads > of control with shared memory: this was much faster than the available > inter-process communication mechanisms. On a single-processor computer > synchronization was much less of a problem. Historically, it was vice versa. First there were threads/processes/tasks with shared variables, semaphores, etc, and later address space separation was added. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beginning developer: fastest way to learn how Python 3.0 works
> Maybe this is the correct list, as my inquiry is about how to learn > how the current implementation works so that I could consider how to > implement new features. > > So, here's a modified question: If you want to learn how python works > (not how to program in the python language), what's a productive way > to proceed? Well, the question is what you want to learn it *for*. If you want to learn in order to contribute, I suggest you pick an old bug on the bug tracker and try to solve it. If you have a specific new feature in mind that you want to implement, I again suggest that you just start implementing it. If you don't know how, then you should ask on python-list how certain things are done that you might need for the feature, or you even explain to python-list readers what the feature is that you want to implement, and how people would go about implementing it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [ANN] Python 2.4.6 and 2.5.3, release candidate 1
Christian Heimes wrote: > Martin v. Löwis schrieb: >> 2.5.3 is the last bug fix release of Python 2.5. Future 2.5.x releases >> will only include security fixes. According to the release notes, over >> 100 bugs and patches have been addressed since Python 2.5.1, many of > > > Do you really mean 2.5.1? Oops, no - although the statement is technically correct; since 2.5.2, only 80 bugs have been added :-) Thanks for pointing that out. Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problem with svn on community buildbot
I have a community buildbot: http://www.python.org/dev/buildbot/community/all/g5%20OSX%202.5/builds/14/step-svn/0 which is failing the svn checkout of the 2.5 branch: svn: PROPFIND request failed on '/projects/python/branches/release25-maint' svn: PROPFIND of '/projects/python/branches/release25-maint': Could not resolve hostname `svn.python.org': Temporary failure in name resolution (http://svn.python.org) The svn command is: /opt/local/bin/svn checkout --revision 67742 --non-interactive http://svn.python.org/projects/python/branches/release25-maint build Any idea what the problem might be? Thanks, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with svn on community buildbot
> svn: PROPFIND of '/projects/python/branches/release25-maint': Could not > resolve hostname `svn.python.org': Temporary failure in name resolution > (http://svn.python.org) > > Any idea what the problem might be? Well - can you resolve `svn.python.org' on that machine (e.g. when using ping(1))? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
