Re: [Python-Dev] "Fixing" the new GIL

On 13Mar2010 23:03, Martin v. L�wis wrote: | > Any thoughts? | | My initial reaction to this report, and still my current opinion is: | This issue is not a problem. | It's a boundary case, so it's not clear whether Python should be able to | deal with it gracefully. I doubt it's a realistic case.

Re: [Python-Dev] "Fixing" the new GIL

Brett Cannon wrote: > > > On Sat, Mar 13, 2010 at 13:52, Benjamin Peterson > wrote: > > 2010/3/13 Antoine Pitrou >: > > Any thoughts? > \ > The latter solution seems best to me as it would help any 3rd party IO > l

Re: [Python-Dev] "Fixing" the new GIL

On Sat, Mar 13, 2010 at 13:52, Benjamin Peterson wrote: > 2010/3/13 Antoine Pitrou : > > Any thoughts? > \ > The latter solution seems best to me as it would help any 3rd party IO > libraries and require less code modification. > Plus the interactiveness approach has been tested by OS thread sche

Re: [Python-Dev] "Fixing" the new GIL

Le Sat, 13 Mar 2010 17:11:41 -0600, s...@pobox.com a écrit : > > If the 5ms interval is too long would it be possible to adaptively > reduce it in this situation? How would you detect it? I assume this > would be akin to your interactiveness computation. I think modulating the interval is what

Re: [Python-Dev] "Fixing" the new GIL

If the 5ms interval is too long would it be possible to adaptively reduce it in this situation? How would you detect it? I assume this would be akin to your interactiveness computation. Skip ___ Python-Dev mailing list Python-Dev@python.org http://ma

Re: [Python-Dev] "Fixing" the new GIL

On Sat, Mar 13, 2010 at 3:46 PM, Antoine Pitrou wrote: > - the second mechanism dynamically computes the "interactiveness" of a > thread and allows interactive threads to steal the GIL quickly. In > this approach, IO methods don't have to be modified at all. > I like the second approach as wel

Re: [Python-Dev] "Fixing" the new GIL

> Any thoughts? My initial reaction to this report, and still my current opinion is: This issue is not a problem. It's a boundary case, so it's not clear whether Python should be able to deal with it gracefully. I doubt it's a realistic case. Regards, Martin

Re: [Python-Dev] "Fixing" the new GIL

2010/3/13 Antoine Pitrou : > Any thoughts? \ The latter solution seems best to me as it would help any 3rd party IO libraries and require less code modification. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python

[Python-Dev] "Fixing" the new GIL

Hello, As some of you may know, Dave Beazley recently exhibited a situation where the new GIL shows quite a poor behaviour (the old GIL isn't very good either, but still a little better). This issue is followed in http://bugs.python.org/issue7946 This situation is when an IO-bound thread wants t

Re: [Python-Dev] Patch to telnetlib.py

On Sat, Mar 13, 2010 at 12:24 PM, gregory dudek wrote: > The Telnet module telnetlib.py can be > very slow -- unusably slow -- for large automated data transfers.  There are > typically done in raw mode. > > The attached patch greatly increased the speed of telnet interactions in raw > mode.  I

Re: [Python-Dev] C++

On Sat, Mar 13, 2010 at 6:00 AM, Neal Becker wrote: > Neil Hodgson wrote: > >> Antoine Pitrou: >> >>> Is this concern still valid? We are in the 2010s now. >>> I'm not saying I want us to put some C++ in the core interpreter, but >>> the portability argument sounds a little old... >> >>    There a

Re: [Python-Dev] Patch to telnetlib.py

On Sat, Mar 13, 2010 at 9:24 AM, gregory dudek wrote: > The Telnet module telnetlib.py can be > very slow -- unusably slow -- for large automated data transfers.  There are > typically done in raw mode. > > The attached patch greatly increased the speed of telnet interactions in raw > mode.  I s

Re: [Python-Dev] Patch to telnetlib.py

Can you create an issue on the bug tracker? Otherwise this will get lost. Eric. On 3/13/2010 12:24 PM, gregory dudek wrote: The Telnet module telnetlib.py can be very slow -- unusably slow -- for large automated data transfers. There are typically done in raw mode. The attached patch greatly

Re: [Python-Dev] Patch to telnetlib.py

On 3/13/2010 12:24 PM, gregory dudek wrote: The Telnet module telnetlib.py can be very slow -- unusably slow -- for large automated data transfers. There are typically done in raw mode. The attached patch Please submit to the tracker. If there is an existing issue, attach it to that.

[Python-Dev] Patch to telnetlib.py

The Telnet module telnetlib.py can be very slow -- unusably slow -- for large automated data transfers. There are typically done in raw mode. The attached patch greatly increased the speed of telnet interactions in raw mode. I submitted this a couple of year ago, but it was for an older branch

Re: [Python-Dev] C++

Jeffrey> If you know of platforms that don't support particular features Jeffrey> of C++, please link to documentation of that like Neil Hodgson Jeffrey> did. If not, please stop spreading FUD. No need to get your knickers in a twist. Every couple years someone asks, "why isn't Pytho

Re: [Python-Dev] __file__ and bytecode-only

Barry Warsaw wrote: > *creation* is the key here. As per BDFL pronouncement, we'll support reading > pyc-only modules just like we do today. This is in PEP 3147. We won't > support creating them though. The creation side could be made a little more explicit in the PEP. We could also do somethin

Re: [Python-Dev] C++

Neil Hodgson wrote: > Antoine Pitrou: > >> Is this concern still valid? We are in the 2010s now. >> I'm not saying I want us to put some C++ in the core interpreter, but >> the portability argument sounds a little old... > >There are still viable platforms which only support subsets of C++.

Re: [Python-Dev] interesting article on regex performance

Collin Winter wrote: > On Fri, Mar 12, 2010 at 8:12 AM, Nick Coghlan wrote: >> There are major practical problems associated with making such a leap >> directly (Google's re2 engine is in C++ rather than C and we'd have to >> keep the existing implementation around regardless to handle the >> feat

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

Am 04.03.2010 21:20, schrieb Brett Cannon: > 1) I miss not having the affected files listed in the subject line. > > 2) The To field is set to h...@python.org which > gets rejected as an invalid email address if you reply. Would be better > to set it to python-checkins so