Now that methods exactly match their python names, should we do the same for free-standing functions? i.e. should this just be str?

Maybe. I quite like the convention, it makes it a bit easier to know what's what. I think I'd call that new rather than str though.

Of course, that function could be a method.

But it can't be a method called new because that clashes with the implementation of new in PyRef.

I really like the idea of it being a new method though (feels more idiomatic). We can probably get rid of PyRef::new and have a generic into_ref on PyValues.

(doesn't need to be in this PR though, just tossing out ideas)

I think it is more consistent that base strings have attribute dicts, I believe cpython is wrong here. We can deviate. You can use the platform module to check for rustpython.

It feels like a pretty serious performance question, if we have to allocate dicts for intermediate ints and bools in computations.

It's important enough that __slots__ exists so that user classes can take advantage of this.

It feels like a pretty serious performance question, if we have to allocate dicts for intermediate ints and bools in computations.

Not just that; this also makes other common optimizations on builtin types that we would probably implement at some point (string interning, small int cache) much weirder and harder to reason about.

In CPython:

>>> a = "hello"
>>> b = "hello"
>>> a is b
True
>>> a = 123
>>> b = 123
>>> a is b
True

So if in one section of code I do "hello".x = 5, this may affect any other code (including third-party library) using the same "hello" literal - as it may or may not be interned. Same with other builtins. That's implicit global state.