Here's the summary for the first half of September. As always,
comments and corrections are greatly appreciated!
=
Announcements
=
QOTF: Quote of the Fortnight
Through a cross-posting slip-up, Jean-Paul Calderone
> On 10/13/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> I have patched Lib/modulefinder.py to work with absolute and relative
>> imports.
>> It also is faster now, and has basic unittests in
>> Lib/test/test_modulefinder.py.
>>
>> The work was done in a theller_modulefinder SVN branch.
>> If n
> Adam Olsen that Python could create a single non-blocking pipe for a
/that/suggested that/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyt
> On 10/13/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> I have patched Lib/modulefinder.py to work with absolute and relative
>> imports.
>> It also is faster now, and has basic unittests in
>> Lib/test/test_modulefinder.py.
>>
>> The work was done in a theller_modulefinder SVN branch.
>> If n
PEP:
Title: Adding data-type objects to the standard library
Version: $Revision: $
Last-Modified: $Date: $
Author: Travis Oliphant <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Created: 05-Sep-2006
Python-Version: 2.6
Abstract
This PEP proposes adapting the data-type objects fro
Thanks to all of those who have already given me feedback on the last
summary. Here's the next one (for the second half of September). I
found the "OS X universal binaries" and "Finer-grained locking than
the GIL" discussions particularly hard to follow, so I'd especially
appreciate corrections o
Travis E. Oliphant schrieb:
> The datatype is an object that specifies how a certain block of
> memory should be interpreted as a basic data-type.
>
> >>> datatype(float)
> datatype('float64')
I can't speak on the specific merits of this proposal, or whether this
kind of func
On Saturday 28 October 2006 03:13, andrew.kuchling wrote:
> 2.4 backport candidate, probably.
FWIW, I'm not planning on doing any more "collect all the bugfixes" releases
of 2.4. It's now in the same category as 2.3 - that is, only really serious
bugs (in particular, security related bugs) will
Steven Bethard schrieb:
> Jack Howarth asked about creating universal binaries for OS X that
> would support 32-bit or 64-bit on both PPC and x86. Ronald Oussoren
> pointed out that the 32-bit part of this was already supported, but
> indicated that adding 64-bit support simultaneously might be mor
Travis E. Oliphant wrote:
> PEP:
> Title: Adding data-type objects to the standard library
Not sure about having 3 different ways to specify
the structure -- it smacks of Too Many Ways To Do
It to me.
Also, what if I want to refer to fields by name
but don't want to have to work out all the offs
I grabbed the latest Python2.5 code via subversion and ran my typo script on it.
Weeding out the obvious false positives and Neal's comments leaves about 129 typos.
See http://www.geocities.com/typopl/typoscan.htm
Should I enter the typos as bugs in the Python bug db?
J
> Date: Fri, 22 S
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>> PEP:
>> Title: Adding data-type objects to the standard library
I've used 'datatype' below for consistency, but can we please call them
something other than data types? Data layouts? Data formats? Binary layouts?
Binary formats? 'type' is already
Nick Coghlan wrote:
> There are actually 5 ways, but the different mechanisms all have different
> use
> case (and I'm going to suggest getting rid of the dictionary form).
D'oh, I though I deleted that parenthetical comment... obviously, I changed my
mind on this point :)
Cheers,
Nick.
--
N
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> The datatype is an object that specifies how a certain block of
>> memory should be interpreted as a basic data-type.
>>
>> >>> datatype(float)
>> datatype('float64')
>
> I can't speak on the specific merits of this propo
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> The datatype is an object that specifies how a certain block of
>> memory should be interpreted as a basic data-type.
>>
>> >>> datatype(float)
>> datatype('float64')
>
> I can't speak on the specific merits of this propo
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>> PEP:
>> Title: Adding data-type objects to the standard library
>
> Not sure about having 3 different ways to specify
> the structure -- it smacks of Too Many Ways To Do
> It to me.
You might be right, but they all have use-cases. I've actually r
16 matches
Mail list logo
