[Python-Dev] Bug in 3.1.2 site.py
I think I've found a bug in the site.py of 3.1.2. The following piece of code tries to make the modules that are normally installed under lib-dynload available when running from the build directory: """Append ./build/lib. in case we're running in the build dir (especially for Guido :-)""" from distutils.util import get_platform s = "build/lib.%s-%.3s" % (get_platform(), sys.version) if hasattr(sys, 'gettotalrefcount'): s += '-pydebug' s = os.path.join(os.path.dirname(sys.path[-1]), s) sys.path.append(s) However, it doesn't always work, because distutils.util.get_platform tries to find a Makefile in the install location, which doesn't exist if the Python you're building has never been installed! -- 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] [Python-checkins] r83885 - in python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
On Mon, Aug 9, 2010 at 8:47 PM, antoine.pitrou wrote: > Author: antoine.pitrou > Date: Mon Aug 9 12:47:46 2010 > New Revision: 83885 > > Log: > Revert r83877 in order to fix compilation Is this still a problem even after the later checkins to fix the circular build dependency by adding _collections to the static part of the build? Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] [Python-checkins] r83885 - in python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
On Mon, Aug 09, 2010 at 10:16:24PM +1000, Nick Coghlan wrote: > On Mon, Aug 9, 2010 at 8:47 PM, antoine.pitrou > > Log: > > Revert r83877 in order to fix compilation > > Is this still a problem even after the later checkins to fix the > circular build dependency by adding _collections to the static part of > the build? The buildbot page said this: Modules/Setup.dist is newer than Modules/Setup; check to make sure you have all the updates you need in your Modules/Setup file. Usually, copying Modules/Setup.dist to Modules/Setup will work. Do you know what needs to done for making Modules/Setup to reflect the changes in Modules/Setup.dist in the buildbots? On local checkouts, the compilation goes fine. -- Senthil We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -- Larry Wall ___ 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] r83885 - in python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
On Mon, 9 Aug 2010 22:16:24 +1000 Nick Coghlan wrote: > On Mon, Aug 9, 2010 at 8:47 PM, antoine.pitrou > wrote: > > Author: antoine.pitrou > > Date: Mon Aug 9 12:47:46 2010 > > New Revision: 83885 > > > > Log: > > Revert r83877 in order to fix compilation > > Is this still a problem even after the later checkins to fix the > circular build dependency by adding _collections to the static part of > the build? Yes, it is. Apparently, there is another problem remaining: Traceback (most recent call last): File "./setup.py", line 7, in from glob import glob File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/glob.py", line 6, in import fnmatch File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/fnmatch.py", line 15, in import functools File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/functools.py", line 15, in from collections import OrderedDict, Counter File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/collections.py", line 9, in from _collections import deque, defaultdict ImportError: No module named _collections [31908 refs] make: *** [sharedmods] Error 1 http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1838/steps/compile/logs/stdio ___ 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] [Python-checkins] r83885 - in python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
On Mon, Aug 9, 2010 at 10:25 PM, Senthil Kumaran wrote: > Do you know what needs to done for making Modules/Setup to reflect > the changes in Modules/Setup.dist in the buildbots? > On local checkouts, the compilation goes fine. The buildbot checkout scripts should probably do that copy as a matter of course. There's no reason to support local modifications of Modules/Setup on the buildbots. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] r83885 - in python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
On Mon, 9 Aug 2010 22:34:18 +1000 Nick Coghlan wrote: > On Mon, Aug 9, 2010 at 10:25 PM, Senthil Kumaran wrote: > > Do you know what needs to done for making Modules/Setup to reflect > > the changes in Modules/Setup.dist in the buildbots? > > On local checkouts, the compilation goes fine. > > The buildbot checkout scripts should probably do that copy as a matter > of course. There's no reason to support local modifications of > Modules/Setup on the buildbots. Florent found out that removing Modules/Setup is done as part of the "clean" stage: http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1820/steps/clean/logs/stdio but the "clean" stage doesn't get run after a compile error: http://www.python.org/dev/buildbot/waterfall?show=x86%20gentoo%203.x Regards Antoine. ___ 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] r83885 - in python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
On Mon, Aug 9, 2010 at 10:46 PM, Antoine Pitrou wrote: > On Mon, 9 Aug 2010 22:34:18 +1000 > Nick Coghlan wrote: >> On Mon, Aug 9, 2010 at 10:25 PM, Senthil Kumaran wrote: >> > Do you know what needs to done for making Modules/Setup to reflect >> > the changes in Modules/Setup.dist in the buildbots? >> > On local checkouts, the compilation goes fine. >> >> The buildbot checkout scripts should probably do that copy as a matter >> of course. There's no reason to support local modifications of >> Modules/Setup on the buildbots. > > Florent found out that removing Modules/Setup is done as part of the > "clean" stage: > http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1820/steps/clean/logs/stdio > but the "clean" stage doesn't get run after a compile error: > http://www.python.org/dev/buildbot/waterfall?show=x86%20gentoo%203.x In that case, once you get a clean run through on the buildbots (with the setup.py changes now in place), you should be OK to check the fnmatch and re changes back in. Longer term, the buildbot setup should be modified to run the cleanup step even if the compilation step fails. I'm assume that is something Martin needs to set up. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] r83885 - in python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
On Mon, Aug 9, 2010 at 8:56 AM, Nick Coghlan wrote: > Longer term, the buildbot setup should be modified to run the cleanup > step even if the compilation step fails. Running "make clean" after checkout/update should work as well. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] [Python-checkins] r83890 - python/branches/py3k/Lib/inspect.py
On Mon, Aug 9, 2010 at 11:05 PM, benjamin.peterson wrote: > -if hasattr(sys, '_getframe'): > - currentframe = sys._getframe > -else: > - currentframe = lambda _=None: None > +def currentframe(): > + """Return the frame or the caller or None if this is not possible.""" > + return sys._getframe(1) if hasattr(sys, "_getframe") else None It isn't hugely important, but with sys._getframe() unlikely to appear during runtime, the following may make more sense: if hasattr(sys, '_getframe'): def currentframe(): return sys._getframe(1) else: def currentframe(): pass currentframe.__doc__ = "Return the frame of the caller or None if this is not possible." (Oh, and there's a typo in the docstring...) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] [Python-checkins] r83890 - python/branches/py3k/Lib/inspect.py
2010/8/9 Nick Coghlan : > On Mon, Aug 9, 2010 at 11:05 PM, benjamin.peterson > wrote: >> -if hasattr(sys, '_getframe'): >> - currentframe = sys._getframe >> -else: >> - currentframe = lambda _=None: None >> +def currentframe(): >> + """Return the frame or the caller or None if this is not possible.""" >> + return sys._getframe(1) if hasattr(sys, "_getframe") else None > > It isn't hugely important, but with sys._getframe() unlikely to appear > during runtime, the following may make more sense: > > if hasattr(sys, '_getframe'): > def currentframe(): > return sys._getframe(1) > else: > def currentframe(): > pass > currentframe.__doc__ = "Return the frame of the caller or None if this > is not possible." I considered that but found the docstring thing ugly. > > (Oh, and there's a typo in the docstring...) Thanks. -- Regards, Benjamin ___ 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] [Python-checkins] r83890 - python/branches/py3k/Lib/inspect.py
On Mon, Aug 9, 2010 at 11:48 AM, Benjamin Peterson wrote: > 2010/8/9 Nick Coghlan : >> On Mon, Aug 9, 2010 at 11:05 PM, benjamin.peterson >> wrote: >>> -if hasattr(sys, '_getframe'): >>> - currentframe = sys._getframe >>> -else: >>> - currentframe = lambda _=None: None >>> +def currentframe(): >>> + """Return the frame or the caller or None if this is not possible.""" >>> + return sys._getframe(1) if hasattr(sys, "_getframe") else None >> >> It isn't hugely important, but with sys._getframe() unlikely to appear >> during runtime, the following may make more sense: >> >> if hasattr(sys, '_getframe'): >> def currentframe(): >> return sys._getframe(1) >> else: >> def currentframe(): >> pass >> currentframe.__doc__ = "Return the frame of the caller or None if this >> is not possible." > > I considered that but found the docstring thing ugly. > I think I have a brighter color for this bikeshed: if hasattr(sys, '_getframe'): def currentframe(): "Return the frame of the caller." .. else: def currentframe(): "Not supported on this platform. Always returns None." .. The working version's docstring may also explain that it may return None on some platforms. ___ 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] mingw support?
> Terry Reedy: >MingW has become less attractive in recent years by the difficulty > in downloading and installing a current version and finding out how to > do so. Some projects have moved on to the TDM packaging of MingW. > > http://tdm-gcc.tdragon.net/ MinGW has become a mess. Equation.com used to have a decent installer, but at some point they started to ship mingw builds with a Trojan. TDM looks OK for now. Building 32-bit Python extension works with MinGW. 64-bit extensions are not possible due to lacking import libraries (no libmsvcr90.a and libpython26.a for amd64). It is not possible to build Python with mingw, only extensions. I think it is possible to build Python with Microsoft's SDK compiler, as it has nmake. The latest is Windows 7 SDK for .NET 4, but we need the version for .NET 3.5 to maintain CRT compatibility with current Python releases. Python's distutils do not work with the SDK compiler, only Visual Studio. Building Python extensions with the SDK compiler is not as easy as it could (or should) be. One advantage of mingw for scientific programmers (which a frequent users of Python) is the gfortran compiler. Although it is not as capable as Absoft or Intel Fortran, it is still decent and can be used with f2py. This makes the lack of 64-bit support for Python extensions with mingw particularly annoying. Microsoft's SDK does not have a Fortran compiler, and commercial versions are very expensive (though I prefer to pay for Absoft anyway). I do not wish for a complete build process for mingw. But support for 64-bit exensions with mingw and distutils support for Microsoft's SDK compiler would be nice. Sturla ___ 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] mingw support?
On Mon, Aug 9, 2010 at 11:47 AM, Sturla Molden wrote: >> Terry Reedy: > >> MingW has become less attractive in recent years by the difficulty >> in downloading and installing a current version and finding out how to >> do so. Some projects have moved on to the TDM packaging of MingW. >> >> http://tdm-gcc.tdragon.net/ > > > MinGW has become a mess. Equation.com used to have a decent installer, but > at some point they started to ship mingw builds with a Trojan. TDM looks > OK for now. > > Building 32-bit Python extension works with MinGW. 64-bit extensions are > not possible due to lacking import libraries (no libmsvcr90.a and > libpython26.a for amd64). It is not possible to build Python with mingw, > only extensions. > > I think it is possible to build Python with Microsoft's SDK compiler, as > it has nmake. The latest is Windows 7 SDK for .NET 4, but we need the > version for .NET 3.5 to maintain CRT compatibility with current Python > releases. > > Python's distutils do not work with the SDK compiler, only Visual Studio. > Building Python extensions with the SDK compiler is not as easy as it > could (or should) be. Based on hints here: http://docs.python.org/distutils/apiref.html?highlight=sdk#module-distutils.msvccompiler I've been able to build GMPY and MPIR using just SDK compiler. For an example, see http://code.google.com/p/gmpy/source/browse/trunk/win_x64_sdk_build.txt I agree that it should be easier but it is possible. casevh > > One advantage of mingw for scientific programmers (which a frequent users > of Python) is the gfortran compiler. Although it is not as capable as > Absoft or Intel Fortran, it is still decent and can be used with f2py. > This makes the lack of 64-bit support for Python extensions with mingw > particularly annoying. Microsoft's SDK does not have a Fortran compiler, > and commercial versions are very expensive (though I prefer to pay for > Absoft anyway). > > I do not wish for a complete build process for mingw. But support for > 64-bit exensions with mingw and distutils support for Microsoft's SDK > compiler would be nice. > > Sturla > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/casevh%40gmail.com > ___ 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] r83869 - in python/branches/py3k: Doc/library/socket.rst Doc/whatsnew/3.2.rst Lib/ssl.py Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c
On Sun, 08 Aug 2010 19:53:38 -0400 Eric Smith wrote: > On 8/8/10 7:48 PM, Antoine Pitrou wrote: > > On Mon, 9 Aug 2010 01:24:50 +0200 (CEST) > > antoine.pitrou wrote: > >> Author: antoine.pitrou > >> Date: Mon Aug 9 01:24:50 2010 > >> New Revision: 83869 > >> > >> Log: > >> Issue #8524: Add a forget() method to socket objects, so as to put the > >> socket into the closed state without closing the underlying file > >> descriptor. > > > > Benjamin suggested to call this detach() instead. What do you think? > > detach() is the name I've seen most often for this. For example, that's > what MFC uses: > http://msdn.microsoft.com/en-us/library/7zhdchw8(VS.80).aspx Thanks. I've done the rename in r83908. Regards Antoine. ___ 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] mingw support?
> Python's distutils do not work with the SDK compiler, only Visual Studio. That is not true. 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] mingw support?
On 8/9/2010 2:47 PM, Sturla Molden wrote: >> Terry Reedy: [...] > > Python's distutils do not work with the SDK compiler, only Visual Studio. > Building Python extensions with the SDK compiler is not as easy as it > could (or should) be. > At one point Mike Fletcher published a patch to make distutils use the SDK compiler. It would make a lot of sense if it were built in to distutils as a further compiler choice. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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] mingw support?
Am 09.08.2010 23:00, schrieb Steve Holden: > On 8/9/2010 2:47 PM, Sturla Molden wrote: >>> Terry Reedy: > [...] >> >> Python's distutils do not work with the SDK compiler, only Visual Studio. >> Building Python extensions with the SDK compiler is not as easy as it >> could (or should) be. >> > At one point Mike Fletcher published a patch to make distutils use the > SDK compiler. It would make a lot of sense if it were built in to > distutils as a further compiler choice. Please understand that this very choice is there already. 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] mingw support?
On 8/9/2010 5:37 PM, "Martin v. Löwis" wrote: > Am 09.08.2010 23:00, schrieb Steve Holden: >> On 8/9/2010 2:47 PM, Sturla Molden wrote: Terry Reedy: >> [...] >>> >>> Python's distutils do not work with the SDK compiler, only Visual Studio. >>> Building Python extensions with the SDK compiler is not as easy as it >>> could (or should) be. >>> >> At one point Mike Fletcher published a patch to make distutils use the >> SDK compiler. It would make a lot of sense if it were built in to >> distutils as a further compiler choice. > > Please understand that this very choice is there already. > That's great. Is that what the documentation refers to when it says """ MSVCCompiler will normally choose the right compiler, linker etc. on its own. To override this choice, the environment variables DISTUTILS_USE_SDK and MSSdk must be both set. MSSdk indicates that the current environment has been setup by the SDK’s SetEnv.Cmd script, or that the environment variables had been registered when the SDK was installed; DISTUTILS_USE_SDK indicates that the distutils user has made an explicit choice to override the compiler selection by MSVCCompiler. """ That isn't particularly clear to me, but it may be to others more familiar with building on Windows. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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] mingw support?
>> Please understand that this very choice is there already. >> > That's great. Is that what the documentation refers to when it says Correct. > That isn't particularly clear to me, but it may be to others more > familiar with building on Windows. People familiar with that documentation fragment had no problem making it work. The problem has rather been that people didn't expect that to be supported, and didn't try to determine whether it was supported. If you search for "SDK" in the online documentation, this will be the only piece that comes up. Not sure when Mike Fletcher wrote his code - if it is recent, he surely must have run into the feature while reading the existing code base. 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] mingw support?
>> Please understand that this very choice is there already.
>>
> That's great. Is that what the documentation refers to when it says
>
> """
> MSVCCompiler will normally choose the right compiler, linker etc. on its
> own. To override this choice, the environment variables
> DISTUTILS_USE_SDK and MSSdk must be both set. MSSdk indicates that the
> current environment has been setup by the SDK?s SetEnv.Cmd script, or
> that the environment variables had been registered when the SDK was
> installed; DISTUTILS_USE_SDK indicates that the distutils user has made
> an explicit choice to override the compiler selection by MSVCCompiler.
> """
>
> That isn't particularly clear to me, but it may be to others more
> familiar with building on Windows.
Ahh...
"MSSdk must be set" typically means we must use the Windows 7 SDK command
prompt.
Without DISTUTILS_USE_SDK, the build fails:
C:\DEVELOPMENT\test-distutils>setup.py build_ext
running build_ext
building 'test' extension
Traceback (most recent call last):
File "C:\DEVELOPMENT\test-distutils\setup.py", line 6, in
ext_modules=[Extension('test', ['test.c'])],
File "C:\Python26\lib\distutils\core.py", line 152, in setup
dist.run_commands()
File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
self.run_command(cmd)
File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
File "C:\Python26\lib\distutils\command\build_ext.py", line 340, in run
self.build_extensions()
File "C:\Python26\lib\distutils\command\build_ext.py", line 449, in
build_exte
nsions
self.build_extension(ext)
File "C:\Python26\lib\distutils\command\build_ext.py", line 499, in
build_exte
nsion
depends=ext.depends)
File "C:\Python26\lib\distutils\msvc9compiler.py", line 449, in compile
self.initialize()
File "C:\Python26\lib\distutils\msvc9compiler.py", line 359, in initialize
vc_env = query_vcvarsall(VERSION, plat_spec)
File "C:\Python26\lib\distutils\msvc9compiler.py", line 275, in
query_vcvarsal
l
raise ValueError(str(list(result.keys(
ValueError: [u'path', u'include', u'lib']
Now let's do what the documentations says:
C:\DEVELOPMENT\test-distutils>set DISTUTILS_USE_SDK=1
C:\DEVELOPMENT\test-distutils>setup.py build_ext
running build_ext
building 'test' extension
creating build
creating build\temp.win-amd64-2.6
creating build\temp.win-amd64-2.6\Release
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\cl.exe /c
/nolog
o /Ox /MD /W3 /GS- /DNDEBUG -IC:\Python26\include -IC:\Python26\PC
/Tctest.c /Fo
build\temp.win-amd64-2.6\Release\test.obj
test.c
creating build\lib.win-amd64-2.6
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\link.exe
/DLL /n
ologo /INCREMENTAL:NO /LIBPATH:C:\Python26\libs
/LIBPATH:C:\Python26\PCbuild\amd
64 /EXPORT:inittest build\temp.win-amd64-2.6\Release\test.obj
/OUT:build\lib.win
-amd64-2.6\test.pyd /IMPLIB:build\temp.win-amd64-2.6\Release\test.lib
/MANIFESTF
ILE:build\temp.win-amd64-2.6\Release\test.pyd.manifest
test.obj : warning LNK4197: export 'inittest' specified multiple times;
using fi
rst specification
Creating library build\temp.win-amd64-2.6\Release\test.lib and object
build\t
emp.win-amd64-2.6\Release\test.exp
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64\mt.exe -nologo
-manifest bu
ild\temp.win-amd64-2.6\Release\test.pyd.manifest
-outputresource:build\lib.win-a
md64-2.6\test.pyd;2
:-D
Sturla
___
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] mingw support?
>> At one point Mike Fletcher published a patch to make distutils use the >> SDK compiler. It would make a lot of sense if it were built in to >> distutils as a further compiler choice. > > Please understand that this very choice is there already. > Yes you are right. I did not know about DISTUTILS_USE_SDK. Sturla ___ 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] mingw support?
On 8/9/2010 2:47 PM, Sturla Molden wrote: Terry Reedy: MingW has become less attractive in recent years by the difficulty in downloading and installing a current version and finding out how to do so. Some projects have moved on to the TDM packaging of MingW. http://tdm-gcc.tdragon.net/ Someone else deserves credit for writing that and giving that link ;-) -- Terry Jan Reedy ___ 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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky wrote: > +PS: In the standard Python distribution, this file is encoded in UTF-8 > +and the list is in rough alphabetical order by last names. > > David Abrahams > Jim Ahlstrom > @@ -28,6 +29,7 @@ > Éric Araujo > Jason Asbahr > David Ascher > +Peter Åstrand >From my recollection of the discussion when Peter was added, the first character in his last name actually sorts after Z (despite its resemblance to an A). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
2010/8/9 Nick Coghlan : > On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky > wrote: >> +PS: In the standard Python distribution, this file is encoded in UTF-8 >> +and the list is in rough alphabetical order by last names. >> >> David Abrahams >> Jim Ahlstrom >> @@ -28,6 +29,7 @@ >> Éric Araujo >> Jason Asbahr >> David Ascher >> +Peter Åstrand > > >From my recollection of the discussion when Peter was added, the first > character in his last name actually sorts after Z (despite its > resemblance to an A). This is correct. Don't think of Å as a kind of "A". It's its own letter, which sorts after Z in Swedish. -- Regards, Benjamin ___ 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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
Was it on IRC? I do remember discussion, but forgot the answer. :( Do you agree that ACKS should be the same in the active branches? I'll fix the order when I merge the lists. On Aug 9, 2010, at 10:53 PM, Benjamin Peterson wrote: 2010/8/9 Nick Coghlan : On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky wrote: +PS: In the standard Python distribution, this file is encoded in UTF-8 +and the list is in rough alphabetical order by last names. David Abrahams Jim Ahlstrom @@ -28,6 +29,7 @@ Éric Araujo Jason Asbahr David Ascher +Peter Åstrand From my recollection of the discussion when Peter was added, the first character in his last name actually sorts after Z (despite its resemblance to an A). This is correct. Don't think of Å as a kind of "A". It's its own letter, which sorts after Z in Swedish. -- Regards, Benjamin ___ Python-checkins mailing list [email protected] http://mail.python.org/mailman/listinfo/python-checkins ___ 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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
On Tue, Aug 10, 2010 at 1:24 PM, Alexander Belopolsky wrote: > Was it on IRC? I do remember discussion, but forgot the answer. :( python-dev or python-checkins I think, but I don't really remember. (Not IRC though, as I only very rarely drop in on the channel) > Do you agree that ACKS should be the same in the active branches? I'll fix > the order when I merge the lists. The most important one to keep up to date is the one for the main development branch, since that should be a superset of all the others. The maintenance branches will naturally be missing new contributors (aside from those contributing bug fixes for that branch), and that's OK. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
On Mon, Aug 9, 2010 at 11:32 PM, Nick Coghlan wrote: > On Tue, Aug 10, 2010 at 1:24 PM, Alexander Belopolsky > wrote: >> Was it on IRC? I do remember discussion, but forgot the answer. :( > > python-dev or python-checkins I think, but I don't really remember. > (Not IRC though, as I only very rarely drop in on the channel) > I'll search the archives. My reasoning was that Å in Åstrand was the same as Å in Ångström. Webster's dictionary (1992 edition that was on my bookshelf) has Ångström (Anders Jonas) between angstrom (the unit) and Anguilla (an island). >> Do you agree that ACKS should be the same in the active branches? I'll fix >> the order when I merge the lists. > > The most important one to keep up to date is the one for the main > development branch, since that should be a superset of all the others. > The maintenance branches will naturally be missing new contributors > (aside from those contributing bug fixes for that branch), and that's > OK. > As I mentioned in a tracker comment, it may be useful to sync the lists between the main and development branches to avoid svnmerge conflicts. I think I've seen some names missing from the main branch which exist in maintenance ones. ___ 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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
Am 10.08.2010 04:47, schrieb Nick Coghlan: > On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky > wrote: >> +PS: In the standard Python distribution, this file is encoded in UTF-8 >> +and the list is in rough alphabetical order by last names. >> >> David Abrahams >> Jim Ahlstrom >> @@ -28,6 +29,7 @@ >> Éric Araujo >> Jason Asbahr >> David Ascher >> +Peter Åstrand > >>From my recollection of the discussion when Peter was added, the first > character in his last name actually sorts after Z (despite its > resemblance to an A). That's why it says "rough" alphabetical order. Putting it into either place sounds reasonable - we can just expect people to change it forth and back. 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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
Am 10.08.2010 05:49, schrieb Alexander Belopolsky: > On Mon, Aug 9, 2010 at 11:32 PM, Nick Coghlan wrote: >> On Tue, Aug 10, 2010 at 1:24 PM, Alexander Belopolsky >> wrote: >>> Was it on IRC? I do remember discussion, but forgot the answer. :( >> >> python-dev or python-checkins I think, but I don't really remember. >> (Not IRC though, as I only very rarely drop in on the channel) >> > I'll search the archives. My reasoning was that Å in Åstrand was the > same as Å in Ångström. Webster's dictionary (1992 edition that was on > my bookshelf) has Ångström (Anders Jonas) between angstrom (the unit) > and Anguilla (an island). People need to recognize that any kind of reference is really irrelevant here. There is no "right" order that is better than any other "right" order. I'd personally object to any English language dictionary telling me how my name sorts in the alphabet. (and yes, I do think it's "wrong" that it got sorted after Lyngvig - in Germany, we put the ö as if it was "oe" - unlike the Swedes, which put the very same letter after the rest of the alphabet. So the ö in Chrigström sorts in a different way than the ö in Löwis. If I move to Sweden, the file would have to change :-) 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
