ex.php?func=detail&aid=1316653&group_id=5470&atid=305470
[1] We need to remove any backdoor methods of getting to mutable
objects outside of your sandbox, which gets us most of the way towards
a restricted execution environment.
--
Adam Olsen, aka Rhamphoryncus
__
On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:12 PM 10/7/2005 -0600, Adam Olsen wrote:
> >Okay, basic principal first. You start with a sandboxed thread that
> >has access to nothing. No modules, no builtins, *nothing*. This
> >means it can run with
On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:17 PM 10/7/2005 -0600, Adam Olsen wrote:
> >On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > Note that implementing a root-based GC for Python is non-trivial, since
> > > extension
On 10/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Adam Olsen <[EMAIL PROTECTED]> wrote:
> > I need to stress that *only* the new, immutable and "thread-safe
> > mark-and-sweep" types would be affected by these changes. Everything
> > else wou
27;s
enough.
Anyway, the idea as I presented it is dead at this point, so I'll
leave it at that.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
orge.net/tracker/index.php?func=detail&aid=1334979&group_id=5470&atid=305470
That patch removes the division from the loop (and fixes the bugs),
but gives only a small increase in speed.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing li
On 10/22/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim]
> >> I assume it's the overflow-checking that's the major time sink,
>
> [Adam Olsen]
> > Are you sure?
>
> No -- that's what "assume" means <0.7 wink>. For example, t
prefer
freezing inplace. Not much overlap with PEP 351 really.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
missing something here.
Presumably because they CAN still be raised; attempting to do so
provokes a warning, not an error.
It also facilitates upgrading from old versions of Python. You can
work to eliminate cases where the exceptions are raised while still
handling them if they do get rais
ases program legibility.
Hear, hear! Not all the world uses english, and restricting them to
latin characters simply means it's not readable in any language. It
doesn't make it any more readable for those of us who only understand
english.
+1 on internationalized identi
ve. Kills two birds with one stone.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
#x27;m accessing __dict__ directly so as to avoid getattr's
requirement for attribute names to be strings.
Obviously it doesn't handle backwards compatibility, so it's more of a
"if I could do it again.." suggestion.
--
Adam Olsen, aka Rhamphoryncus
Class(object):
def foo(self):
return object.__getattribute__(self, '__dict__')[(ObjClass,
'__private')]
Hopefully that example does not get bogged down in poor pseudocode.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailin
you said """Obviously it
> doesn't handle backwards compatibility, so it's more of a "if I could
> do it again.." suggestion."""
I was referring to code which already hardcodes the format of the
current approach, i.e.:
class Foo(object):
def _
5, Decimal("3"), 3, Decimal("4"), 5]
[2.0, Decimal("3"), 3, 3.5, Decimal("4"), 5]
[2.0, 3.5, Decimal("3"), 3, Decimal("4"), 5]
[2.0, 3, 3.5, Decimal("3"), Decimal("4"), 5]
(The positions of 3 and Decimal("3")
-accuracy argument to prevent it (just a
difficulty of implementation one.)
If the comparison is to fail I would prefer an exception rather than
an id-based fallback though.
Speaking of id, there's no reason why "id(a) == id(b)" has to fail for
mismatched types in the face of per
On 12/28/05, Noam Raphael <[EMAIL PROTECTED]> wrote:
> On 12/28/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Speaking of id, there's no reason why "id(a) == id(b)" has to fail for
> > mismatched types in the face of persistence so long as the result of
&g
e
gap or "length" is non-zero), the latter would let you pick rounding
behavior when you know enough math to back it up.
And rather than leave you all hanging I'll say that I believe it could
be done by using LLVM (circumventing C entierly.)
http://rhamph
r(obj, **kwargs):
return obj.__str__(**kwargs)
class Color:
msg = {'en':['red', 'green', 'blue'], 'de':['rot','grĂ¼n','blau']}
def __str__(self, language='en'):
return self.msg[language][sel
number types are expected to
use intervals in the face of inexactness (and those who don't behave
as expected would have unexpected results.)
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
it.
I'd rather wait until byte is fully defined, implemented, and released
in a python version before that option is taken away.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > In-favour-of-%2b-ly y'rs,
> >
> > My only opposition to this is that the byte type may want to use it.
> > I'd rather wait until byt
On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Jan 17, 2006, at 3:38 PM, Adam Olsen wrote:
>
> > I dream of a day when str(3.25, base=2) == '11.01'. That is the
> > number a float really represents. It would be so much easier to
> > underst
On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Jan 17, 2006, at 4:09 PM, Adam Olsen wrote:
>
> > On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> >>>> In-favour-
cific format.)
I'm -0 on subclassing str in the shortterm and -1 on it in the
longterm. It's cruft and not something we want to be stuck with.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
d I seem to recall an old assembler (a z80
> assembler, IIRC :P) that used a syntax like 10h and 11b for hex an bin
> radix.
ffr16 #16rff or 255
Iamadeadparrotr36 # 36rIamadeadparrot or 3120788520272999375597
Suffix syntax for bases higher than 10 is ambiguous with variable
names. Prefix
is more of a historical artifact than a
consious decision. We may not be willing to trade off functionality
for performance, but once we've already made the tradeoff we're
reluctant to go back. So it seems the challenge is this: can anybody
patch long to have performance suffici
aise exceptions from inexact results (after a
suitable warning period and with a trunc() function added to math.)
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
e it's usually lossy.
- Decimal to int. Truncates, quite happily losing precision..
I guess my confusion revolves around float to Decimal. Is lossless
conversion a good thing in python, or is prohibiting float to Decimal
conversion just a fudge to prevent people from initializing a Decima
parantly it's already been applied to Python 2.5:
http://www.python.org/dev/doc/devel/whatsnew/node4.html
Now that may not be the exact syntax that Twisted provides, but the
point is that the layout (and the top-to-bottom execution order) is
possible.
--
Adam Olsen, aka Rhamphoryncus
201 - 230 of 230 matches
Mail list logo