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 [email protected] which > gets rejected as an invalid email address if you reply. Would be better > to set it to python-checkins so

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] 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] __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++

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

[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] 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.

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 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] 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 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

[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] "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 [email protected] http://mail.python

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

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

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 [email protected] http://ma

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

Le Sat, 13 Mar 2010 17:11:41 -0600, [email protected] 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

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

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 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.