Thomas Heller wrote:
> Would it be a solution to move the 'official' ctypes development into
> Python SVN external/ctypes, or would this be considered abuse? Another
> location in SVN could be used as well, if external is though to contain
> only vendor drops...
external indeed is meant only for
On 3/10/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
Would it be a solution to move the 'official' ctypes development intoPython SVN external/ctypes, or would this be considered abuse? Anotherlocation in SVN could be used as well, if external is though to contain
only vendor drops...If all the dev
Thomas Wouters wrote:
> On 3/10/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>
>> Would it be a solution to move the 'official' ctypes development into
>> Python SVN external/ctypes, or would this be considered abuse? Another
>> location in SVN could be used as well, if external is though to cont
On Fri, 2006-03-10 at 09:01 +0100, "Martin v. Löwis" wrote:
> I personally don't mind having the "upstream" ctypes repository also
> in svn.python.org; this would be similar to distutils, setuptools,
> and (I think) the email package. Currently, some of them live in
> sandbox/trunk, but I wouldn't
[Thomas Heller]
> ...
> In the meantime, please: If anyone is going to make fixes to the ctypes source
> code (apart from Tim's regular whitespace cleanup), please do this in the
> ctypes CVS repository on sourceforge, in the trunk.
FYI, my regular whitespace cleanup consists of running reindent.p
Tim Peters wrote:
> [Thomas Heller]
>> ...
>> In the meantime, please: If anyone is going to make fixes to the ctypes
>> source
>> code (apart from Tim's regular whitespace cleanup), please do this in the
>> ctypes CVS repository on sourceforge, in the trunk.
>
> FYI, my regular whitespace cleanu
I'm not really making any actionable proposal here, so maybe this is
off-topic; if so, sorry.
Back during the defaultdict discussion I proposed a multidict object
(http://mail.python.org/pipermail/python-dev/2006-February/061264.html)
-- right now I need to implement one to represent web form s
[Ian Bicking]
> The question then is what the API should look like for such an object --
> an ordered, multi-value dictionary.
May I suggest that multidict begin it's life as a cookbook recipe so that its
API can mature.
Raymond
___
Python-Dev mai
Raymond Hettinger wrote:
> [Ian Bicking]
>
>>The question then is what the API should look like for such an object --
>>an ordered, multi-value dictionary.
>
>
> May I suggest that multidict begin it's life as a cookbook recipe so that its
> API can mature.
There's already quite a few recipes
On 3/10/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>
> BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
>
> http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0
>
> Is there a way to get the actual failures somehow? Running the tests i
Tim Peters wrote:
> [Thomas Heller]
>> ...
>> And I never had tried it before on a sparc machine - all the intel and ppc
>> processors
>> seem to have no problems with it.
>
> Pentiums don't enforce "natural" alignment restrictions, but run much
> slower on unaligned access (varying by specific c
Thomas Heller wrote:
> BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
FWIW, ctypes doesn't even build on a Windows AMD64 machine. It wants to
use the Windows x86 FFI code, which does not compile with the AMD64
compiler.
Regards,
Martin
Tim Peters wrote:
> It's griping about this:
>
> /* Forward declaration */
> static PyMethodDef unicodedata_functions[];
This is now fixed.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
On Fri, 2006-03-10 at 11:25 -0600, Ian Bicking wrote:
> I'm not really making any actionable proposal here, so maybe this is
> off-topic; if so, sorry.
>
> Back during the defaultdict discussion I proposed a multidict object
> (http://mail.python.org/pipermail/python-dev/2006-February/061264.htm
On Fri, 2006-03-10 at 12:12 -0600, Ian Bicking wrote:
> There's already quite a few recipes out there. But I should probably
> collect them as well.
>
> http://www.voidspace.org.uk/python/odict.html
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/107747
> http://aspn.activestate.com/A
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
>
> FWIW, ctypes doesn't even build on a Windows AMD64 machine. It wants to
> use the Windows x86 FFI code, which does not compile with the AMD64
> compiler.
On such a mach
Neal Norwitz wrote:
> I want to modify regrtest so the traceback info is stored in a file,
> so you can still retrieve the data after a test run. I haven't
> started making this mod yet.
I took a different approach now, adding an option to regrtest to re-run
failed tests in verbose mode; this is
Neal Norwitz wrote:
> On 3/10/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
>>
>> http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0
>>
>> Is there a way to get the actual failures some
Thomas Heller wrote:
>>FWIW, ctypes doesn't even build on a Windows AMD64 machine. It wants to
>>use the Windows x86 FFI code, which does not compile with the AMD64
>>compiler.
>
>
> On such a machine probably other source files should be used. I have no such
> machine - is it possible to build
Thomas Heller wrote:
> """
> test_set
> test_ctypes
> test test_ctypes failed -- Traceback (most recent call last):
> File "/Users/buildslave/bb/trunk.4/build/Lib/ctypes/test/test_leaks.py",
> line 68, in test_cycles_refcount
> self.fail("leaking refcounts")
> AssertionError: leaking refcoun
Thomas Heller wrote:
> BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
>
> http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0
>
> Is there a way to get the actual failures somehow?
They are now in
http://www.python.org/dev/buildb
Guido van Rossum wrote:
> I don't think we should make any of these keywords.
Not even True and False? The only good reasons
I can see for anyone wanting to shadow these
are backwards compatibility ones.
Greg
___
Python-Dev mailing list
Python-Dev@pyth
On 3/10/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > I don't think we should make any of these keywords.
>
> Not even True and False? The only good reasons
> I can see for anyone wanting to shadow these
> are backwards compatibility ones.
Not even True and False.
I do
Josiah Carlson told me had has given up getting a Windows
buildbot running, because every time he installed VS.NET
on his machine, the installation would immediately crash.
So if anybody wants to contribute both a machine and time
to operate it (including the likely very tedious phase to
get any r
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Not even True and False.
>
> I don't see why everything that doesn't make sense to be shadowed
> ought to become a keyword. That way lies madness.
Have you considered whether P3K will disallow names from being
shadowed in such as way as to prevent the
On 3/10/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Not even True and False.
> >
> > I don't see why everything that doesn't make sense to be shadowed
> > ought to become a keyword. That way lies madness.
>
> Have you considered whether P3K will
> > On such a machine probably other source files should be used. I have no
> > such
> > machine - is it possible to build the 64-bit version on a 32-bit machine
> > (with
> > the platform SDK)?
>
> Indeed, this is possible. I don't know of anybody who does so, so far,
> but in principle, the p
27 matches
Mail list logo
