Issue1645

classification
Title: PyBoolean, PyFloat, PyLong, PyString, PyUnicode should consistently use getValue instead of value directly
Type: behaviour Severity: normal
Components: Core Versions: 2.5.1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: zyasoft Nosy List: JonathanFeinberg, zyasoft
Priority: normal Keywords: patch

Created on 2010-08-17.17:37:13 by zyasoft, last changed 2010-10-15.14:03:55 by zyasoft.

Files
File name Uploaded Description Edit Remove
fix_and_test_numeric_accessors.diff JonathanFeinberg, 2010-08-18.02:42:07 Patch to implement change described
unnamed JonathanFeinberg, 2010-08-18.14:36:56
Messages
msg5984 (view) Author: Jim Baker (zyasoft) Date: 2010-08-17.17:37:12
This will allow for users to extend these types in interesting ways, as seen in processing.py, and should not have a performance impact on any modern JVM. (It's already consistently done in PyInteger.)
msg5985 (view) Author: Jim Baker (zyasoft) Date: 2010-08-17.19:24:04
This refactoring would probably be reasonable for PyDictionary and other types, but deferring that for now, so changing the title.

Because PyBoolean is a subclass of PyInteger (due to int/bool compatibility in Python, which stems from the lack of bool prior to 2.2), you need to override getBooleanValue, which is then used by getValue.

Fixed in r7097, but marking as pending because we need unit tests around how this can be used to support user type extension.
msg5987 (view) Author: Jonathan Feinberg (JonathanFeinberg) Date: 2010-08-18.02:42:07
The enclosed patch fixes a couple of lingering non-encapsulated references to the field, and creates unit tests for each of the affected classes. The unit tests can and will be improved in the coming days to exercise more __magic__ operator methods, but this puts the basic format in place.
msg5988 (view) Author: Jim Baker (zyasoft) Date: 2010-08-18.03:16:09
I think I understand why you'd want to construct mutable versions of these types for something like processing.py, but two cautions if this is representative of your code:

1) Obviously objects of these types are no longer hashable as such and thus will really screw things up if they're placed in a Map. You may want to change their hashCode to be on their object identity, or throw a TypeError, like PyList.

2) Normally you should consider making the underlying fields volatile.

Mutation likely impacts PyString/PyUnicode even more.
 
Also, the current field in PyString is string, so should it be getValue or getString? I tend to favor the latter form this moment.
msg5990 (view) Author: Jonathan Feinberg (JonathanFeinberg) Date: 2010-08-18.14:36:57
> 1) Obviously objects of these types are no longer hashable as such and thus
> will really screw things up if they're placed in a Map. You may want to
> change their hashCode to be on their object identity, or throw a TypeError,
> like PyList.
>

Excellent advice. Your intuition is right, that this is a peculiar use case.
It would be bizarre for a processing user to use, say, the current mouse x
position in pixels as a dictionary key.

Devil's advocate: given your legitimate concern that PyInteger and its kin
represent immutable values, why isn't "value" immutable?

Finally, I should say that given how idiosyncratic my use case is, I
wouldn't have any hard feelings if the committers thought it best to go back
to direct field access on an i

> 2) Normally you should consider making the underlying fields volatile.
>

Will do.

> Also, the current field in PyString is string, so should it be getValue or
> getString? I tend to favor the latter form this moment.
>

I'd argue for the former for some sort of "least surprise" aesthetic
relative to the other PyThings, but I'm very new to the project, and
wouldn't want to argue strongly for anything!

Very kind regards,
-- 
Jonathan Feinberg  jdf@pobox.com  http://MrFeinberg.com/
msg5991 (view) Author: Jim Baker (zyasoft) Date: 2010-08-19.01:44:43
PyInteger.value not being final is definitely an oversight, like so much discussed here. I actually changed the other fields to be final. I will make that change too, as well as try out the patch.
msg5995 (view) Author: Jim Baker (zyasoft) Date: 2010-08-21.03:58:02
Committed Jonathan's patchset in r7100. Thanks!

We still need more tests around PyString, PyUnicode, as well as the whole hashing discussion, but it's looking good.
msg6169 (view) Author: Jim Baker (zyasoft) Date: 2010-10-15.14:03:55
Closing this bug out. We always need more tests, but it's enough for now.
History
Date User Action Args
2010-10-15 14:03:55zyasoftsetstatus: open -> closed
messages: + msg6169
2010-09-09 05:44:51zyasoftsetpriority: normal
2010-08-21 03:58:04zyasoftsetmessages: + msg5995
2010-08-19 01:44:44zyasoftsetmessages: + msg5991
2010-08-18 14:36:58JonathanFeinbergsetfiles: + unnamed
messages: + msg5990
2010-08-18 03:16:10zyasoftsetstatus: pending -> open
messages: + msg5988
title: PyBoolean, PyFloat, PyLong should consistently use getValue instead of value directly -> PyBoolean, PyFloat, PyLong, PyString, PyUnicode should consistently use getValue instead of value directly
2010-08-18 02:42:09JonathanFeinbergsetfiles: + fix_and_test_numeric_accessors.diff
keywords: + patch
messages: + msg5987
nosy: + JonathanFeinberg
2010-08-17 19:24:05zyasoftsetstatus: open -> pending
assignee: zyasoft
components: + Core
title: Builtin types like PyFloat should consistently use getValue instead of value directly -> PyBoolean, PyFloat, PyLong should consistently use getValue instead of value directly
messages: + msg5985
versions: + 2.5.1
type: behaviour
resolution: fixed
2010-08-17 17:37:13zyasoftcreate