Re: [Python-Dev] [Python-checkins] cpython: Fix a comment: PySequence_Fast() creates a list, not a tuple.
This fix should be applied to the documentation as well. On Tue, Mar 6, 2012 at 08:59, larry.hastings wrote: > http://hg.python.org/cpython/rev/d8f68195210e > changeset: 75448:d8f68195210e > user: Larry Hastings > date: Mon Mar 05 22:59:13 2012 -0800 > summary: > Fix a comment: PySequence_Fast() creates a list, not a tuple. > > files: > Include/abstract.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > diff --git a/Include/abstract.h b/Include/abstract.h > --- a/Include/abstract.h > +++ b/Include/abstract.h > @@ -1026,7 +1026,7 @@ > > PyAPI_FUNC(PyObject *) PySequence_Fast(PyObject *o, const char* m); > /* > - Returns the sequence, o, as a tuple, unless it's already a > + Returns the sequence, o, as a list, unless it's already a > tuple or list. Use PySequence_Fast_GET_ITEM to access the > members of this list, and PySequence_Fast_GET_SIZE to get its length. > > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > python-check...@python.org > http://mail.python.org/mailman/listinfo/python-checkins > ___ 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
Re: [Python-Dev] Sandboxing Python
On Mon, Mar 5, 2012 at 3:40 PM, "Martin v. Löwis" wrote: >> I strongly disagree that sandbox is secure because it's "just >> segfaults" and "any code is exploitable that way". Finding segfaults >> in CPython is "easy". As in all you need is armin, a bit of coffee and >> a free day. Reasons for this vary, but one of those is that python is >> a large code base that does not have automatic ways of preventing such >> issues like C-level recursion. >> >> For a comparison, PyPy sandbox is a compiled from higher-level >> language program that by design does not have all sorts of problems >> described. The amount of code you need to carefully review is very >> minimal (as compared to the entire CPython interpreter). It does not >> mean it has no bugs, but it does mean finding segfaults is a >> significantly harder endeavour. There are no bug-free programs, >> however having for example to segfault an arbitrary interpreter >> *written* in Python would be significantly harder than one in C, >> wouldn't it? > > While this may true, I can't conclude that we should stop fixing > crashers in CPython, or give up developing CPython altogether. While > it is a large code base, it is also a code base that will be around > for a long time to come, so any effort spend on this today will pay > off in the years to come. > > Regards, > Martin I did not say that Martin. PyPy sandbox does not come without issues, albeit they are not the security related kind. My point is that it does not make sense do add stuff to CPython to make sandboxing on the Python easier *while* there are still easily accessible segfaults. Fixing those issues, should be a priority *before* we actually start and tinker with other layers. All I'm trying to say is "if you want to make a sandbox on top of CPython, you have to fix segfaults". Cheers, fijal ___ 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
Re: [Python-Dev] Sandboxing Python
> I strongly disagree that sandbox is secure because it's "just > segfaults" and "any code is exploitable that way". Finding segfaults > in CPython is "easy". As in all you need is armin, a bit of coffee and > a free day. Reasons for this vary, but one of those is that python is > a large code base that does not have automatic ways of preventing such > issues like C-level recursion. > > For a comparison, PyPy sandbox is a compiled from higher-level > language program that by design does not have all sorts of problems > described. The amount of code you need to carefully review is very > minimal (as compared to the entire CPython interpreter). It does not > mean it has no bugs, but it does mean finding segfaults is a > significantly harder endeavour. There are no bug-free programs, > however having for example to segfault an arbitrary interpreter > *written* in Python would be significantly harder than one in C, > wouldn't it? While this may true, I can't conclude that we should stop fixing crashers in CPython, or give up developing CPython altogether. While it is a large code base, it is also a code base that will be around for a long time to come, so any effort spend on this today will pay off in the years to come. Regards, Martin ___ 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
Re: [Python-Dev] Sandboxing Python
> For a comparison, PyPy sandbox is a compiled from higher-level > language program that by design does not have all sorts of problems > described. The amount of code you need to carefully review is very > minimal (as compared to the entire CPython interpreter). It does not > mean it has no bugs, but it does mean finding segfaults is a > significantly harder endeavour. There are no bug-free programs, > however having for example to segfault an arbitrary interpreter > *written* in Python would be significantly harder than one in C, > wouldn't it? I agree that the PyPy sandbox design looks better... but some people are still using CPython and some of them need security. That's why there are projects like zope.security, RestrictedPython and others. Security was not included in CPython design. Python is a highly dynamic language which make the situation worse. I would like to improve CPython security. pysandbox is maybe not perfect, and it may only be a first step to improve security. Even if pysandbox has issues, having a frozendict type would help to secure applications. For example, it can be used later for __builtins__ or to build read-only types. I agree that each bug, especially segfault, may lead to exploitable vulnerabilities, but it doesn't mean that we should not consider hardening Python because of these bugs. Even if PHP is known for its lack of security and its broken safe_mode, people use it and run it on web server accessible to anyone on the Internet. There are also projects to harden PHP. For example: http://www.hardened-php.net/suhosin/ suhosin patch doesn't avoid the possiblity of segfault but it is harder to exploit them with the patch. I proposed to start with a frozendict because I consider that it is not only useful for security, and the patch to add the type is not intrusive. Other changes to use the patch can be discussed later, except if you consider that related changes (__builtins__ and read-only type) should be discussed to decide if a frozendict is required or not. Victor ___ 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
Re: [Python-Dev] Sandboxing Python
On Mon, Mar 5, 2012 at 1:21 PM, Greg Ewing wrote: > Armin Rigo wrote: >> >> For example, let's assume we can decref >> a object to 0 before its last usage, at address x. All you need is >> the skills and luck to arrange that the memory at x becomes occupied >> by a new bigger string object allocated at "x - small_number". > > > That's a lot of assumptions. When you claimed that *any* segfault > bug could be turned into an arbitrary-code exploit, it sounded > like you had a provably general procedure in mind for doing so, > but it seems not. > > In any case, I think Victor is right to object to his sandbox > being shot down on such grounds. The same thing equally applies > to any method of sandboxing any computation, whether it involves > Python or not. Even if you fork a separate process running code > written in Befunge, it could be prone to this kind of attack if > there is a bug in it. > > What you seem to be saying is "Python cannot be sandboxed, > because any code can have bugs." Or, "Nothing is ever 100% secure, > because the universe is not perfect." Which is true, but not in > a very interesting way. Not all of segfaults are exploitable, but most of them are. Some are super trivial (like the one armin explained, where it takes ~few hours for a skilled person), or some are only research paper kind of proof of concepts (double free is an example). I strongly disagree that sandbox is secure because it's "just segfaults" and "any code is exploitable that way". Finding segfaults in CPython is "easy". As in all you need is armin, a bit of coffee and a free day. Reasons for this vary, but one of those is that python is a large code base that does not have automatic ways of preventing such issues like C-level recursion. For a comparison, PyPy sandbox is a compiled from higher-level language program that by design does not have all sorts of problems described. The amount of code you need to carefully review is very minimal (as compared to the entire CPython interpreter). It does not mean it has no bugs, but it does mean finding segfaults is a significantly harder endeavour. There are no bug-free programs, however having for example to segfault an arbitrary interpreter *written* in Python would be significantly harder than one in C, wouldn't it? Cheers, fijal ___ 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
Re: [Python-Dev] Sandboxing Python
05.03.12 23:47, Guido van Rossum написав(ла): Maybe it would make more sense to add such a test to xrange()? (Maybe not every iteration but every 10 or 100 iterations.) `sum([10**100]*100)` leads to same effect. ___ 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
Re: [Python-Dev] Sandboxing Python
05.03.12 23:16, Victor Stinner написав(ла): > Apply the timeout would require to modify the sum() function. sum() is just one, simple, example. Any C code could potentially run long enough. Another example is the recently discussed hashtable vulnerability: class badhash: __hash__ = int(42).__hash__ set([badhash() for _ in range(10)]) > A more generic solution would be to use a subprocess. Yes, it's the only way to secure implement the sandbox. ___ 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
Re: [Python-Dev] Sandboxing Python
> Just forbid the sandboxed code from using the signal module, and set > the signal to the default action (abort). Ah yes, good idea. It may be an option because depending on the use case, failing with abort is not always the best option. The signal module is not allowed by the default policy. >> Apply the timeout would require to modify the sum() function. A more >> generic solution would be to use a subprocess. > > Maybe it would make more sense to add such a test to xrange()? (Maybe > not every iteration but every 10 or 100 iterations.) pysandbox may replace some functions by functions checking regulary the timeout to raise a Python exception instead of aborting the process. Victor ___ 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
Re: [Python-Dev] Sandboxing Python
>>> I challenge anymore to break pysandbox! I would be happy if anyone >>> breaks it because it would make it more stronger. > > I tried to run the files from Lib/test/crashers and --- kind of > obviously --- I found at least two of them that still segfaults > execfile.py, sometimes with minor edits and sometimes directly, on > CPython 2.7. Most crashers don't crash pysandbox because they use features blocked by pysandbox, like the gc module. Others fail with a timeout. 3 tests are crashing pysandbox: - modify a dict during a dict lookup: I proposed two different fixes in issue #14205 - type MRO changed during a type lookup (modify __bases__ during the lookup): I proposed a fix in issue #14199 (keep a reference to the MRO during the lookup) - stack overflow because of a compiler recursion: we should limit the depth in the compiler (i didn't write a patch yet) pysandbox should probably hide __bases__ special attribute, or at least make it read-only. > If you are not concerned about segfaults but only real attacks, then > fine, I will not spend the hours necessary to turn the segfault into a > real attack :-) It's possible to fix these crashers. In my experience, Python is very stable and has few crasher in the core language (e.g. compared to PHP). But I agree that it would be safer to run the untrusted code in a subprocess, by design. Running the code in a subprocess may be an option to provide higher level of security. Using a subprocess allows to reuse OS protections. Victor ___ 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
Re: [Python-Dev] Sandboxing Python
On Mon, Mar 5, 2012 at 1:16 PM, Victor Stinner wrote: > 2012/3/5 Serhiy Storchaka : >> 05.03.12 11:09, Victor Stinner написав(ла): >> >>> pysandbox uses SIGALRM with a timeout of 5 seconds by default. You can >>> change this timeout or disable it completly. >>> >>> pysandbox doesn't provide a function to limit the memory yet, you have >>> to do it manually. It's not automatic because there is no portable way >>> to implement such limit and it's difficult to configure it. For my IRC >>> bot using pysandbox, setrlimit() is used with RLIMIT_AS. >> >> >> But it does not work for extensive C-calculations. `sum(xrange(10))` >> runs 2.5 minutes on my computer instead of 5 seconds, and `map(sum, >> [xrange(10)] * 100)` -- almost infinity time. pysandbox doesn't >> provide a reliable time limit too, it is also necessary to mention. > > Ah yes, I realized that SIGALRM is handled by the C signal handler, > but Python only handles the signal later. sum() doesn't call > PyErr_CheckSignals() to check for pending signals. Just forbid the sandboxed code from using the signal module, and set the signal to the default action (abort). > Apply the timeout would require to modify the sum() function. A more > generic solution would be to use a subprocess. Maybe it would make more sense to add such a test to xrange()? (Maybe not every iteration but every 10 or 100 iterations.) -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Sandboxing Python
On Tue, 06 Mar 2012 10:21:12 +1300 Greg Ewing wrote: > > What you seem to be saying is "Python cannot be sandboxed, > because any code can have bugs." Or, "Nothing is ever 100% secure, > because the universe is not perfect." Which is true, but not in > a very interesting way. There is a difference between bugs and known bugs, though. Regards Antoine. ___ 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
Re: [Python-Dev] Sandboxing Python
Armin Rigo wrote: For example, let's assume we can decref a object to 0 before its last usage, at address x. All you need is the skills and luck to arrange that the memory at x becomes occupied by a new bigger string object allocated at "x - small_number". That's a lot of assumptions. When you claimed that *any* segfault bug could be turned into an arbitrary-code exploit, it sounded like you had a provably general procedure in mind for doing so, but it seems not. In any case, I think Victor is right to object to his sandbox being shot down on such grounds. The same thing equally applies to any method of sandboxing any computation, whether it involves Python or not. Even if you fork a separate process running code written in Befunge, it could be prone to this kind of attack if there is a bug in it. What you seem to be saying is "Python cannot be sandboxed, because any code can have bugs." Or, "Nothing is ever 100% secure, because the universe is not perfect." Which is true, but not in a very interesting way. -- Greg ___ 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
Re: [Python-Dev] Sandboxing Python
2012/3/5 Serhiy Storchaka : > 05.03.12 11:09, Victor Stinner написав(ла): > >> pysandbox uses SIGALRM with a timeout of 5 seconds by default. You can >> change this timeout or disable it completly. >> >> pysandbox doesn't provide a function to limit the memory yet, you have >> to do it manually. It's not automatic because there is no portable way >> to implement such limit and it's difficult to configure it. For my IRC >> bot using pysandbox, setrlimit() is used with RLIMIT_AS. > > > But it does not work for extensive C-calculations. `sum(xrange(10))` > runs 2.5 minutes on my computer instead of 5 seconds, and `map(sum, > [xrange(10)] * 100)` -- almost infinity time. pysandbox doesn't > provide a reliable time limit too, it is also necessary to mention. Ah yes, I realized that SIGALRM is handled by the C signal handler, but Python only handles the signal later. sum() doesn't call PyErr_CheckSignals() to check for pending signals. Apply the timeout would require to modify the sum() function. A more generic solution would be to use a subprocess. Victor ___ 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
Re: [Python-Dev] Exceptions in comparison operators
On Mon, Mar 5, 2012 at 4:41 AM, Mark Shannon wrote:
> Comparing two objects (of the same type for simplicity)
> involves a three stage lookup:
> The class has the operator C.__eq__
> It can be applied to operator (descriptor protocol): C().__eq__
> and it produces a result: C().__eq__(C())
>
> Exceptions can be raised in all 3 phases,
> but an exception in the first phase is not really an error,
> its just says the operation is not supported.
> E.g.
>
> class C: pass
>
> C() == C() is False, rather than raising an Exception.
>
> If an exception is raised in the 3rd stage, then it is propogated,
> as follows:
>
> class C:
> def __eq__(self, other):
> raise Exception("I'm incomparable")
>
> C() == C() raises an exception
>
> However, if an exception is raised in the second phase (descriptor)
> then it is silenced:
>
> def no_eq(self):
> raise Exception("I'm incomparable")
>
> class C:
> __eq__ = property(no_eq)
>
> C() == C() is False.
>
> But should it raise an exception?
>
> The behaviour for arithmetic is different.
>
> def no_add(self):
> raise Exception("I don't add up")
>
> class C:
> __add__ = property(no_add)
>
> C() + C() raises an exception.
>
> So what is the "correct" behaviour?
> It is my opinion that comparisons should behave like arithmetic
> and raise an exception.
I think you're probably right. This is one of those edge cases that
are so rare (and always considered a bug in the user code) that we
didn't define carefully what should happen. There are probably some
implementation-specific reasons why it was done this way (comparisons
use a very different code path from regular binary operators) but that
doesn't sound like a very good reason.
OTOH there *is* a difference: as you say, C() == C() is False when the
class doesn't define __eq__, whereas C() + C() raises an exception if
it doesn't define __add__. Still, this is more likely to have favored
the wrong outcome for (2) by accident than by design.
You'll have to dig through the CPython implementation and find out
exactly what code needs to be changed before I could be sure though --
sometimes seeing the code jogs my memory.
But I think of x==y as roughly equivalent to
r = NotImplemented
if hasattr(x, '__eq__'):
r = x.__eq__(y)
if r is NotImplemented and hasattr(y, '__eq__'):
r = y.__eq__(x)
if r is NotImplemented:
r = False
which would certainly suggest that (2) should raise an exception. A
possibility is that the code looking for the __eq__ attribute
suppresses *all* exceptions instead of just AttributeError. If you
change no_eq() to return 42, for example, the comparison raises the
much more reasonable TypeError: 'int' object is not callable.
--
--Guido van Rossum (python.org/~guido)
___
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
Re: [Python-Dev] Why does Mac OS X python share site-packages with apple python?
[edited for clarity] In article , Ned Deily wrote: > [...] It affects > user-installed framework-build Pythons, such as those provided by > python.org installers, allowing [the user-installed Pythons] to [use] > distributions that [were] explicitly > installed by the user [into] the system Pythons. -- Ned Deily, n...@acm.org ___ 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
Re: [Python-Dev] Why does Mac OS X python share site-packages with apple python?
In article <4f54c6c3.9040...@netwok.org>, Éric Araujo wrote: > Le 03/03/2012 22:57, Ned Deily a écrit : > > The python.org OS X Pythons (and built-from-source framework builds) add > > the Apple-specific directory to the search path in order to allow > > sharing of installed third-party packages between the two. > The interesting thing to me here is that Ned’s decision to allow sharing > some installed distributions/packages on Mac OS X is (IIUC) > diametrically opposed to the one made by Canonical developers when they > invented the dist-packages directory for Debian and Ubuntu to prevent > breaking the system Python by installing a distribution/package with a > python.org/built-from-source Python installed under /usr/local. Just to be clear, it wasn't my decision; this feature was added before I was a core developer. In any case, this is the opposite case: the system Python is not affected by this feature. It affects user-installed framework-build Pythons, such as those provided by python.org installers, allowing them to share distributions explicitly installed by the user with the system Pythons. It also does not share 3rd-party distributions included by Apple with the system Pythons. I'm +0 on it myself. -- Ned Deily, n...@acm.org ___ 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
[Python-Dev] Misc/NEWS in 2.7 and 3.2
Hi, I noticed that the top-level section in Misc/NEWS (i.e. the section where we add entries) for 3.3 is for 3.3.0a2 (the next release), but in 2.7 and 3.2 we’re still adding entries to the sections corresponding to the last RCs. Will the RMs move things when they merge back their release clones, or should we start new sections and move the latest entries there? Cheers ___ 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
Re: [Python-Dev] Why does Mac OS X python share site-packages with apple python?
Hi, Le 03/03/2012 22:57, Ned Deily a écrit : > The python.org OS X Pythons (and built-from-source framework builds) add > the Apple-specific directory to the search path in order to allow > sharing of installed third-party packages between the two. The interesting thing to me here is that Ned’s decision to allow sharing some installed distributions/packages on Mac OS X is (IIUC) diametrically opposed to the one made by Canonical developers when they invented the dist-packages directory for Debian and Ubuntu to prevent breaking the system Python by installing a distribution/package with a python.org/built-from-source Python installed under /usr/local. (On that note, there is still time to land http://bugs.python.org/issue1298835 “Adding a vendor-packages directory” into 3.3.) Regards ___ 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
Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 1
On 3/5/2012 2:54 AM, Georg Brandl wrote:
On behalf of the Python development team, I'm happy to announce the
first alpha release of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier
porting between 2.x and 3.x. Major new features in the 3.3 release
series are:
* PEP 380, Syntax for Delegating to a Subgenerator ("yield from")
* PEP 393, Flexible String Representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* PEP 409, Suppressing Exception Context
* PEP 3151, Reworking the OS and IO exception hierarchy
* The new "packaging" module, building upon the "distribute" and
"distutils2" projects and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 3155, Qualified name for classes and functions
* PEP 414, explicit Unicode literals to help with porting
* The new "faulthandler" module that helps diagnosing crashes
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html
The 3.3 whatsnews page doesn't seem to mention PEP 414 or Unicode
literals at all.
--Ned.
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
Please consider trying Python 3.3.0a1 with your code and reporting any
bugs you may notice to:
http://bugs.python.org/
Enjoy!
--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
___
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/ned%40nedbatchelder.com
___
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
[Python-Dev] Exceptions in comparison operators
Comparing two objects (of the same type for simplicity)
involves a three stage lookup:
The class has the operator C.__eq__
It can be applied to operator (descriptor protocol): C().__eq__
and it produces a result: C().__eq__(C())
Exceptions can be raised in all 3 phases,
but an exception in the first phase is not really an error,
its just says the operation is not supported.
E.g.
class C: pass
C() == C() is False, rather than raising an Exception.
If an exception is raised in the 3rd stage, then it is propogated,
as follows:
class C:
def __eq__(self, other):
raise Exception("I'm incomparable")
C() == C() raises an exception
However, if an exception is raised in the second phase (descriptor)
then it is silenced:
def no_eq(self):
raise Exception("I'm incomparable")
class C:
__eq__ = property(no_eq)
C() == C() is False.
But should it raise an exception?
The behaviour for arithmetic is different.
def no_add(self):
raise Exception("I don't add up")
class C:
__add__ = property(no_add)
C() + C() raises an exception.
So what is the "correct" behaviour?
It is my opinion that comparisons should behave like arithmetic
and raise an exception.
Cheers,
Mark
___
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
Re: [Python-Dev] Sandboxing Python
>>> You can't solve the too much time, without solving the halting problem, >> >> Not sure what you mean by that. It seems to me that it's particularly >> easy to do in a roughly portable way, with alarm() for example on all >> UNIXes. > > What time should you set the alarm for? How much time is enough before you > decide that a piece of code is taking too long? pysandbox uses SIGALRM with a timeout of 5 seconds by default. You can change this timeout or disable it completly. pysandbox doesn't provide a function to limit the memory yet, you have to do it manually. It's not automatic because there is no portable way to implement such limit and it's difficult to configure it. For my IRC bot using pysandbox, setrlimit() is used with RLIMIT_AS. Victor ___ 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
[Python-Dev] Remove f_yieldfrom attribute from frameobject
Could we remove the f_yieldfrom attribute from frameobject (at the Python level) before it is too late and we are stuck with it. Issue (with patch) here: http://bugs.python.org/issue13970 Cheers, Mark. ___ 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
