[00:10] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 2 hr and 3 minutes ----- [02:13] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)
----- silence for 1 hr and 21 minutes ----- [03:34] Continuity (~kittish@host81-156-153-153.range81-156.btcentralplus.com) left irc: Client Quit
----- silence for 4 hr and 19 minutes ----- [07:53] ironfroggy (konversat@cpe-069-132-041-189.carolina.rr.com) left #pypy ("I'm tired of talking to you, so I makes you go away.").
----- silence for 3 hr and 22 minutes ----- [11:15] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 24 minutes ----- [11:39] tiberius (~tiberius1@pD9E10EC3.dip.t-dialin.net) joined #pypy.
[11:39] tiberius (tiberius1@pD9E10EC3.dip.t-dialin.net) left #pypy.
----- silence for 1 hr and 57 minutes ----- [13:36] sanxiyn (~tinuviel@222.233.187.73) joined #pypy.
----- silence for 23 minutes ----- [13:59] _hannes (wdbxtgw@i528C1E2E.versanet.de) joined #pypy.
----- silence for 46 minutes ----- [14:45] yuuh (sckjkn@i3ED6B211.versanet.de) joined #pypy.
----- silence for 17 minutes ----- [15:02] _hannes (wdbxtgw@i528C1E2E.versanet.de) left irc: Read error: 110 (Connection timed out)
[15:08] Nick change: yuuh -> _hannes
[15:23] sanxiyn (tinuviel@222.233.187.73) left #pypy ("Bye").
----- silence for 51 minutes ----- [16:14] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)
----- silence for 2 hr and 44 minutes ----- [18:58] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.
[19:07] arigo (~arigo@d83-176-48-217.cust.tele2.ch) joined #pypy.
----- silence for 1 hr and 42 minutes ----- [20:49] Continuity (~kittish@host81-155-190-53.range81-155.btcentralplus.com) joined #pypy.
----- silence for 1 hr and 36 minutes ----- [22:25] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 56 minutes ----- [23:21] Action: arigo found a funny CPython bug
[23:22] <arigo> class X(object):
[23:22] <arigo> class __metaclass__(type):
[23:22] <arigo> def mro(self):
[23:22] <arigo> return [self, float, object]
[23:22] <arigo> x = X()
[23:22] <arigo> print float(x)
[23:22] <arigo> Segmentation fault
[23:28] <pedronis> interesting
[23:28] <arigo> PyFloat_Check() and more generally PyXxx_Check(9
[23:29] <pedronis> in PyPy
[23:29] <pedronis> it fails at X()
[23:29] <arigo> are implemented by looking at the incoming argument's tp_mro!
[23:29] <arigo> yes, funny
[23:29] <arigo> somehow, PyPy gives the reasonable answer
[23:29] <pedronis> yes
[23:31] <arigo> there is no way in PyPy to create an instance of such a class?
[23:32] <pedronis> x=object.__new__(X)
[23:32] <arigo> uh
[23:33] <pedronis> but you still get errors from all float methods
[23:34] <pedronis> our internal final dispatching
[23:34] <pedronis> does not depend on the mro
[23:36] <arigo> I still guess there must be a way to crash PyPy too
[23:37] <pedronis> well you need something that does no typechecking
[23:37] <pedronis> here all lookups find float methods
[23:37] <pedronis> but those report unsopported operand
[23:38] <pedronis> also something that does isinstance w_float
[23:38] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
[23:39] <pedronis> may then crash
[23:39] <arigo> however, isinstance(w_x, w_float) should never be followed by the assumption that x is a W_FloatObject
[23:39] <pedronis> yes
[23:39] <arigo> it seems that only multimethod implementations ever do this assumption
[23:41] <pedronis> ?
[23:41] <pedronis> multimethod check concrete types
[23:41] <arigo> yes, precisely
[23:41] <arigo> I'm saying that nothing else assumes that w_x has a specific concrete type, not even after an isinstance
[23:41] <pedronis> yes, mm do isinstance
[23:41] <pedronis> on W_FloatObject
[23:42] <arigo> I meant space.isinstance()
[23:42] <pedronis> but multimethods
[23:42] <pedronis> don't do that
[23:42] <arigo> yes I'm saying that *only* multimethods don't do that and use the concrete instance
[23:43] <pedronis> so they cannot crash
[23:43] <arigo> indeed
[23:43] <arigo> however, a far-fetch example:
[23:43] <arigo> import types
[23:43] <arigo> class X(object):
[23:43] <arigo> class __metaclass__(type):
[23:43] <arigo> def mro(self):
[23:43] <arigo> return [self, types.CodeType, object]
[23:43] <arigo> x = object.__new__(X)
[23:43] <arigo> exec x
[23:46] <pedronis> this one crashes
[23:47] <arigo> import types
[23:47] <arigo> class X(object):
[23:47] <arigo> class __metaclass__(type):
[23:47] <arigo> def mro(self):
[23:47] <arigo> return [self, types.FunctionType, object]
[23:47] <arigo> x = object.__new__(X)
[23:47] <arigo> x.func_code
[23:47] <arigo> this one crashes too
[23:48] <pedronis> strange
[23:48] <arigo> here the descriptor trusts that it gets a Function object
[23:48] <arigo> actually I'm looking for all calls to interpclass_w()
[23:49] <arigo> each of them is a potential hole if it isn't immediately followed by a concrete isinstance().
[23:49] <pedronis> but some of them are followed
[23:49] <arigo> yes, but not all
[23:49] <pedronis> yes
[23:49] <pedronis> I see
[23:49] <arigo> for the descriptors it's in gateway.py's unwrap_spec_emit_self
[23:49] <arigo> which does a bare interpclass_w()
[23:50] <pedronis> no
[23:50] <pedronis> mmh
[23:50] <pedronis> that is not used anymore
[23:50] <arigo> uh
[23:50] <pedronis> they should go through BaseWrappable
[23:51] <arigo> ah wait
[23:51] <arigo> I didn't svn up for quite some time actually
[23:52] <pedronis> emit_self
[23:52] <pedronis> is no more
[23:52] <arigo> ok, my last example is safe now
[23:52] <pedronis> but yes places
[23:52] <pedronis> that use space.isinstance
[23:52] <pedronis> and then assume a concrete class
[23:52] <pedronis> are not safe
[23:53] <pedronis> (and are also annotator unfriendly)
[23:54] <arigo> yes
[23:55] <arigo> I wonder if we can formally prove that full annotator-friendlyness means full type safety
[23:58] <pedronis> btw I worked a bit on the annotator last week
[00:00] --- Mon Feb 28 2005