Mailman 3 March 2003 - Python-Dev

csv package ready for prime-time?
by Skip Montanaro March 19, 2003

March 19, 2003

I'm ready to move the csv package out of the sandbox into the main CVS trunk. Since my last post there have been a few changes and comments: * Cliff Wells contributed his csv file parameter sniffing code * The installation is now a package instead of a single module (not sure if the docs have caught up with this change yet) * On the mailing list, the following threads of significance are found: - John Machin pointed out a few bugs and raised issues with my decision to ignore blank lines in my DictReader class. I don't believe we ever reached a concensus we were both happy with. (That is, John may still be slightly unhappy with the current results. I didn't change the behavior as a result of the thread.) - Andrew Dalke reported some problems using a space character as the delimiter which appear to be resolved. Is there a formal process for "dusting off" software which has been playing in the sandbox? What about getting PEP 305 stamped with the BDFL seal of approval? (I realize Guido's busy in the run-up to PyCon.) As a gentle reminder, the relevant URLs are http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbo… http://www.python.org/peps/pep-0305.html You can browse the mailing list archives at http://manatee.mojam.com/pipermail/csv You can check out the code and play with it fairly easily. From your sandbox directory execute cvs up -dP . cd csv python setup.py install Feedback to the csv mailing list please (Reply-To: adjusted accordingly). Skip

2 1

RE: [Python-Dev] python-dev Summary for 2003-03-01 through 2003-03-15
by Delaney, Timothy C (Timothy) March 19, 2003

March 19, 2003

> From: Christian Tismer [mailto:tismer@tismer.com] > > > > This is all going into the current summary. Wasn't > expecting this to > > generate new content, though. =) > > Hee hee, be aware of infinite recursion :-) I wouldn't expect it to be that much of a problem. Each time through seems to take a lot of time, so there are plenty of opportunities to break out of the infinite recursion before the net fills up ... Tim Delaney

1 0

Capabilities
by Aahz March 18, 2003

March 18, 2003

On Tue, Mar 18, 2003, Zooko wrote: > > No -- capabilities (as envisioned for Python) are references. Whether > a reference to an object, to a bound method, or to a function doesn't > matter. > > Note that it isn't that capabilities are "like" references, it is > that capabilities *are* references. Every reference is a capability. > Every capability is a reference. <blink> Are you saying that an int is a capability? -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ Register for PyCon now! http://www.python.org/pycon/reg.html

2 1

Re: [Python-Dev] python-dev Summary for 2003-03-01 through 2003-03-15
by Zooko March 18, 2003

March 18, 2003

(I, Zooko, wrote the lines prepended with "> > ".) Ben Laurie <ben(a)algroup.co.uk> wrote: > > > No -- capabilities (as envisioned for Python) are references. Whether a > > reference to an object, to a bound method, or to a function doesn't matter. > > I should note that this is a new (and good) idea, not one that we've > previously expressed. And, of course, they are references with > restrictions, which will be spelt out in the PEP. Yes. It isn't that Brett missed something and I corrected him, it's that I just asserted an idea that hasn't previously been posted to the list. Is the python-dev summary allowed to describe ideas posted in discussion of the python-dev summary? ;-) Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links

3 2

Shortcut bugfix
by Raymond Hettinger March 18, 2003

March 18, 2003

There is an SF report that Pmw gets TypeErrors under Py2.3 but not under previous versions of Python: www.python.org/sf/697591 There are three parts to the story: 1. a method in _tkinter.c was changed (probably appropriately) to occassionally return ints in addition to strings. 2. Pmw used string.atoi() to coerce the result to an int. This should probably be changed, but I don't want existing Pmw to suddenly fail under 2.3. 3. String.atoi(s) works by calling int(s,10). It is the ten part that makes int() raise a TypeError. The long way to fix this bug is to 1) have Neal or MvL research the propriety of the changes to _tkinter and possibly find that they needed to be done and have to be left alone and 2) have the Pmw folks update their code to not use string.atoi(s) when s is not a string (seems like a bug, but s used to always be a string when they wrote the code). Step 2 doesn't help existing users of Pmw unless they get a bugfix release. The shortcut is to fix something that isn't broken and have string.atoi stop automatically appending the ten to the int() call. Current string.atoi: def atoi(s, base=10): return _int(s, base) Proposed string.atoi: def atoi(s, *args): return _int(s, *args) The shortcut has some appeal because it lets the improvements to _tkinter stay in place and allows existing Pmw installations to continue to operate. Otherwise, one of the two has to change. Does anyone think changin string.atoi is the wrong way to go? Raymond Hettinger

5 7

Re: [Python-Dev] capability-mediated modules
by Zooko March 18, 2003

March 18, 2003

