Re: [Python-Dev] Developer list update
On Thursday 07 April 2005 10:58, Raymond Hettinger wrote: > Eric Price Eric Price was an intern at CNRI; I think it's safe to remove him from the list, as I've not seen anything from him in a *long* time. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developer list update
On Apr 8, 2005 9:31 AM, Fred Drake <[EMAIL PROTECTED]> wrote: > On Thursday 07 April 2005 10:58, Raymond Hettinger wrote: > > Eric Price > > Eric Price was an intern at CNRI; I think it's safe to remove him from the > list, as I've not seen anything from him in a *long* time. Eric Price did some of the work on the decimal package, which was only two summers ago. He wasn't an intern at CNRI. Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Security capabilities in Python
I would like to experiment with security based on Python references as security capabilities. Unfortunatly, there are several problems that make Python references invalid as capabilities: * There is no way to create secure proxies because there are no private attributes. * Lots of Python objects are reachable unnecessarily breaking the principle of least privelege (i.e: object.__subclasses__() etc.) I was wondering if any such effort has already begun or if there are other considerations making Python unusable as a capability platform? (Please cc the reply to my email) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developer list update
On Friday 08 April 2005 09:53, Jeremy Hylton wrote: > Eric Price did some of the work on the decimal package, which was only > two summers ago. He wasn't an intern at CNRI. A different Eric Price, then. Mea culpa. (Or am I misremembering the intern's name? Hmm.) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security capabilities in Python
You might take a look at zope.security: http://svn.zope.org/Zope3/trunk/src/zope/security/ It isn't a capability-based system, but it does address similar problems and might have some useful ideas. See the README.txt and untrustedinterpreter.txt. Jim Eyal Lotem wrote: I would like to experiment with security based on Python references as security capabilities. Unfortunatly, there are several problems that make Python references invalid as capabilities: * There is no way to create secure proxies because there are no private attributes. * Lots of Python objects are reachable unnecessarily breaking the principle of least privelege (i.e: object.__subclasses__() etc.) I was wondering if any such effort has already begun or if there are other considerations making Python unusable as a capability platform? (Please cc the reply to my email) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Developer list update
On Thu, 2005-04-07 at 10:58, Raymond Hettinger wrote: > Ben Gertzfield Ben did a lot of work on the i18n parts of the email package. I haven't heard from him in quite a while. > Ken Manheimer Ken's still around. I'll send you his current email address in a separate (pvt) message. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developer list update
[Raymond Hettinger] > Does anyone know what has become of the following developers and perhaps > have their current email addresses? How about we exploit that if someone is a Python developer on SF, they necessarily have an SF email address ($(SFNAME)@users.sourceforge.net, like I'm [EMAIL PROTECTED])? Then, IMO, if someone with SF commit privs can't be reached via their SF address, they shouldn't have SF commit privs. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developer list update
[Jeremy] >> Eric Price did some of the work on the decimal package, which was only >> two summers ago. He wasn't an intern at CNRI. [Fred] > A different Eric Price, then. Mea culpa. > > (Or am I misremembering the intern's name? Hmm.) Yes, Eric Price was "the PythonLabs intern", for the brief time that lasted. I'll add info about him to developers.txt. He was given SF developer status specifically to work on the decimal module, which then lived in the Python sandbox. There isn't a reason for him to remain a developer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Developer list update
> [Raymond Hettinger] > > Does anyone know what has become of the following developers and perhaps > > have their current email addresses? [Tim Peters] > How about we exploit that if someone is a Python developer on SF, they > necessarily have an SF email address ($(SFNAME)@users.sourceforge.net, > like I'm [EMAIL PROTECTED])? I used those addresses and sent notes to everyone who hasn't made a recent checkin. For the most part, we've gotten lots of cheerful responses (with one notable exception) indicating a continuing use for the checkin privs. A few people no longer have a use for the access and I'm recording those as we go. > Then, IMO, if someone with SF commit privs can't be reached via their > SF address, they shouldn't have SF commit privs. I'm taking a lighter approach and making every effort to get in contact. If they respond, I'll ask them to update their SF address. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developer list update
... [Uncle "Bad Cop" Timmy] >> Then, IMO, if someone with SF commit privs can't be reached via their >> SF address, they shouldn't have SF commit privs. [Raymond "Good Cop" Hettinger] > I'm taking a lighter approach and making every effort to get in contact. > If they respond, I'll ask them to update their SF address. Of course! I would too, if I were you. But given that I'm still me, the annotated attributions above should clarify the role I'm playing here <0.9 wink>. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Security capabilities in Python
"Eyal Lotem" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I would like to experiment with security based on Python references as > security capabilities. I am pretty sure that there was a prolonged discussion on Python, security, and capability on this list a year or two ago. Perhaps you can find it in the summary archives or the archives themselves. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Developer list update
Raymond> Does anyone know what has become of ... Raymond> Charles G Waldman I'd scratch Charles from the list. I work at the same company he did. Nobody here has been in touch with him for over a year. Several of us have tried to get ahold of him but to no avail. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threading (GilState) question
> > Under "Limitations and Exclusions" it specifically disowns > > responsibility for worrying about whether Py_Initialize() and > > PyEval_InitThreads() have been called: > > > [snip quote] > > This suggests that I should call PyEval_InitThreads() in > initreadline(), which seems daft. fwiw, Modules/_bsddb.c does exactly that. -g ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Developer list update
Raymond Hettinger wrote: > I used those addresses and sent notes to everyone who hasn't made a > recent checkin. where recent obviously was defined as "after 2.4" for checkins, and "last week" for tracker activities. python-dev was a lot more fun in the old days. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] marshal / unmarshal
What should marshal / unmarshal do with floating point NaNs (the case we
are worrying about is Infinity) ? The current behavior is not perfect.
Michael Spencer chased down a supposed "Idle" problem to (on Win2k):
marshal.dumps(1e1) == 'f\x061.#INF'
marshal.loads('f\x061.#INF') == 1.0
Should loads raise an exception?
Somehow, I thing 1.0 is not the best possible representation for +Inf.
-- Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: marshal / unmarshal
Scott David Daniels wrote:
> What should marshal / unmarshal do with floating point NaNs (the case we
> are worrying about is Infinity) ? The current behavior is not perfect.
>
> Michael Spencer chased down a supposed "Idle" problem to (on Win2k):
> marshal.dumps(1e1) == 'f\x061.#INF'
> marshal.loads('f\x061.#INF') == 1.0
>
> Should loads raise an exception?
> Somehow, I thing 1.0 is not the best possible representation for +Inf.
looks like marshal uses atof to parse the string, without bothering to
check for trailing junk... it should probably use a strtod instead, and
raise an exception if there's enough junk left at the end (see PyFloat_
FromString for sample code).
fwiw, here's what I get on a linux box:
>>> import marshal
>>> marshal.dumps(1e1)
'f\x03inf'
>>> marshal.loads(_)
inf
and yes, someone should fix the NaN mess, but I guess everyone's too
busy removing unworthy developers from sourceforge to bother working
on stuff that's actually useful for real Python users...
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marshal / unmarshal
[Scott David Daniels] > What should marshal / unmarshal do with floating point NaNs (the case we > are worrying about is Infinity) ? The current behavior is not perfect. All Python behavior in the presence of a NaN, infinity, or signed zero is a platform-dependent accident. This is because C89 has no such concepts, and Python is written to the C89 standard. It's not easy to fix across all platforms (because there is no portable way to do so in standard C), although it may be reasonably easy to fix if all anyone cares about is gcc and MSVC (every platform C compiler has its own set of gimmicks for "dealing with" these things). If marshal could reliably detect a NaN, then of course unmarshal should reliably reproduce the NaN -- provided the platform on which it's unpacked supports NaNs. > Should loads raise an exception? Never for a quiet NaN, unless the platform doesn't support NaNs. It's harder to know what to with a signaling NaN, because Python doesn't have any of 754's trap-enable or exception status flags either (the new ``decimal`` module does, but none of that is integrated with the _rest_ of Python yet). Should note that what the fp literal 1e1 does across boxes is also an accident -- Python defers to the platform C libraries for string<->float conversions. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: hierarchicial named groups extension to the re library
<[EMAIL PROTECTED]> wrote: > (ie. the re library only returns the ~last~ match for named groups - not > a list of ~all~ the matches for the named groups. And the hierarchy of those named groups is non-existant in the flat dictionary of matches > that results. ) are you 100% sure that this can be implemented on top of other RE engines (CPython isn't the only Python implementation out there). (generally speaking, trying to turn an RE engine into a parser is a lousy idea. the library would benefit more from a simple parser toolkit than it benefits from more non-standard and highly specialized RE hacks...) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Developer list update
[Raymond Hettinger wrote: >> I used those addresses and sent notes to everyone who hasn't made a >> recent checkin. [Fredrik Lundh] > where recent obviously was defined as "after 2.4" for checkins, and "last > week" > for tracker activities. Raymond didn't mention tracker activity above, and that's a different issue -- it's possible now to separate commit privileges from tracker privileges on SourceForge. Like it or not (I think I can guess which), every person with commit privs implies at least one box that can become a security hole, and at least 5 people who in fact never commit anymore were agreeable to giving up SF developer privs. > python-dev was a lot more fun in the old days. Ya, but you were too -- and so was I. I expect these all go together, given that (the collective) we _are_ python-dev. So what have you been up to lately? Skip it unless the answer's fun . ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: marshal / unmarshal
"Tim Peters" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > All Python behavior in the presence of a NaN, infinity, or signed zero > is a platform-dependent accident. The particular issue here is not platform dependence as such but within-platform usage dependence, as in the same code giving radically different answers in a standard interactive console window and an idle window, or when you run it the first time (from xx.py) versus subsequent times (from xx.pyc) until you edit the file again. (I verified this on 2.2, but MSpencer claimed to have tested on 2.4). Having the value of an expression such as '100 < 1e1000' flip back and forth between True and False from run to run *is* distressing for some people ;-). I know that this has come up before as 'wont fix' bug, but it might be better to have invalid floats like 1e1000, etc, not compile and raise an exception (at least on Windows) instead of breaking the reasonable expectation that unmarshal(marshal(codeob)) == codeob. That would force people (at least on Windows) to do something more more within-platform deterministic. >If marshal could reliably detect a NaN, then of course unmarshal >should reliably reproduce the NaN -- provided the platform on which >it's unpacked supports NaNs Windows seems to support +- INF just fine, doing arithmetic and comparisons 'correctly'. So it seems that detection or reproduction is the problem. Terry J. Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: marshal / unmarshal
Terry Reedy wrote: "Tim Peters" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] All Python behavior in the presence of a NaN, infinity, or signed zero is a platform-dependent accident. The particular issue here is not platform dependence as such but within-platform usage dependence, as in the same code giving radically different answers in a standard interactive console window and an idle window, or when you run it the first time (from xx.py) versus subsequent times (from xx.pyc) until you edit the file again. (I verified this on 2.2, but MSpencer claimed to have tested on 2.4). Having the value of an expression such as '100 < 1e1000' flip back and forth between True and False from run to run *is* distressing for some people ;-). I know that this has come up before as 'wont fix' bug, but it might be better to have invalid floats like 1e1000, etc, not compile and raise an exception (at least on Windows) instead of breaking the reasonable expectation that unmarshal(marshal(codeob)) == codeob. That would force people (at least on Windows) to do something more more within-platform deterministic. If marshal could reliably detect a NaN, then of course unmarshal should reliably reproduce the NaN -- provided the platform on which it's unpacked supports NaNs Windows seems to support +- INF just fine, doing arithmetic and comparisons 'correctly'. So it seems that detection or reproduction is the problem. Terry J. Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org I can write the Windows-dependent detect code if that is what is wanted. I just want to know what the consensus is on the "should." If we cause exceptions, should they be one encode or decode or both? If not, do we replicate all NaNs, Infs of both signs, Indeterminates? --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security capabilities in Python
On Fri, 8 Apr 2005, Eyal Lotem wrote: > I would like to experiment with security based on Python references as > security capabilities. This is an interesting and worthwhile thought. Several people (including myself) have talked about the possibility of doing this in the past. I believe the two problems you mention can be addressed without modifying the Python core. > * There is no way to create secure proxies because there are no > private attributes. Attributes are not private, but local variables are. If you use lexical scoping to restrict variable access (as one would in Scheme, E, etc.) you can create secure proxies. See below. > * Lots of Python objects are reachable unnecessarily breaking the > principle of least privelege (i.e: object.__subclasses__() etc.) True. However, Python's restricted execution mode prevents access to these attributes, allowing you to enforce encapsulation. (At least, that is part of the intent of restricted execution mode, though currently we do not make official guarantees about it.) Replacing __builtins__ activates restricted execution mode. Here is a simple facet function. def facet(target, allowed_attrs): class Facet: def __repr__(self): return '' % (allowed_attrs, target) def __getattr__(self, name): if name in allowed_attrs: return getattr(target, name) raise NameError(name) return Facet() def restrict(): global __builtins__ __builtins__ = __builtins__.__dict__.copy() # Here's an example. list = [1, 2, 3] immutable_facet = facet(list, ['__getitem__', '__len__', '__iter__']) # Here's another example. class Counter: def __init__(self): self.n = 0 def increment(self): self.n += 1 def value(self): return self.n counter = Counter() readonly_facet = facet(counter, ['value']) If i've done this correctly, it should be impossible to alter the contents of the list or the counter, given only the immutable_facet or the readonly_facet, after restrict() has been called. (Try it out and let me know if you can poke holes in it...) The upshot of all this is that i think you can do secure programming in Python if you just use a different style. Unfortunately, this style is incompatible with the way classes are usually written in Python, which means you can't safely use much of the standard library, but i believe the language itself is not fatally flawed. -- ?!ng ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: marshal / unmarshal
Tim Peters wrote:
> All Python behavior in the presence of a NaN, infinity, or signed zero
> is a platform-dependent accident. This is because C89 has no such
> concepts, and Python is written to the C89 standard. It's not easy to
> fix across all platforms (because there is no portable way to do so in
> standard C), although it may be reasonably easy to fix if all anyone
> cares about is gcc and MSVC
which probably represents very close to 100% of all python interpreter
instances out there. making floats behave the same on standard builds
for windows, mac os x, and linux would be a great step forward.
+1.0 from me.
>> Should loads raise an exception?
>
> Never for a quiet NaN, unless the platform doesn't support NaNs. It's
> harder to know what to with a signaling NaN, because Python doesn't
> have any of 754's trap-enable or exception status flags either (the
> new ``decimal`` module does, but none of that is integrated with the
> _rest_ of Python yet).
>
> Should note that what the fp literal 1e1 does across boxes is also
> an accident -- Python defers to the platform C libraries for
> string<->float conversions.
yeah, but the problem here is that MSVC cannot read its own NaN:s;
float() checks for that, but loads doesn't. compare and contrast:
>>> float(str(1e1))
Traceback (most recent call last):
File "", line 1, in ?
ValueError: invalid literal for float(): 1.#INF
>>> import marshal
>>> marshal.loads(marshal.dumps(1e1))
1.0
on the other hand,
>>> marshal.loads("\f\x01x")
Traceback (most recent call last):
File "", line 1, in ?
ValueError: bad marshal data
adding basic error checking shouldn't be very hard (you could probably
call the string->float converter in the float object module, and just map any
exceptions to "bad marshal data")
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: marshal / unmarshal
Fredrik Lundh wrote: [...] and yes, someone should fix the NaN mess, but I guess everyone's too busy removing unworthy developers from sourceforge to bother working on stuff that's actually useful for real Python users... That's not at all true. Some of us are busy giving up commit privileges in order to avoid the impression that we might one day work on stuff that actually useful to real Python users. Except, possibly, conferences. The effbot is at least averagely cantankerous this month :-) unworthi-ly y'rs - steve -- Steve Holden+1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
