Mailman 3 August 2002 - Python-Dev

Re: [Python-Dev] [development doc updates]
by Jack Jansen Aug. 26, 2002

Aug. 26, 2002

On vrijdag, augustus 23, 2002, at 07:24 , Fred L. Drake wrote: > The development version of the documentation has been updated: > > http://www.python.org/dev/doc/devel/ > > Add documentation for the new "sets" module (thanks, Raymond!). > Various minor additions and clarifications. Fred, how much work would it be to make at least the html tarfile available too under www.python.org/doc/2.3? I'm looking at making the documentation friendly to the Mac help viewer (actually, Bill Fancher donated the code), and it would help the build process is there was a fixed URL based on the version number where I could always find the latest docs for the current version. -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

2 2

Why no math.fac?
by Gerhard Häring Aug. 26, 2002

Aug. 26, 2002

Any reason why there isn't any factorial function in the math module? I could easily implement one in C (for ints and longs only, right?) Gerhard -- This sig powered by Python! Außentemperatur in München: 22.3 °C Wind: 1.2 m/s

5 4

Questions about sets.py
by Tim Peters Aug. 26, 2002

Aug. 26, 2002

1. BaseSet contains 3 blobs like this: def __or__(self, other): """Return the union of two sets as a new set. (I.e. all elements that are in either set.) """ if not isinstance(other, BaseSet): return NotImplemented result = self.__class__(self._data) result._data.update(other._data) return result def union(self, other): """Return the union of two sets as a new set. (I.e. all elements that are in either set.) """ return self | other Is there a good reason not to write the latter as just union = __or__ ? 2. Is there a particular reason for not coding issuperset as def issuperset(self, other): """Report whether this set contains another set.""" self._binary_sanity_check(other) return other.issubset(self) ? Given that issubset exists, issuperset is of marginal value anyway. 3. BaseSet._update is a darned cute example of exploiting that the iterator returned by iter() isn't restartable!. That isn't a question, it's just a giggle <wink>. 4. Who believes that the __le__, __lt__, __ge__, and __gt__ methods are a good idea? If anything, I'd expect s <= t to mean "is subset", and "s < t" to mean "is proper subset". Getting the lexicographic ordering of the underlying dicts instead doesn't seem to be of any use, except perhaps to prevent sorting lists of sets from blowing up. Fine by me if that blows up, though. 5. It's curious enough that we avoid dict.copy() in def copy(self): """Return a shallow copy of a set.""" result = self.__class__([]) result._data.update(self._data) return result that if there's a reason to avoid it a comment would help. 6. It seems that doing self.__class__([]) in various places instead of self.__class__() wastes time without reason (it builds a unique empty list each time, the __init__ function then does a useless iteration dance over that, and finally the list object is torn apart again). If the intent is to communicate that we're creating an empty set, IMO the latter spelling is even a bit clearer about that (I see "[]" and keep wondering what it's trying to accomplish). 7. union_update, intersection_update, symmetric_difference_update, and difference_update return self despite mutating in-place. That makes them unique among mutating container methods (e.g., list.append, list.insert, list.remove, dict.update, list.sort, ..., return None). Is the inconsistency worth it? Chaining mutating set operations isn't common, and with names like "symmetric_difference_update()" it's a challenge to fit more than one on a line anyway <wink>. If it's thought that chaining mutating operations is somehow a good idea for sets when it's not for other containers, then we really have to be consistent about it in the sets module. For example, then Set.add() should return self too; indeed, set.add(elt1).add(elt2) may even be pleasant at times. Or if the point was merely to create "nice names" for __ior__ etc, then, e.g., the existing union_update should be renamed to __ior__, and union_update defined as def union_update(self, other): """yadda""" self |= other and let it return None. In a sense this is the opposite of question #1, where the extra code block *is* supplied but without an apparent need. 8. If there's something still valuable in _test(), I think it ought to be moved into test_sets.py. "Self-testing modules" can be convenient when developing, but after modules are deployed in the std library the embedded tests are never run again (with the exception of module doctests, which can easily be run via a regrtest-flavor test_xyz test, and which are so invoked).

3 3

Re: [Python-Dev] type categories
by Oren Tirosh Aug. 25, 2002

Aug. 25, 2002

On Sat, Aug 24, 2002 at 05:37:36PM +0200, Alex Martelli wrote: > On Saturday 24 August 2002 05:15 pm, Jeremy Hylton wrote: > > Good point, Oren. We now have two requirements for interfaces that > > are different than the standard inheritance mechanism. It should be > > possible to: > > > > - inherit from a class without implementing that class's interfaces > > > > - declare that a class implements an interface outside the class > > statement > > > > It's harder to support the second requirement using the current > > inheritance mechanism. > > The second requirement is a good part of what adaptation is meant > to do. I am not talking about situations where the object does not meet your expectations and needs to be adapted - I'm talking about situations where it actually does and the only problem is how to describe that fact properly. Adaptation is cool, but I don't see it as a replacement for anything that interfaces are supposed to achieve. Effective adaptation requires some kind of interface definition mechanism to work on top of. Oren

3 4

Weekly Python Bug/Patch Summary
by Skip Montanaro Aug. 25, 2002

Aug. 25, 2002

Bug/Patch Summary ----------------- 273 open / 2793 total bugs (+4) 109 open / 1663 total patches (+3) New Bugs -------- Empty genindex.html pages (2002-07-26) http://python.org/sf/586926 import cycle in distutils (2002-08-19) http://python.org/sf/597604 spawn*() doesn't handle errors well (2002-08-20) http://python.org/sf/597795 exec*() doesn't handle errors well (2002-08-20) http://python.org/sf/597797 compiler package and SET_LINENO (2002-08-20) http://python.org/sf/597919 Core dump when using mmap. (2002-08-20) http://python.org/sf/597938 import _tkinter python dumps core. (2002-08-21) http://python.org/sf/598160 The KeyError message doesn't use repr on the key value reported (2002-08-21) http://python.org/sf/598451 HTTPConnection memory leak (2002-08-22) http://python.org/sf/598797 Python not handling cText (2002-08-22) http://python.org/sf/598981 execfile() not show filename when IOErro (2002-08-23) http://python.org/sf/599163 ext module generation problem (2002-08-23) http://python.org/sf/599248 re searches don't work with 4-byte unico (2002-08-23) http://python.org/sf/599377 Method resolution order in Py 2.2 - 2.3 (2002-08-23) http://python.org/sf/599452 CRAM-MD5 module (2002-08-24) http://python.org/sf/599679 SocketServer wrong about allow_reuse_add (2002-08-24) http://python.org/sf/599681 sub[n] not working as expected. (2002-08-24) http://python.org/sf/599757 httplib.connect broken in 2.1 branch (2002-08-25) http://python.org/sf/599838 NameError value is not the name error (2002-08-25) http://python.org/sf/599869 New Patches ----------- Pure Python strptime() (PEP 42) (2001-10-23) http://python.org/sf/474274 "simplification" to ceval.c (2002-08-19) http://python.org/sf/597221 Oren Tirosh's fastnames patch (2002-08-20) http://python.org/sf/597907 textwrap.dedent, inspect.getdoc-ish (2002-08-21) http://python.org/sf/598163 Failure building the documentation (2002-08-22) http://python.org/sf/598996 PEP 269 Implementation (2002-08-23) http://python.org/sf/599331 Bugfix for urllib2.py (2002-08-25) http://python.org/sf/599836 Closed Bugs ----------- Summary: "BuildApplet can destory the source file on Mac OS X" (2002-01-18) http://python.org/sf/505562 ** in doc/current/lib/operator-map.html (2002-07-04) http://python.org/sf/577513 bug in splituser(host) in urllib (2002-07-14) http://python.org/sf/581529 imaplib: prefix-quoted strings (2002-07-30) http://python.org/sf/588711 add main to py_pycompile (2002-07-30) http://python.org/sf/588768 Mixin broken for new-style classes (2002-08-05) http://python.org/sf/591135 comments taken as values in ConfigParser (2002-08-08) http://python.org/sf/592527 string method bugs w/ 8bit, unicode args (2002-08-14) http://python.org/sf/595350 pythonw has a console on Win98 (2002-08-15) http://python.org/sf/595537 IDLE/Command Line Output Differ (2002-08-15) http://python.org/sf/595791 pickle_complex in copy_reg.py (2002-08-15) http://python.org/sf/595837 popenN return only text mode pipes (2002-08-16) http://python.org/sf/595919 textwrap has problems wrapping hyphens (2002-08-17) http://python.org/sf/596434 Closed Patches -------------- Alternative implementation of interning (2002-07-01) http://python.org/sf/576101 new version of Set class (2002-07-13) http://python.org/sf/580995 Update environ for CGIHTTPServer.py (2002-08-15) http://python.org/sf/595846 urllib.splituser(): '@' in usrname (2002-08-17) http://python.org/sf/596581

1 0

Fw: Security hole in rexec?
by Samuele Pedroni Aug. 24, 2002

Aug. 24, 2002

----- Original Message ----- From: Troels Therkelsen <t_therkelsen(a)hotmail.com> Newsgroups: comp.lang.python Sent: Saturday, August 24, 2002 6:42 PM Subject: Security hole in rexec? > Hello everybody, > > I have managed to stumble onto something with the rexec module that I > do not quite understand. As I understand it, the rexec framework is > meant to create a sandbox area within the Python interpreter, > technically with an instance of the rexec.RExec class. It is supposed > to be impossible to break out of this sandbox unless you do something > careless like inserting non-rexec objects into the rexec namespace. > > Let me demonstrate with some code: > > Python 2.2.1 (#1, Jun 27 2002, 10:29:04) > [GCC 2.95.3 20010315 (release)] on linux2 > Type "help", "copyright", "credits" or "license" for more > information. > >>> import rexec > >>> r = rexec.RExec() > >>> r.r_exec("import sys; print sys.stdout") > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/usr/local/lib/python2.2/rexec.py", line 254, in r_exec > exec code in m.__dict__ > File "<string>", line 1, in ? > AttributeError: 'module' object has no attribute 'stdout' > > This is as you'd expect, 'stdout' is not in the default ok_sys_names > attribute of the rexec.RExec class, so you are not supposed to be able > to see it from within the 'sandbox'. But observe: > > >>> r.r_exec("del __builtins__") > >>> r.r_exec("import sys; print sys.stdout") > <open file '<stdout>', mode 'w' at 0x80fe2a0> > > If __builtins__ is so critical to the operation of the 'sandbox' how > is it possible to break it from within the 'sandbox'? Have I stumbled > across a bug in rexec? Have I misunderstood something important? > > I've used the id() function to get the 'address' of the __builtins__ > object and I have verified that the new __builtins__ which gets > re-added has a different id so it is definitely a different > __builtins__ than the one I used del on. It would appear that exec > and family adds __builtins__ to the namespace it runs in if it doesn't > exist. But where does it get it from? Why doesn't rexec deal with > this quirk of exec? Maybe it's a new feature/bug of exec? > > I'll stop with the questions now. Suffice to say, I really need rexec > :-) > > Best regards, > > Troels Therkelsen

2 1

Re: [Python-Dev] convertibility
by David Abrahams Aug. 24, 2002

Aug. 24, 2002

From: "Alex Martelli" <aleax(a)aleax.it> > On Saturday 24 August 2002 04:00 pm, Samuele Pedroni wrote: > ... > > [yes with type categories or adapt we could do better, > > but the design prefers to minimize unexpected behaviour, > > and in practice is not too much constraining] > > As a happy user of Jython (albeit, so far, in modest amounts, > and not yet in production-code), I want to add an unsolicited > testimonial -- most of the time, the rules Jython applies "do > what feels right" and prove (to me) unsurprising and unconstraining. > > After studying the rules in detail, particularly with overload resolution in > mind, I was afraid of many possible mishaps. In practice, I find that > it seems the rules don't get in my way and don't trip me up either. > Whatever it is, there IS something right in those rules (perhaps just > in conjunction with typical Java libraries, or perhaps more generally). Hmm. When did Java acquire overload resolution? I was surprised to see it here: http://developer.java.sun.com/developer/TechTips/2000/tt0314.html I was thinking of taking advantage of these rules for Boost.Python (and Python itself), but I'm a little worried about the applicability of the final part of the rules: if any method still under consideration has parameter types that are assignable to another method that's also still in play, then the other method is removed from consideration. This process is repeated until no other method can be eliminated. If the result is a single "most specific" method, then that method is called. If there's more than one method left, the call is ambiguous. This rule is similar to the one used in C++ for partial ordering of function templates. The problem is that my convertibility criteria examine the actual objects involved in a conversion, not just their types. This allows us to overload on sequence-of-float vs. sequence-of-string, for example. Substitutability of argument types can't be tested without exemplars of those types to work with. -Dave ----------------------------------------------------------- David Abrahams * Boost Consulting dave(a)boost-consulting.com * http://www.boost-consulting.com

1 0

type categories
by Samuele Pedroni Aug. 24, 2002

Aug. 24, 2002

[Jeremy Hylton] > - inherit from a class without implementing that class's interfaces > > - declare that a class implements an interface outside the class > statement I would like to add and restate my proposal to allow also for refering to anonymous super-interfaces of an interface in terms of the interface plus a subset of its signatures, also e.g. FileLike and just 'write'. [that means an interface can be thought to correspond to a set of (tag,signature) tuples, where tag identifies the interface, and one can also just consider subsets of it] I really think that such a feature would allow interfaces to better mix and match with how currently Python code is written. Or at least ease the transition from an interfaces-less world. This may seem YAGNI, but I clearly remember people stating (on types-sig) the need to refer to an interface of just the granularity of just file-like 'read' or just __getitem__. Having to name them is overkill, having to implement all the methods of an interface corresponding to a base Python type also. It is a burden to implement and may seem complex, but I feel, it matches how we code in Python - implementing e.g. just subsets of interfaces corresponding to a base Python type - and still allowing to have interface checking precision. regards.

1 0

convertibility
by Samuele Pedroni Aug. 24, 2002

Aug. 24, 2002

FYI , in _Jython_ given the java class public class A { public void fi(int i) {} public void fd(double d) {} public void fs(String s) {} } import A a=A() one can call a.fi with a Python integer or long a.fd with a Python integer or long or float a.fs only with a Python string [yes with type categories or adapt we could do better, but the design prefers to minimize unexpected behaviour, and in practice is not too much constraining] regards.

2 1

Set naming
by Magnus Lie Hetland Aug. 24, 2002

Aug. 24, 2002

By naming the new set module sets and the class Set the parallel to array module is broken. I guess that's not a problem -- I just thought I'd mention it. Naming the module "set" would be more analogous to "array", and having "set" as an alias for "Set" would let people switch to a possible future type with the same name by commenting out their import statements... But then again, I guess my little mind is infested with hobgoblins ;) -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org

2 1