documentation of _immutable_?
Hi, any place where I can find docs describing _immutable_ and _immutable_fields_ in some detail? As it happens, they don't quite do what I expected, which led to bugs. I'd like to know what their scope is and what the wildcards do. Right now I just removed them all to be safe (and allow some experimentation). But that is costing performance (20% extra overhead). Also, I see _attrs_ in quite a few places. What is it for? Thanks, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
On Tue, Oct 30, 2012 at 1:15 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
A very short answer is "never use _immutable_ it's very confusing". _immutable_fields_ is better (for subclassing) Wildcards mean "array on the instance is immutable" so a[*] means x.a[3] will be constant folded, if x is a constant.
Hi Maciej,
A very short answer is "never use _immutable_ it's very confusing".
that I found out the hard way already. :)
I've also seen an '?' appended to field names? But it is the last set of rules that I'm interested in (the "if" portion of the rule in particular). Something like it seems to have bit me: there was a field that was constant only by inheritance of _immutable_ = True, but it didn't hurt until the container variable received a jit.promote(). With both in place, I got wrong results. With the promote() removed, I got: [bogus _immutable_field_ declaration: <FieldU pypy.module.cppyy.executor.BasicRefExecutor.inst_do_assign 12>] which was very nice (as a diagnostic). Removing the _immutable_ = True, however, did not resolve the issue like I expected, as (I think, still investigating) the object was part of an object that also had _immutable_ set to True, making it immutable still. My current guess is that I should selectively use _immutable_fields_ only, and not promote whole objects, but only fields of objects. The other issue that I have, is that it seems to be okay to make a field immutable if it will be set once on first use (i.e. if guaranteed to be set before the JIT kicks in)? If true, that'd be a nice feature. Looking forward to those docs. :) Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
On Tue, Oct 30, 2012 at 1:15 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
A very short answer is "never use _immutable_ it's very confusing". _immutable_fields_ is better (for subclassing) Wildcards mean "array on the instance is immutable" so a[*] means x.a[3] will be constant folded, if x is a constant.
Hi Maciej,
A very short answer is "never use _immutable_ it's very confusing".
that I found out the hard way already. :)
I've also seen an '?' appended to field names? But it is the last set of rules that I'm interested in (the "if" portion of the rule in particular). Something like it seems to have bit me: there was a field that was constant only by inheritance of _immutable_ = True, but it didn't hurt until the container variable received a jit.promote(). With both in place, I got wrong results. With the promote() removed, I got: [bogus _immutable_field_ declaration: <FieldU pypy.module.cppyy.executor.BasicRefExecutor.inst_do_assign 12>] which was very nice (as a diagnostic). Removing the _immutable_ = True, however, did not resolve the issue like I expected, as (I think, still investigating) the object was part of an object that also had _immutable_ set to True, making it immutable still. My current guess is that I should selectively use _immutable_fields_ only, and not promote whole objects, but only fields of objects. The other issue that I have, is that it seems to be okay to make a field immutable if it will be set once on first use (i.e. if guaranteed to be set before the JIT kicks in)? If true, that'd be a nice feature. Looking forward to those docs. :) Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
participants (2)
-
Maciej Fijalkowski -
wlavrijsen＠lbl.gov