Mailman 3 July 2006 - Python-Dev

Re: [Python-Dev] how about adding ping's uuid module to the standard lib ?
by Tim Peters 28 Jul '06

28 Jul '06

Georg discovered that test_uuid didn't run any tests, and fixed that on Thursday. A number of buildbots have failed that test since then. My XP box appears unique among the Windows buildbots in failing. It always fails like so: AssertionError: different sources disagree on node: from source 'getnode1', node was 00038a000015 from source 'getnode2', node was 00038a000015 from source 'ipconfig', node was 001111b2b7bf 0x00038a000015 /is/ the last 6 bytes returned by the Windows UuidCreateSequential() on my box. I confirmed that by writing a C program calling it directly. However, it doesn't appear to correspond to any MAC address of any HW on my box. All documented ways of determining the MAC address of my Ethernet card (using UuidCreateSequential for this appears to be folklore rather than documented behavior) agree that 0x001111b2b7bf is correct on this box; e.g., $ getmac /fo list /v Connection Name: Local Area Connection Network Adapter: Marvell Yukon 88E8050 PCI-E ASF Gigabit Ethernet Controller Physical Address: 00-11-11-B2-B7-BF Transport Name: \Device\Tcpip_... Connection Name: 1394 Connection Network Adapter: 1394 Net Adapter Physical Address: 62-A1-AC-6C-FD-BE Transport Name: \Device\Tcpip_... Connection Name: 1394 Connection 2 Network Adapter: 1394 Net Adapter Physical Address: E2-1F-01-C6-5D-88 Transport Name: \Device\Tcpip_... The last two are for firewire interfaces, and don't match the purported MAC address extracted from UuidCreateSequential's output anyway. So, at least on my box, this comment in uuid.py is incorrect (UuidCreateSequential does not behave as it says): # On Windows prior to 2000, UuidCreate gives a UUID containing the # hardware address. On Windows 2000 and later, UuidCreate makes a # random UUID and UuidCreateSequential gives a UUID containing the # hardware address. ... Unfortunately, uuid.getnode() tries things in this order on Windows: getters = [_windll_getnode, _netbios_getnode, _ipconfig_getnode] It's only the first one that returns the bogus 0x00038a000015; both of the latter return 0x001111B2B7BF. However, there's nothing I can do to that list to make test_uuid pass on this box. It wants to insist that all three ways of getting/guessing the MAC address return the same thing, and that's never going to happen here. Given that _windll_getnode's actual behavior appears to have nothing in common with what was expected for it here, best suggestion I can make is to throw its code away.

1 1

Re: [Python-Dev] Internal namespace proposal
by David Hopwood 28 Jul '06

28 Jul '06

Richard Jones wrote: > On 27/07/2006, at 12:19 PM, David Hopwood wrote: > >> A restricted interpreter refuses access to any object attribute or >> method with a name beginning with '_' (by throwing a new exception type >> 'InternalAccessException'), unless the access is from a method and its >> static target is that method's first argument variable. >> >> Also, a restricted interpreter refuses access to any module-global >> variable or module-global function with a name beginning with '_' (by >> throwing 'InternalAccessException'), unless the access is statically >> from the same module. > > Note that this is a rule that Zope enforces in its restricted environment. Is that documented anywhere? -- David Hopwood <david.nospam.hopwood(a)blueyonder.co.uk>

1 0

Internal namespace proposal
by David Hopwood 28 Jul '06

28 Jul '06

