On Thu, 11 Jul 2013 22:28:49 -0400
"R. David Murray" wrote:
> On Fri, 12 Jul 2013 13:49:54 +1200, Ben Hoyt wrote:
> > I guess it has to be dropped at some stage, but with Windows XP it's a case
> > of "XP is dead. Long live XP!" There are still an awful lot of XP boxes out
> > there, and I'd kind
Am 12.07.2013 03:49, schrieb Ben Hoyt:
> I guess it has to be dropped at some stage, but with Windows XP it's a
> case of "XP is dead. Long live XP!" There are still an awful lot of XP
> boxes out there, and I'd kind hate to see support dropped completely. We
> still use it here at home.
>
> Wikip
On Thu, Jul 11, 2013 at 6:58 PM, Christian Heimes wrote:
> For Python 3.4 is going to be a very close call. According to PEP 429
> 3.4.0 final is scheduled for February 22, 2014. The extended support
> phase of Windows XP ends merely 45 days later on April 8, 2014. Do we
> really have to restrict
You underestimate the reach of XP. For older or underpowered hardware
outside the developed world it is still the de facto choice. And it
definitely is the best version of Windows ever. None of the Win98 crap and
none of the Vista junk.
Telling people to go install Ubuntu is not really fair if oth
ACTIVITY SUMMARY (2013-07-05 - 2013-07-12)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4067 ( -5)
closed 26140 (+74)
total 30207 (+69)
Open issues wit
On 7/12/2013 8:50 AM, Guido van Rossum wrote:
You underestimate the reach of XP. For older or underpowered hardware
outside the developed world it is still the de facto choice. And it
definitely is the best version of Windows ever. None of the Win98 crap
and none of the Vista junk.
Telling
Sorry for the delay; work got in the way.
On 07Jul2013 15:21, Victor Stinner wrote:
| Ok, I think that the best consensus here is to add a new
| os.set_blocking() function. The function would not be available on
| Windows, but should be available on all UNIX platforms.
Thanks.
| See the diff:
|
On Feb 27, 2013 4:31 AM, "Michael Foord" wrote:
>
>
> On 27 Feb 2013, at 11:00, David Beazley wrote:
>
> >>
> >> From: Eli Bendersky
> >>
> >> I'll be the first one to admit that pycparser is almost certainly not
> >> generally useful enough to be exposed in the stdlib. So just using it
as an
>
On 7/13/2013 12:10 AM, Eric Snow wrote:
On Feb 27, 2013 4:31 AM, "Michael Foord"
> +1 PLY is capable and well tried-and-tested. We used it in Resolver
One to implement a pretty large grammar and it is (in my opinion) best
of breed in the Python parser generator world. Being stable and widely
David Beasley; see earlier in this same thread:
http://mail.python.org/pipermail/python-dev/2013-February/thread.html#124389
On Fri, Jul 12, 2013 at 9:41 PM, Terry Reedy wrote:
> On 7/13/2013 12:10 AM, Eric Snow wrote:
>
>>
>> On Feb 27, 2013 4:31 AM, "Michael Foord" >
>
> > +1 PLY is capab
Is there any semantic difference between
BUILD_TUPLE 0
LOAD_CONST
MAKE_CLOSURE 0
and
LOAD_CONST
MAKE_FUNCTION 0
?
In other words is there any difference between a function and a closure
that doesn't capture anything? Is it just a speed optimization for a common
case?
And
11 matches
Mail list logo