"Phillip J. Eby" <pje(a)telecommunity.com> wrote: > > There's a *much* simpler way to do this. 'import' is implemented by > calling an '__import__' function -- which of course is a capability. To do > mediated imports, it's only necessary to supply a mediating version of > '__import__'. One also needs a specialized version of '__import__' to set > up a newly imported module's builtins. I'm aware of this feature, but I was groping for a more elegant (and more capability-flavored) way to do it. As far as I can tell, the technique you describe is the "policy mini-language" way to implement access control. If I want a certain chunk of code to have access to a certain module, I set the policy with an overridable handler or a configuration object, specifying that this code is allowed to have access to this module, and then I invoke the code. This is analogous to "restricted Python v2"'s way of controlling access to certain resources in this e-mail message [1]. If I change my mind about how the code should work, I have to make changes in two places: first the part of the code that says "import spam" has to change to say "import eggs", and second the policy configuration has to change from "suchandsuch is allowed to import spam" to "suchandsuch is allowed to import eggs". In a pure capability language like E, whenever a module is imported it comes into life without permission to do anything, and then the importer grants it permission to do whatever it needs to do (by passing references). This is more like "restricted Python v3" in that designating which module the code ought to use, and authorizing the code to use that module, are both done in the same act (by passing a reference to the module in question). There is a description with examples in the "E in a Walnut" book [2]. Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links [1] http://mail.python.org/pipermail/python-dev/2003-March/033938.html [2] http://www.skyhunter.com/marcs/ewalnut.html#SEC16

1 0

Re: [Python-Dev] capability-mediated modules
by Phillip J. Eby March 18, 2003

March 18, 2003

Zooko wrote: >Just to help me think about it I'll suggest a non-Pythonic and incompatible way: >there is no "import" keyword. When you invoke a constructor, function, method, >etc., you have to pass as arguments references to everything that the code will >need to do its job. So, assuming the tic-tac-toe game requires the "math" >module and the "string" module, I would have to write: There's a *much* simpler way to do this. 'import' is implemented by calling an '__import__' function -- which of course is a capability. To do mediated imports, it's only necessary to supply a mediating version of '__import__'. One also needs a specialized version of '__import__' to set up a newly imported module's builtins.

1 0

Re: Capabilities
by Zooko March 18, 2003

March 18, 2003

(I, Zooko, wrote the lines prepended with "> > ".) Aahz <aahz(a)pythoncraft.com> wrote: > > > No -- capabilities (as envisioned for Python) are references. Whether > > a reference to an object, to a bound method, or to a function doesn't > > matter. > > > > Note that it isn't that capabilities are "like" references, it is > > that capabilities *are* references. Every reference is a capability. > > Every capability is a reference. > > <blink> Are you saying that an int is a capability? Do you mean: references are really just memory addresses? Python has pointer- safety so Python code cannot access a Python object without a reference to it, even if it knows that object's memory address. This is the first requirement listed in this message: [1]. Or do you mean: I could have a reference to some fundamental computational concept like an int -- would that reference be a capability? I would say yes, all references, even to some basic programming language constructs like None or True, are capabilities. Things like None, True, integers, etc., need to be available to all code (just so that we don't have to pass the same bundle of dozens of standard references to every object we create). Fortunately they can also be made safe so that it is okay for untrusted code to access them. Unfortunately the current implementations of things like None are not safe [2]. This is part of the third requirement listed in [1]. Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links [1] http://mail.python.org/pipermail/python-dev/2003-March/033891.html [2] http://mail.python.org/pipermail/python-dev/2003-March/033945.html

1 0

Re: [Python-Dev] capability-mediated modules
by Zooko March 18, 2003

March 18, 2003

(I, Zooko, wrote the lines prepended with "> > ".) Aahz <aahz(a)pythoncraft.com> wrote: > > > For example, suppose you want to control the ability to listen on > > sockets for network traffic. If there is a reference (e.g., to an > > object) that represents the privilege of listening on sockets, then > > you can give such a reference to one object, allowing that object it > > to listen on sockets, while withholding it from another object, thus > > preventing that one from listening on sockets. > > Doesn't that only work if the second object never gains a reference to > the first object? This is why real mandatory private data is needed. The second object could have a reference to the first object, and could use the first object through some interface offered by the first object, without being able to access the first object's socket-listener capability. Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links

1 0

Re: [Python-Dev] capability-mediated modules
by Aahz March 18, 2003

March 18, 2003

On Tue, Mar 18, 2003, Zooko wrote: > > For example, suppose you want to control the ability to listen on > sockets for network traffic. If there is a reference (e.g., to an > object) that represents the privilege of listening on sockets, then > you can give such a reference to one object, allowing that object it > to listen on sockets, while withholding it from another object, thus > preventing that one from listening on sockets. Doesn't that only work if the second object never gains a reference to the first object? -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ Register for PyCon now! http://www.python.org/pycon/reg.html

1 0