[This message is cc:d to the e-lang list, but please take any replies to python-dev(a)python.org.] Brett Cannon wrote: > On 7/19/06, Ka-Ping Yee <cap-talk(a)zesty.ca> wrote: > >> OMG!!! Is all i can say at the moment. Very excited. This is very encouraging. Thanks to ?!ng, Michael Chermside and others for making the case for capabilities. > Also realize that I am using object-capabilities to secure the interpreter, > not objects. That will be enough of a challenge to do for now. Who knows, > maybe some day Python can support object-capabilities at the object level, > but for now I am just trying to isolate and protect individual interpreters > in the same process. I think that the alternative of providing object-granularity protection domains straight away is more practical than you suggest, and I'd like to at least make sure that this possibility has been thoroughly explored. Below is a first-cut proposal for enforcing namespace restrictions, i.e. support for non-public attributes and methods, on Python objects and modules. It is not sufficient by itself to provide capability security, but it could be the basis for doing that at object granularity. (Note that this proposal would only affect sandboxed/restricted interpreters, at least for the time being. The encapsulation it provides is also useful for reasons other than security, and I think there is nothing about it that would be unreasonable to apply to an unrestricted interpreter, but for compatibility, that would have to be enabled by a __future__ option or similar.) Internal namespace proposal =========================== Existing Python code tends to use a convention where the names of attributes and methods intended only for internal use are prefixed by '_'. This convention comes from PEP 8 <http://www.python.org/dev/peps/pep-0008/>, which says: # In addition, the following special forms using leading or trailing # underscores are recognized (these can generally be combined with any case # convention): # # - _single_leading_underscore: weak "internal use" indicator. E.g. "from M # import *" does not import objects whose name starts with an underscore. # # - single_trailing_underscore_: used by convention to avoid conflicts with # Python keyword, e.g. # # Tkinter.Toplevel(master, class_='ClassName') # # - __double_leading_underscore: when naming a class attribute, invokes name # mangling (inside class FooBar, __boo becomes _FooBar__boo; see below). # # - __double_leading_and_trailing_underscore__: "magic" objects or # attributes that live in user-controlled namespaces. E.g. __init__, # __import__ or __file__. Never invent such names; only use them # as documented. I propose that the "internal" status of names beginning with _ (including those beginning with __) should be enforced in restricted interpreters. This is better than introducing a new annotation, because it will do the right thing for existing code that follows this part of PEP 8. More precisely: A restricted interpreter refuses access to any object attribute or method with a name beginning with '_' (by throwing a new exception type 'InternalAccessException'), unless the access is from a method and its static target is that method's first argument variable. Also, a restricted interpreter refuses access to any module-global variable or module-global function with a name beginning with '_' (by throwing 'InternalAccessException'), unless the access is statically from the same module. (A method's first argument is usually called 'self', but that's just a convention. By "static target", I mean that to access an internal attribute _foo in a method with first argument 'self', you must write "self._foo"; attempting to access "x._foo" will fail even if 'x' happens to be the same object as 'self'. This allows such accesses to be reported at compile-time, rather than only at run-time.) I am using the term "internal" rather than "private" or "protected", because these semantics are not the same as either "private" or "protected" in C++ or Java. In Python with this change, an object can only access its own internal methods and attributes. In C++ and Java, an object can access private and protected members of other objects of the same class. The rationale for this difference is explained below. The use of _single vs __double underscores encodes a useful distinction that would not change. Ignoring the point in the previous paragraph, a _single underscore is similar to "protected" in languages like C++ and Java, while a __double underscore is similar to "private". This is purely a consequence of the name mangling: if a class X and its subclass Y both name an attribute __foo, then we will end up with two attributes _X__foo and _Y__foo in instances of Y, which is the desired behaviour for private attributes. In the case of an attribute called _foo, OTOH, there can be only one such attribute per object, which is the desired behaviour for protected attributes. The name mangling also ensures that an object will not *accidentally* access a private attribute inherited from a superclass. However, in the same example, an instance of Y can still deliberately access the copy of the attribute inherited from X by specifying _X__foo. There is no security problem here, because Y cannot do anything as a result that it could not have done by copying X's code, rather than inheriting from it. Notice that this is only true because we restrict an object to only accessing its own internal attributes and methods; if we followed C++'s semantics where an object can access protected members of any superclass, this would break security. (Java solves this problem by applying a more complicated access rule for protected members, which I considered to be unintuitive. More details on request.) __dict__ is an internal attribute. This means that an object can only directly reflect on itself. I know that there are other means of reflection (e.g. using the 'inspect' module); blocking these or making them safe is a separate issue. If desired, it would be safe to add a 'publicdict' attribute to each object, or a 'publicdict(object)' built-in. This would return a *read-only* dict, probably created lazily if needed, giving access only to public (non-internal) attributes and methods. __init__ is an internal method. This is as it should be, because it should not be possible to call __init__ on an existing object; only to have __init__ implicitly called when a new object is constructed. __repr__ and __str__ are internal under these rules, and probably shouldn't be. Existing classes may expose private state in the strings returned by __repr__ or __str__, but in principle, there is nothing unsafe about being able to convert the public state of an object to a string. OTOH, this functionality is usually accessed via the built-ins 'repr' and 'str', which we could perhaps allow to access '__repr__' and '__str__' as a special case. -- David Hopwood <david.nospam.hopwood(a)blueyonder.co.uk>

