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 mailto:h...@python.org which
gets rejected as an invalid email address if you reply. Would be better
to set it to python-checkins so that
Collin Winter wrote:
On Fri, Mar 12, 2010 at 8:12 AM, Nick Coghlan ncogh...@gmail.com 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
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++.
IIRC,
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 something
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 Python
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
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.
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
On Sat, Mar 13, 2010 at 9:24 AM, gregory dudek du...@cim.mcgill.ca 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
On Sat, Mar 13, 2010 at 6:00 AM, Neal Becker ndbeck...@gmail.com 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
On Sat, Mar 13, 2010 at 12:24 PM, gregory dudek du...@cim.mcgill.ca 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
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
2010/3/13 Antoine Pitrou solip...@pitrou.net:
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
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
On Sat, Mar 13, 2010 at 3:46 PM, Antoine Pitrou solip...@pitrou.net 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
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
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
On Sat, Mar 13, 2010 at 13:52, Benjamin Peterson benja...@python.orgwrote:
2010/3/13 Antoine Pitrou solip...@pitrou.net:
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
Brett Cannon wrote:
On Sat, Mar 13, 2010 at 13:52, Benjamin Peterson benja...@python.org
mailto:benja...@python.org wrote:
2010/3/13 Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net:
Any thoughts?
\
The latter solution seems best to me as it would
On 13Mar2010 23:03, Martin v. L�wis mar...@v.loewis.de 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
20 matches
Mail list logo
