Re: [Python-Dev] Developing/patching ctypes
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 vendor drops. 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 mind it living in /ctypes/trunk, either. Be aware that the set of committers to svn.python.org/projects is currently restricted to Python committers. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes (was: Re: integrating ctypes into python)
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 developers are also python-developers (or at least have svn access), and the source is supposed to be identical, SVN obviously beats SVN :) I can work equally well with the main repository in CVS, though, and I've had quite a bit of practice in merging changes. -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 contain >> only vendor drops... > > > If all the developers are also python-developers (or at least have svn > access), and the source is supposed to be identical, SVN obviously beats SVN I didn't know that SVN is *that great* :) ! > :) I can work equally well with the main repository in CVS, though, and I've > had quite a bit of practice in merging changes. Cool. Martin v. Löwis wrote: > external indeed is meant only for vendor drops. > > 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 mind it living in /ctypes/trunk, either. > Be aware that the set of committers to svn.python.org/projects is > currently restricted to Python committers. I think the currently active ctypes developers are also Python committers, additionally I've asked on the ctypes-users list for objections. I'll think about this stuff over the weekend, currently I tend to moving ctypes to Python SVN. Whether it will be /ctypes/trunk or sandbox/ctypes I don't really care. 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. If anyone (of the Python developers) wants to do this and doesn't currently have commit access, please mail me your SF userid privately. Note that both perky and Thomas Wouters have promised to do Py_ssize_t fixes - please coordinate that to avoid double work. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 mind it living in /ctypes/trunk, either. > Be aware that the set of committers to svn.python.org/projects is > currently restricted to Python committers. Actually, for the most part email pkg lives inside Python and I external it into the sandbox for the standalone releases. email 4.0 is a little different because I wanted to do the development outside Python to reduce the chance of breakage, but I am planning on merging the code back into the Python trunk, possibly this weekend. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
[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.py
from the root of a Python checkout ("cd python; reindent.py -r .").
There's nothing specific to the Python project about that little
procedure, and, e.g., I regularly did the same for Zope Corp's ZODB
project.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 cleanup consists of running reindent.py
> from the root of a Python checkout ("cd python; reindent.py -r .").
> There's nothing specific to the Python project about that little
> procedure, and, e.g., I regularly did the same for Zope Corp's ZODB
> project.
I've nothing against that, and I should myself get used to do the same
in my own repositories from time to time.
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 in verbose
mode by default is probably not a good idea, because it may make tests fail,
AFAIK.
If not, I have no other choice (since I don't have a 64-bit machine myself) than
to test this in the sourceforge compilefarm amd64 machine, which is a pain
since they don't allow outbound network from there.
Thomas
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] multidict API
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 submissions. It would also be ordered in that case. The question then is what the API should look like for such an object -- an ordered, multi-value dictionary. I would really like if this object was in the collections module, but I'm too lazy to try to pursue that now. But if it did show up, I'd like the class I write to look the same. There's some open questions I see: * Does __getitem__ return a list of all matching keys (never a KeyError, though possibly returning []), or does it return the first matching key? * Either way, I assume there will be another method, like getfirst or getall, that will present the other choice. What would it be named? Should it have a default? * Should there be a method to get a single value, that implicitly asserts that there is only one matching key? * Should the default for .get() be None, or something else? * Does __setitem__ overwrite any or all values with matching keys? * If so, there should be another method like .add(key, value) which does not overwrite. Or, if __setitem__ does not overwrite, then there should be a method that does. * Does __delitem__ raise a KeyError if the key is not found? * Does .keys() return all unique keys, or all keys in order (meaning a key may show up more than once in the list)? I really could go either way on all of these questions, though I think there's constraints -- answer one of the questions and another becomes obvious. But you can answer them in whatever order you want. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multidict API
[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 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multidict API
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 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/ASPN/Cookbook/Python/Recipe/438823 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/173072 http://urchin.earth.li/~twic/odict.py http://www.astro.washington.edu/owen/ROPython.html http://home.arcor.de/wolfgang.grafen/Python/Modules/Modules.html email.Message.Message http://cvs.eby-sarna.com/wsgiref/src/wsgiref/headers.py?view=markup Well, there's a few, mostly ordered, some multivalue. A comparison would be helpful, but maybe a little later. odict is probably the most filled-out, though it is probably more listish than I really would like. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 in > verbose > mode by default is probably not a good idea, because it may make tests fail, > AFAIK. 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. > If not, I have no other choice (since I don't have a 64-bit machine myself) > than > to test this in the sourceforge compilefarm amd64 machine, which is a pain > since they don't allow outbound network from there. I ran the test manually last night, there were 12 errors IIRC. It was stuff like strings not being equal. I can't send you the verbose run right now. I'll try to do it when I get a chance, but that won't be before Sunday. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes is in SVN now.
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 chip model, and > generally more heavily penalized as time goes on). In the good old > days, Pentium was one of dozens of competing architectures, and was > the oddball in catering to unaligned access. Now it's eternal > "backward compatibility" with an early implementation accident. Most > other architectures never catered to unaligned access, or did so only > at the cost of generating an interrupt so that kernel-mode software > could fake unaligned access. Bottom line is that unaligned access > isn't portable and never was, and even on architectures where "it > works" it can be extremely expensive to use it. I was astonished to find out that also the ARM processor on Windows CE doesn't support unaligned accesses. When one thinks about it, it probably makes sense on small devices. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicodedata.c no longer compiles on Windows
Tim Peters wrote: > It's griping about this: > > /* Forward declaration */ > static PyMethodDef unicodedata_functions[]; This is now fixed. Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multidict API
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.html) > -- right now I need to implement one to represent web form submissions. > It would also be ordered in that case. FWIW, the email package's Message class implements something similar in its mapping API, to represent message headers. I'm not saying that it's a good general approach to the problem, but I do think the way we solved it works well for Messages. The implementation is also probably not very good for general purposes, since it can involve linear searches of lists, but for Messages, which don't typically have that many headers, I think it's fine. Messages keep track of the order in which the headers are added, and you may have multiple values for each header. If you delete a header and re-add it, it gets added to the end. So iterating over the headers gives you each header in order, including duplicates. __getitem__() however will return only one of those headers; which exactly you get is technically undefined. get() has the same semantics. There's a new get_all() method that takes a key and returns a list of all the values for that key (header). __delitem__() removes all matching keys. > * Does __getitem__ return a list of all matching keys (never a KeyError, > though possibly returning []), or does it return the first matching key? See above -- it returns one matching key, but the spec doesn't specify which one (see the implementation for the obvious answer ;). One other semantic difference with Messages is that __getitem__() on a missing header returns None -- it does not raise a KeyError. Practicality beats purity. > * Either way, I assume there will be another method, like getfirst or > getall, that will present the other choice. What would it be named? > Should it have a default? In Message, it's called get_all() and it does take an optional default, just like get(). > * Should there be a method to get a single value, that implicitly > asserts that there is only one matching key? Message doesn't have this. > * Should the default for .get() be None, or something else? Message.get() defaults to None. > * Does __setitem__ overwrite any or all values with matching keys? Message's __setitem__() appends the header (there's a separate add_header() method that takes a bunch of arguments specific to email headers) but it does not overwrite any existing header. The idiom used to replace a header is usually: del msg['some-header'] msg['Some-Header'] = 'Wizzy Mailerified' Oh yeah, keys are case-preserving but case-insensitive because in email messages 'Some-Header: Foo' is the same as 'some-header: Foo', but we want to be as idempotent as possible. > * If so, there should be another method like .add(key, value) which does > not overwrite. Or, if __setitem__ does not overwrite, then there should > be a method that does. Message.replace_header() preserves header order, and it replaces the value for the first header found. > * Does __delitem__ raise a KeyError if the key is not found? For Message, the answer is "no". > * Does .keys() return all unique keys, or all keys in order (meaning a > key may show up more than once in the list)? Message.keys() returns them in order. Likewise .values() and .items(). > I really could go either way on all of these questions, though I think > there's constraints -- answer one of the questions and another becomes > obvious. But you can answer them in whatever order you want. Cool, thanks! For simplicity, I've answered them in the order they were asked, just like Message would. :) -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multidict API
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/ASPN/Cookbook/Python/Recipe/438823 > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/173072 > http://urchin.earth.li/~twic/odict.py > http://www.astro.washington.edu/owen/ROPython.html > http://home.arcor.de/wolfgang.grafen/Python/Modules/Modules.html > email.Message.Message > http://cvs.eby-sarna.com/wsgiref/src/wsgiref/headers.py?view=markup > > Well, there's a few, mostly ordered, some multivalue. A comparison > would be helpful, but maybe a little later. odict is probably the most > filled-out, though it is probably more listish than I really would like. Actually, my suspicion is that there won't be a general enough solution to warrant inclusion in the stdlib. But hey, if you can create an 80% solution, that would be nice. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 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)? Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 what the buildbot now uses. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 somehow? Running the tests in
>> verbose
>> mode by default is probably not a good idea, because it may make tests fail,
>> AFAIK.
>
> 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.
>
There are also sporadic test failures on the OSX machine:
http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/345/step-test/0
I think the test is broken - but what I find interesting is that in this case
the actual failure
is printed:
"""
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 refcounts
test_long_future
"""
Why is that?
Thomas
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 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 procedure is described in PCbuild/readme.txt. In essence, you install the platform SDK and vsextcomp, and then build the ReleaseAMD64 solution setting. OTOH, the distutils included with Python 2.5 also honor SDK environments (again), so if you install the platform SDK, open an IA64 or AMD64 build environment, and run upstream's setup.py, it /should/ just use the compiler, header files, etc in the path. If that would help, I could provide you with a Python 2.5 MSI file (for x86), to run distutils, and get the 2.5 headers. OTTH, a lot of things don't work on Win64, so people could probably readily accept the lack of ctypes. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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 refcounts
>
> test_long_future
> """
>
> Why is that?
Because it is just a single exception. For that, a traceback is printed.
Not so for multiple failures.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
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/buildbot/all/amd64%20gentoo%20trunk/builds/280/step-test/0 Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making builtins more efficient
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making builtins more efficient
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 don't see why everything that doesn't make sense to be shadowed ought to become a keyword. That way lies madness. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Still looking for volunteer to run Windows buildbot
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 results out of this at all), please contact me. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making builtins more efficient
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 compiler from determining the namespace to look for a given name? I seen nothing in PEP 3000 related to this issue. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making builtins more efficient
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 disallow names from being > shadowed in such as way as to prevent the compiler from determining > the namespace to look for a given name? I seen nothing in PEP 3000 > related to this issue. Yes, that's one of my goals. PEP 280 (clumsily) expresses some of the ideas. Currently, my main idea is to allow the compiler to assume that if a known built-in is used in a module, and inspection of the source code for that module reveals no assignment to a global with the same name, the built-in can be assumed to have the standard semantics, and may be hardcoded in any way the compiler seems fit (for example, an opcode that computes len() would be fair game). Exceptions would be made for 'open' and '__import__' (since these are commonly hacked). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
> > 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 procedure is described in PCbuild/readme.txt. In > essence, you install the platform SDK and vsextcomp, and then build the > ReleaseAMD64 solution setting. I do this for ActivePython builds... by setting up the Platform SDK compiler I want in the environment and then using: devenv.com .../pcbuild.sln /useenv /build Release Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