3 7

Support for PyGetSetDefs in pydoc
by Barry Warsaw 27 Jul '06

27 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patch #1520294 adds support for attributes defined with PyGetSetDef in extension modules to pydoc, specifically so things like help (array.array.typecode) gives something useful, like the attribute's docstring for instance. Along the way, I added types.GetSetterType and inspect.isgetsetter(), along with tests and docs. Now I definitely think that the pydoc change should go into Python 2.5 and be backported to Python 2.4, but it's a bit of a question whether the types.py and inspect.py changes should go into Python 2.5 now that we're in beta. I personal think they're worthwhile changes to go it, but I won't argue too hard for them since the pydoc fixes can be implemented with local changes to pydoc.py alone. Thoughts? - -Barry https://sourceforge.net/tracker/? func=detail&atid=305470&aid=1520294&group_id=5470 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLMEYnEjvBPtnXfVAQKB8gQAmkk0V0B0xdRD/Xgko4vD0JmvFiXZL3EO bEzE9Wtn8u54JB/EXLdocjeFLjlOzlSzalLKGvxgQHyKGP0F8CSBN6mIreTsztct wl58FyPro3mkwsamUrkPzf/xSZk/4tO81oXPkuzqANbv+0WEnD5MmdSpVqz7jQIo qqbAqah2ha4= =kxSp -----END PGP SIGNATURE-----

4 9

Re: [Python-Dev] Which version of distutils to ship with Python 2.5?
by Phillip J. Eby 27 Jul '06

27 Jul '06

At 01:51 PM 7/27/2006 -0400, Collin Winter wrote: >On 7/27/06, "Martin v. Löwis" <martin(a)v.loewis.de> wrote: > > Collin Winter wrote: > > > Is it intentional that Python 2.5 is (currently) shipping with > > > distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and 2.4.3) > > > shipped with distutils 2.4.1? Judging from my own tests, distutils > > > 2.4.1 fixed several bugs that some of my test suites depend on (the > > > fixes, not the bugs ; ). > > > > Are these bugs not fixed in the distutils that shipped with Python 2.5b2? > >I now believe this to be a new regression that I had confused with an >earlier bug report. I've filed a new report, >http://python.org/sf/1529871. I'd appreciate it if anyone could shed >some light on this. As I noted on the bug itself, the problem is due to r46372, a patch introduced by the need-for-speed sprint and which broke CPython's compliance with PEP 302, by introducing non-None, non-importer values into sys.path_importer_cache. At the present time, I have not received an unequivocal response regarding how the problem should be corrected: 1. Update PEP 302 and the "What's New" documentation to reflect this backwards-incompatible change and require authors to update their code to work with Python 2.5 2. Fix the patch so it implements the speedup in a way that is conformant with PEP 302 as it currently stands (I have volunteered to do this, if the release manager(s) will authorize it) 3. Revert the patch. No one has volunteered for any of the work required for #1. I belive that #3 must be done if #2 is not approved and no volunteers surface for #1 in a timely manner.

1 0

Re: [Python-Dev] uuid test suite failing
by Matt Fleming 27 Jul '06

27 Jul '06

> On 27/07/06, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > > IIRC at least some versions of HP-UX do not support the -a flag for > > ifconfig, I'll check this tomorrow. > > > > Ronald > > td192> /usr/sbin/ifconfig usage: ifconfig interface [ af [ address [ dest_addr ] ] [ up ] [ down ][ netmask mask ] ] [ metric n ] [ arp | -arp ] [ plumb | unplumb ] td192> /usr/sbin/ifconfig -a ifconfig: no such interface td192> uname -a HP-UX td192 B.11.11 U 9000/800 1839940656 unlimited-user license Also fixed this test on my NetBSD machine by using 'ifconfig -a' and checking for 'address:' in the output. But as Ronald said, not all platforms support the '-a' flag. Not sure if this will fix the OpenBSD buildbot, I don't have access to an OpenBSD machine. Matt -- http://mattssanctuary.blogspot.com

1 0

