Mailman 3 November 2010 - Python-Dev

Re: [Python-Dev] [Python-checkins] r84743 - in python/branches/py3k: Doc/license.rst Misc/NEWS Modules/expat/COPYING
by Éric Araujo 05 Dec '10

05 Dec '10

+zlib +---- + +The :mod:`zlib` extension is built using an included copy of the zlib +sources unless the zlib version found on the system is too old to be +used for the build:: Unless or if? Building with an included copy *if* the system one is too old makes sense to me, not the contrary. Am I not seeing something? Regards

2 2

Re: [Python-Dev] [Python-checkins] r86817 - python/branches/py3k-stat-on-windows/Lib/test/test_shutil.py
by Brian Curtin 02 Dec '10

02 Dec '10

On Fri, Nov 26, 2010 at 12:44, hirokazu.yamamoto <python-checkins(a)python.org > wrote: > Author: hirokazu.yamamoto > Date: Fri Nov 26 19:44:28 2010 > New Revision: 86817 > > Log: > Now can reproduce the error on AMD64 Windows Server 2008 > even where os.symlink is not supported. > > > Modified: > python/branches/py3k-stat-on-windows/Lib/test/test_shutil.py > > Modified: python/branches/py3k-stat-on-windows/Lib/test/test_shutil.py > > ============================================================================== > --- python/branches/py3k-stat-on-windows/Lib/test/test_shutil.py > (original) > +++ python/branches/py3k-stat-on-windows/Lib/test/test_shutil.py Fri > Nov 26 19:44:28 2010 > @@ -271,24 +271,32 @@ > shutil.rmtree(src_dir) > shutil.rmtree(os.path.dirname(dst_dir)) > > - @support.skip_unless_symlink > + @unittest.skipUnless(hasattr(os, 'link'), 'requires os.link') > def test_dont_copy_file_onto_link_to_itself(self): > # bug 851123. > os.mkdir(TESTFN) > src = os.path.join(TESTFN, 'cheese') > dst = os.path.join(TESTFN, 'shop') > try: > - f = open(src, 'w') > - f.write('cheddar') > - f.close() > - > - if hasattr(os, "link"): > - os.link(src, dst) > - self.assertRaises(shutil.Error, shutil.copyfile, src, dst) > - with open(src, 'r') as f: > - self.assertEqual(f.read(), 'cheddar') > - os.remove(dst) > + with open(src, 'w') as f: > + f.write('cheddar') > + os.link(src, dst) > + self.assertRaises(shutil.Error, shutil.copyfile, src, dst) > + with open(src, 'r') as f: > + self.assertEqual(f.read(), 'cheddar') > + os.remove(dst) > + finally: > + shutil.rmtree(TESTFN, ignore_errors=True) > > + @support.skip_unless_symlink > + def test_dont_copy_file_onto_symlink_to_itself(self): > + # bug 851123. > + os.mkdir(TESTFN) > + src = os.path.join(TESTFN, 'cheese') > + dst = os.path.join(TESTFN, 'shop') > + try: > + with open(src, 'w') as f: > + f.write('cheddar') > # Using `src` here would mean we end up with a symlink pointing > # to TESTFN/TESTFN/cheese, while it should point at > # TESTFN/cheese. > @@ -298,10 +306,7 @@ > self.assertEqual(f.read(), 'cheddar') > os.remove(dst) > finally: > - try: > - shutil.rmtree(TESTFN) > - except OSError: > - pass > + shutil.rmtree(TESTFN, ignore_errors=True) > > @support.skip_unless_symlink > def test_rmtree_on_symlink(self): You might be working on something slightly different, but I have an issue created for the failure of that test: http://bugs.python.org/issue10540 It slipped past me because I was only running the test suite as a regular user without the required symlink privilege, so the test was skipped. That Server 2008 build slave runs the test suite as administrator, so it was running that test and going into the os.link block, which it didn't do until r86733.

2 5

AIX 5.3 - Enabling Shared Library Support Vs Extensions
by Anurag Chourasia 02 Dec '10

02 Dec '10

