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 o
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 d
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
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,
"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
[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 tha
<[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 b
[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 h
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'
>
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
S
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.
__
> > 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, Mod
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
__
"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. P
...
[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 up
> [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,
[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
[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 PROTECT
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
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 w
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,
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
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 so
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.
___
Pyt
24 matches
Mail list logo