Release manager: pdb bugfix incompatibility
by A.M. Kuchling 27 Jul '06

27 Jul '06

Bug #1526834: if you do 'b f(' in pdb, the debugger crashes. This bug stems from pdb just sticking the string in a regex and compiling it. cre = re.compile(r'def\s+%s\s*[(]' % funcname) A side effect of this is that 'b f()' works to match the function 'f', because the empty parens are legal regex syntax declaring an empty group that matches the null string. It's easy to fix the crash by doing re.escape(funcname). But this means that 'b f()' will no longer find the function 'f' -- it will look for 'f(' followed by another paren, and won't find it. Should this be fixed by the re.escape(), or should the fix attempt to keep 'b f()' working? The pdb documentation doesn't claim that 'b f()' should work. --amk

1 0

Patch for building ctypes on more OpenBSD target platforms
by Thomas Heller 27 Jul '06

27 Jul '06

I've uploaded a patch sent to me in private email by Damien Miller, who is packaging ctypes for the OpenBSD port tree. I'm requesting permission to commit this for Python 2.5. http://python.org/sf/1529514 Thanks, Thomas

1 0

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 27 Jul '06

27 Jul '06

Patch / Bug Summary ___________________ Patches : 401 open ( +3) / 3342 closed ( +8) / 3743 total (+11) Bugs : 896 open ( -8) / 6035 closed (+24) / 6931 total (+16) RFE : 224 open ( +2) / 233 closed ( +2) / 457 total ( +4) New / Reopened Patches ______________________ pkgutil.walk_packages ignores onerror arg (2006-07-20) CLOSED http://python.org/sf/1525766 opened by James Y Knight Tkdnd mouse cursor handling patch (2006-07-20) http://python.org/sf/1525806 opened by klappnase calltip awkwardly shortened (2006-07-20) CLOSED http://python.org/sf/1525817 opened by Lingl str.__iter__ and unicode.__iter__ (2006-07-21) http://python.org/sf/1526367 opened by Walter DÃ¶rwald Fix socketmodule compile on NetBSD (2006-07-21) http://python.org/sf/1526460 opened by Matt Fleming New module: miniconf (2006-07-24) http://python.org/sf/1527597 opened by S.Fourmanoit winsound - probably win9x port is not working (2006-07-24) CLOSED http://python.org/sf/1527744 opened by Hirokazu Yamamoto Expose case-insensitivity of string.Template (2006-07-25) http://python.org/sf/1528167 opened by Chad Whitacre PyShell.recall - fix indentation logic (2006-07-25) http://python.org/sf/1528468 opened by Tal Einat patch for mbcs codecs (2006-03-22) http://python.org/sf/1455898 reopened by ocean-city Patches Closed ______________ pkgutil.walk_packages ignores onerror arg (2006-07-20) http://python.org/sf/1525766 closed by gbrandl calltip awkwardly shortened (2006-07-20) http://python.org/sf/1525817 closed by loewis ParenMatch: workaround for misinterpreting of closing parens (2006-01-16) http://python.org/sf/1407280 closed by kbk Syntax-related improvements to IDLE (2004-02-28) http://python.org/sf/906702 closed by kbk (partial?) fix for Misc/python-config.in (2006-07-16) http://python.org/sf/1523356 closed by gbrandl ConnectRegistry blocks all threads (2006-03-12) http://python.org/sf/1448199 closed by loewis MS Windows - module search path fix (2005-07-04) http://python.org/sf/1232023 closed by loewis winsound - probably win9x port is not working (2006-07-24) http://python.org/sf/1527744 closed by gbrandl 1515163 fix - traceback and str exc (2006-06-30) http://python.org/sf/1515343 closed by gbrandl New / Reopened Bugs ___________________ inspect.py: still infinite recursion inspecting frames (2006-07-03) CLOSED http://python.org/sf/1516184 reopened by nnorwitz Bug in shutil.copytree on Windows (2006-07-20) http://python.org/sf/1525866 opened by Mike Foord email package quoted printable behaviour changed (2006-07-20) http://python.org/sf/1525919 opened by Thomas Arendsen Hein Win32: subprocess.Popen() w/o "pipe" throws an exception (2006-07-21) CLOSED http://python.org/sf/1526203 opened by Larry Hastings Concatenation on a long string breaks (2006-07-21) http://python.org/sf/1526585 opened by Jp Calderone current directory added to sys.path on win32 (2006-07-22) CLOSED http://python.org/sf/1526785 opened by John Ehresman unbalanced parentheses from command line crash pdb (2006-07-21) http://python.org/sf/1526834 opened by Ilya Sandler PythonLauncher uses incorrect working directory (2006-07-23) http://python.org/sf/1527397 opened by Bob Ippolito optparse should support arbitrary number of arguments (2006-07-24) http://python.org/sf/1527705 reopened by riteshsarraf optparse should support arbitrary number of arguments (2006-07-24) http://python.org/sf/1527705 opened by Ritesh Raj Sarraf tarfile chokes on ipython archive on Windows (2006-07-24) http://python.org/sf/1527974 opened by Arve Knudsen difflib.SequenceMatcher.find_longest_match() wrong result (2006-07-25) http://python.org/sf/1528074 opened by John Machin urllib2 data argument (2006-07-25) http://python.org/sf/1528258 opened by paul rubin forward in turtle module may cause incorrect display (2006-07-25) http://python.org/sf/1528363 opened by NatureMage IDLE: printing issue on OSX (2006-07-25) http://python.org/sf/1528593 opened by Ronald Oussoren Python 2.5b2 fails to build on Solaris 10 (2006-07-25) http://python.org/sf/1528620 opened by Guido Ostkamp Python 2.5b2 fails to build (GCC) on Solaris 10 (2006-07-26) http://python.org/sf/1529269 opened by Guido Ostkamp Bugs Closed ___________ inspect.py: still infinite recursion inspecting frames (2006-07-03) http://python.org/sf/1516184 closed by pje logging using the SysLog handler fails if locale is set (2006-07-17) http://python.org/sf/1524081 closed by vsajip Win32: subprocess.Popen() w/o "pipe" throws an exception (2006-07-21) http://python.org/sf/1526203 closed by gbrandl Malloc, memory error, failmalloc, low memory. (2006-07-19) http://python.org/sf/1525589 closed by nnorwitz current directory added to sys.path on win32 (2006-07-22) http://python.org/sf/1526785 closed by loewis IDLE (macosx): Class and Path browsers show Tk menu (2006-07-06) http://python.org/sf/1517996 closed by ronaldoussoren Column Number is not visible in MacOSX (2003-07-09) http://python.org/sf/768481 closed by kbk Tooltip-window doesn't vanish if... (2003-07-22) http://python.org/sf/775535 closed by kbk failure of test_ossaudiodev; elapsed time .1 sec faster (2006-06-05) http://python.org/sf/1501330 closed by gward Argument missing from calltip for new-style class init (2004-09-13) http://python.org/sf/1027566 closed by kbk length of unicode string changes print behaviour (2006-02-22) http://python.org/sf/1436532 closed by loewis exec and eval allocate lots of memory and do not free it (2006-07-20) http://python.org/sf/1525678 closed by loewis os.listdir doesn't check error code from FindNextFile (2006-07-18) http://python.org/sf/1524310 closed by loewis os.path.abspath() / os.chdir() buggy with unicode paths (2005-09-07) http://python.org/sf/1283895 closed by loewis traceback now masks some string exceptions (2006-06-30) http://python.org/sf/1515163 closed by gbrandl sys.ps1 not protected in EditorWindow.py (2004-08-16) http://python.org/sf/1010370 closed by kbk EditorWindow demo causes attr-error (2006-01-28) http://python.org/sf/1417598 closed by kbk Building 2.5a1 requires python (2006-04-06) http://python.org/sf/1465408 closed by anthonybaxter New / Reopened RFE __________________ New sequences for Unicode classes needed (2006-07-25) http://python.org/sf/1528154 opened by gmarketer RFE Closed __________ Add Windows 9x/ME (lack of) support information to README.TX (2006-06-22) http://python.org/sf/1510853 closed by loewis

1 0

patch for mbcs codec (again)
by H.Yamamoto 27 Jul '06

27 Jul '06

Hello. I noticed mbcs codec still has problem when calls StreamReader. Can anyone commit the patch "fix.patch version2" on http://python.org/sf/1455898 ? # Very sorry about this... I thought I checked this, but I definitely looked at something # wrong.

1 0

Python-Dev July 2006