All, When I configure python to enable shared libraries, none of the extensions are getting built during the make step due to this error. building 'cStringIO' extension gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/u01/home/apli/wm/GDD/Python-2.6.6/./Include -I. -IInclude -I./Include -I/opt/freeware/include -I/opt/freeware/include/readline -I/opt/freeware/include/ncurses -I/usr/local/include -I/u01/home/apli/wm/GDD/Python-2.6.6/Include -I/u01/home/apli/wm/GDD/Python-2.6.6 -c /u01/home/apli/wm/GDD/Python-2.6.6/Modules/cStringIO.c -o build/temp.aix-5.3-2.6/u01/home/apli/wm/GDD/Python-2.6.6/Modules/cStringIO.o ./Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp build/temp.aix-5.3-2.6/u01/home/apli/wm/GDD/Python-2.6.6/Modules/cStringIO.o -L/usr/local/lib *-lpython2.6* -o build/lib.aix-5.3-2.6/cStringIO.so *collect2: library libpython2.6 not found* building 'cPickle' extension gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/u01/home/apli/wm/GDD/Python-2.6.6/./Include -I. -IInclude -I./Include -I/opt/freeware/include -I/opt/freeware/include/readline -I/opt/freeware/include/ncurses -I/usr/local/include -I/u01/home/apli/wm/GDD/Python-2.6.6/Include -I/u01/home/apli/wm/GDD/Python-2.6.6 -c /u01/home/apli/wm/GDD/Python-2.6.6/Modules/cPickle.c -o build/temp.aix-5.3-2.6/u01/home/apli/wm/GDD/Python-2.6.6/Modules/cPickle.o ./Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp build/temp.aix-5.3-2.6/u01/home/apli/wm/GDD/Python-2.6.6/Modules/cPickle.o -L/usr/local/lib *-lpython2.6* -o build/lib.aix-5.3-2.6/cPickle.so *collect2: library libpython2.6 not found* This is on AIX 5.3, GCC 4.2, Python 2.6.6 I can confirm that there is a libpython2.6.a file in the top level directory from where I am doing the configure/make etc Here are the options supplied to the configure command ./configure --enable-shared --disable-ipv6 --with-gcc=gcc CPPFLAGS="-I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses" Please guide me in getting past this error. Thanks for your help on this. Regards, Anurag

2 2

[Preview] Comments and change proposals on documentation
by Georg Brandl 01 Dec '10

01 Dec '10

Hi, at <http://dpo.gbrandl.de/contents>, you can look at a version of the 3.2 docs that has the upcoming commenting feature. JavaScript is mandatory. I've switched on anonymous comments for testing, but usually at least comments from anonymous users can be moderated. Be sure to test the "propose a change" feature too. Login currently allows OpenID exclusively. Credits go to Jacob Mason, whose GSOC project is responsible for almost all of what you see there. [1] Please test on a smaller page, such as <http://dpo.gbrandl.de/library/math>, there is currently a speed issue with larger pages. (Helpful tips from JS experts are welcome.) Other things I have to do before this can go live: * reuse existing logins from either wiki or tracker? * (re)Captcha integration for anonymous comments * easier moderation (currently emails are sent on new comments) * facility for (semi)automatic applying of proposals (once Hg is live, this should be easy to do due to the separation between commit and merge) * allow commenting on code blocks (figure out where to place the "bubble") Any feedback is appreciated (I'd suggest mailing it to doc-SIG only, to avoid cluttering up python-dev). Have fun, Georg [1] The source for the webapp is at <http://bitbucket.org/jacobmason/sphinx-demo-webapp>, but most of the functionality is implemented in Sphinx trunk.

7 9

python3k : imp.find_module raises SyntaxError
by Emile Anclin 01 Dec '10

01 Dec '10

hello, working on Pylint, we have a lot of voluntary corrupted files to test Pylint behavior; for instance $ cat /home/emile/var/pylint/test/input/func_unknown_encoding.py # -*- coding: IBO-8859-1 -*- """ check correct unknown encoding declaration """ __revision__ = 'éééé' and we try to find that module : find_module('func_unknown_encoding', None). But python3 raises SyntaxError in that case ; it didn't raise SyntaxError on python2 nor does so on our func_nonascii_noencoding and func_wrong_encoding modules (with obvious names) Python 3.2a2 (r32a2:84522, Sep 14 2010, 15:22:36) [GCC 4.3.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from imp import find_module >>> find_module('func_unknown_encoding', None) Traceback (most recent call last): File "<stdin>", line 1, in <module> SyntaxError: encoding problem: with BOM >>> find_module('func_wrong_encoding', None) (<_io.TextIOWrapper name=5 encoding='utf-8'>, 'func_wrong_encoding.py', ('.py', 'U', 1)) >>> find_module('func_nonascii_noencoding', None) (<_io.TextIOWrapper name=6 encoding='utf-8'>, 'func_nonascii_noencoding.py', ('.py', 'U', 1)) So what is the reason of this selective behavior? Furthermore, there is BOM in our func_unknown_encoding.py module. -- Emile Anclin <emile.anclin(a)logilab.fr> http://www.logilab.fr/ http://www.logilab.org/ Informatique scientifique & et gestion de connaissances

