Re: [Python-Dev] problems building python2.7
On 9/11/12 17:07:13, R. David Murray wrote: On Fri, 09 Nov 2012 16:44:00 +0100, Hans Mulder han...@xs4all.nl wrote: I looked into it, and the problem is this bit of code (line 230-235): try: self.assertTrue(os.path.exists(tmp_file)) fp = urllib.urlopen(tmp_fileurl) finally: os.close(fd) fp.close() Due to a misconfiguration, urllib.thishost() raises an IOError on my laptop. This causes urllib.urlopen to raise an exception, and the name fp is never bound, so that the fp.close() in the finally clause raises an UnboundLocalError, masking the problem in urlopen. A quick fix would be: try: self.assertTrue(os.path.exists(tmp_file)) fp = urllib.urlopen(tmp_fileurl) fp.close() finally: os.close(fd) That way, the .close is only attempted if the open succeeds. Could you open an issue for this on the tracker, please? That way we won't forget to fix it. Done: issue 16450. -- HansM ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] problems building python2.7
On 9/11/12 10:57:22, Chris Withers wrote: Hi All, I wanted to run the unit tests before checking in the patch for http://bugs.python.org/issue16441, even though it's a trivial change, so I was trying to follow the instructions at: http://docs.python.org/devguide/ I'm on MacOS, so following the unix instructions did: ./configure --with-pydebug make -j2 This appears to have worked, given the end of the output: Python build finished, but the necessary bits to build these modules were not found: _bsddb dl gdbm imageoplinuxaudiodev ossaudiodev readline spwd sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. running build_scripts creating build/scripts-2.7 copying and adjusting /Users/chris/LocalHG/cpython/Tools/scripts/pydoc - build/scripts-2.7 copying and adjusting /Users/chris/LocalHG/cpython/Tools/scripts/idle - build/scripts-2.7 copying and adjusting /Users/chris/LocalHG/cpython/Tools/scripts/2to3 - build/scripts-2.7 copying and adjusting /Users/chris/LocalHG/cpython/Lib/smtpd.py - build/scripts-2.7 changing mode of build/scripts-2.7/pydoc from 644 to 755 changing mode of build/scripts-2.7/idle from 644 to 755 changing mode of build/scripts-2.7/2to3 from 644 to 755 changing mode of build/scripts-2.7/smtpd.py from 644 to 755 [65930 refs] However, I can't find the python it's built... On my system, it's in the current directory. It's called python.exe, to avoid a name clash with the Python subdirectory. I thought I'd be clever and try: buzzkill:cpython chris$ cat build/scripts-2.7/2to3 #!/usr/local/bin/python2.7 ... Presumable, it would be installed in /usr/local/bin if I'd tried make install. There is a python there, but it's a symlink put in place around a year ago. Same here. So, where should I look for the built python? In the current directory: $ ./python.exe Python 2.7.3+ (2.7:8b181c75792f, Nov 9 2012, 11:26:59) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type help, copyright, credits or license for more information. Hope this helps, -- HansM ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] problems building python2.7
On 9/11/12 11:57:39, Chris Withers wrote: On 09/11/2012 10:52, Michael Foord wrote: However, I can't find the python it's built... It should be python.exe (yes really). Hah! Should http://docs.python.org/devguide/ be updated to reflect this or does this only affect Mac OS? (or should we correct the build so it doesn't spit out a .exe?) It only affects MacOS. On other Unix system, the build process spits out an executable named python. On MacOS that's not possible, because that name would clash with the subdirectory named Python. After the build you should be able to do: ./python.exe Unfortunately, still: buzzkill:cpython chris$ ./python.exe -m test -j3 /Users/chris/LocalHG/cpython/python.exe: No module named test.__main__; 'test' is a package and cannot be directly executed [18856 refs] How about make test ? Hope this helps, -- HansM ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] problems building python2.7
On 9/11/12 12:09:26, Hans Mulder wrote: On 9/11/12 11:57:39, Chris Withers wrote: On 09/11/2012 10:52, Michael Foord wrote: However, I can't find the python it's built... It should be python.exe (yes really). Hah! Should http://docs.python.org/devguide/ be updated to reflect this or does this only affect Mac OS? (or should we correct the build so it doesn't spit out a .exe?) It only affects MacOS. On other Unix system, the build process spits out an executable named python. On MacOS that's not possible, because that name would clash with the subdirectory named Python. After the build you should be able to do: ./python.exe Unfortunately, still: buzzkill:cpython chris$ ./python.exe -m test -j3 /Users/chris/LocalHG/cpython/python.exe: No module named test.__main__; 'test' is a package and cannot be directly executed [18856 refs] How about make test ? Hope this helps, -- HansM I tried make test, and I got: test test_urllib failed -- Traceback (most recent call last): File /Users/hans/python/cpython/cpython-2.7/Lib/test/test_urllib.py, line 235, in test_missing_localfile fp.close() UnboundLocalError: local variable 'fp' referenced before assignment Is this a bug in the test suite, or a regression in 2.7.3+ ? This is on MacOS 10.6.5, using a checkout from hg.python.org from earlier today. -- HansM ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] problems building python2.7
On 9/11/12 15:11:26, Chris Withers wrote: On 09/11/2012 11:54, Hans Mulder wrote: I tried make test, and I got: test test_urllib failed -- Traceback (most recent call last): File /Users/hans/python/cpython/cpython-2.7/Lib/test/test_urllib.py, line 235, in test_missing_localfile fp.close() UnboundLocalError: local variable 'fp' referenced before assignment Is this a bug in the test suite, or a regression in 2.7.3+ ? This is on MacOS 10.6.5, using a checkout from hg.python.org from earlier today. I'm on MacOS 10.7.5 and got: 356 tests OK. 35 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_epoll test_gdb test_gdbm test_gl test_imageop test_imgfile test_largefile test_linuxaudiodev test_msilib test_ossaudiodev test_readline test_smtpnet test_socketserver test_startfile test_sunaudiodev test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 4 skips unexpected on darwin: test_dl test_readline test_tk test_ttk_guionly I looked into it, and the problem is this bit of code (line 230-235): try: self.assertTrue(os.path.exists(tmp_file)) fp = urllib.urlopen(tmp_fileurl) finally: os.close(fd) fp.close() Due to a misconfiguration, urllib.thishost() raises an IOError on my laptop. This causes urllib.urlopen to raise an exception, and the name fp is never bound, so that the fp.close() in the finally clause raises an UnboundLocalError, masking the problem in urlopen. A quick fix would be: try: self.assertTrue(os.path.exists(tmp_file)) fp = urllib.urlopen(tmp_fileurl) fp.close() finally: os.close(fd) That way, the .close is only attempted if the open succeeds. -- HansM ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.exists() / os.path.isdir() inconsistency when dealing with gvfs directories
On 27/06/12 02:19:03, Giampaolo Rodolà wrote: 2012/6/27 Cameron Simpson c...@zip.com.au: So I'd be +0.5 for making the docs more clear that True is reliable and False may merely mean could not access. +1 +1 I was about to propose a 'strict' parameter which lets the exception propagate in case of errno != EACCES/EPERM but a doc fix is probably just fine. I'll file a bug report later today. A 'strict' parameter that just propagates the exception might be a good idea. That would allow the user to deal with whatever issues stat() encounters. Arbitrarily mapping EPERM to 'False' would be unhelpful, as it leaves the user in a position where one value can mean two different things. -- HansM ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
On 30/01/12 00:30:14, Steven D'Aprano wrote: Mark Shannon wrote: Antoine Pitrou wrote: [..] Antoine is right. It is a reorganisation of the dict, plus a couple of changes to typeobject.c and object.c to ensure that instance dictionaries do indeed share keys arrays. I don't quite follow how that could work. If I have this: class C: pass a = C() b = C() a.spam = 1 b.ham = 2 how can a.__dict__ and b.__dict__ share key arrays? I've tried reading the source, but I'm afraid I don't understand it well enough to make sense of it. They can't. But then, your class is atypical. Usually, classes initialize all the attributes of their instances in the __init__ method, perhaps like so: class D: def __init__(self, ham=None, spam=None): self.ham = ham self.spam = spam As long as you follow the common practice of not adding any attributes after the object has been initialized, your instances can share their keys array. Mark's patch will do that. You'll still be allowed to have different attributes per instance, but if you do that, then the patch doesn't buy you much. -- HansM ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