6 15

PEP 291 versus Python 3
by Éric Araujo 30 Nov '10

30 Nov '10

Good morning python-dev, PEP 291 (Backward Compatibility for Standard Library) does not seem to take Python 3 into account. Is this PEP only relevant for the 2.7 branch?* If it’s supposed to apply to 3.x too, despite the view that 3.0 was a clean break, what does it mean to have a module that is developed in the py3k branch and should retain compatibility with 2.3 or 1.5.2? * Tarek’s interpretation: “The 2.x needs to stay 2.3 compatible so we should keep the 3.x as similar as possible for bugfixes.” In the particular case of distutils (should be compatible with 2.3), we (including I) have been lax. Our tests for example use modern unittest features like skips, which makes them not runnable on old Pythons. I am very uncomfortable with code that seems to run fine but which tests (however few) cannot be run, so I think I’ll have to trade the skips for old-style “return” statements. The other way of solving that is to change the compat policy. If I remember correctly, the rationale for code compat in distutils is that people may copy distutils from Python x.y to their install of x.y-n; I don’t know if this is still an active practice, and if it is, I don’t know if it should be supported, considering that distutils2 (compatible with 2.4+ and available from PyPI) is coming. Regards

5 5

Re: [Python-Dev] [Python-checkins] r86633 - in python/branches/py3k: Doc/library/inspect.rst Doc/whatsnew/3.2.rst Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS
by Éric Araujo 29 Nov '10

29 Nov '10

> Author: nick.coghlan > New Revision: 86633 > > Issue #10220: Add inspect.getgeneratorstate(). Initial patch by Rodolpho Eckhardt > > Modified: python/branches/py3k/Doc/library/inspect.rst > ============================================================================== > --- python/branches/py3k/Doc/library/inspect.rst (original) > +++ python/branches/py3k/Doc/library/inspect.rst Sun Nov 21 04:44:04 2010 > @@ -620,3 +620,25 @@ > # in which case the descriptor itself will > # have to do > pass > + > +Current State of a Generator > +---------------------------- > + > +When implementing coroutine schedulers and for other advanced uses of > +generators, it is useful to determine whether a generator is currently > +executing, is waiting to start or resume or execution, or has already > +terminated. func:`getgeneratorstate` allows the current state of a > +generator to be determined easily. > + > +.. function:: getgeneratorstate(generator) > + > + Get current state of a generator-iterator. > + > + Possible states are: > + GEN_CREATED: Waiting to start execution. > + GEN_RUNNING: Currently being executed by the interpreter. > + GEN_SUSPENDED: Currently suspended at a yield expression. > + GEN_CLOSED: Execution has completed. I wonder if those shouldn’t be marked up as :data: or something to make them indexed.

25 95

PEP 384 final review
by "Martin v. Löwis" 29 Nov '10

29 Nov '10

I have now completed http://www.python.org/dev/peps/pep-0384/ Benjamin has volunteered to rule on this PEP. Please comment with any changes you want to see, or speak in favor or against this PEP. Regards, Martin

9 18

Virus on python-3.1.2.msi?
by "Martin v. Löwis" 28 Nov '10

28 Nov '10

Issue 1050 claims that the 3.1.2 installer has the virus Palevo.DZ. Can somebody with a virus scanner please confirm or contest that claim? Thanks, Martin http://bugs.python.org/issue10500

1 0

[RELEASED] Python 3.1.3
by Benjamin Peterson 27 Nov '10

27 Nov '10

On behalf of the Python development team, I'm happy as a lark to announce the third bugfix release for the Python 3.1 series, Python 3.1.3. This bug fix release features numerous bug fixes and documentation improvements over 3.1.2. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. This is a production release. To download Python 3.1.3 visit: http://www.python.org/download/releases/3.1.3/ A list of changes in 3.1.3 can be found here: http://svn.python.org/projects/python/tags/r313/Misc/NEWS The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 3.1.3's contributors)

1 0