New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow "none" values for Choices when included in constants and/or string is an allowable type #6

Open
wants to merge 9 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@rayrrr
Copy link
Contributor

rayrrr commented Jul 22, 2018

This is a more robust approach to resolving #3.

What I'm proposing and showing here is that, instead of converting 'none' to None objects and then testing that that has been done in multiple unit tests, we can just reject 'none' as a value in the appropriate cases within the validate method, in one place.

This passes all unit tests.

@freakboy3742
Copy link
Member

freakboy3742 left a comment

I'm not convinced this is the right approach. We need to be very clear about the distinction between None (the Python symbolic value), "none" (a Python string with the value of "none") and NONE (a Python constant with the value of "none").

The current code (and tests) are a bit loose, and lean towards coercing "none" to None; I'd argue that's the original mistake. We shouldn't be allowing None at all.

Pack does this the right way - defining a constant NONE - but then gets caught in the loose coercion. That is the underlying problem that needs to be fixed, AFAICT.

@@ -271,7 +272,7 @@ def __init__(self):
except ValueError as v:
self.assertEqual(
str(v),
"Invalid value 'invalid' for property 'prop'; Valid values are: a, b, none"
"Invalid value 'invalid' for property 'prop'; Valid values are: a, b, none, none"

This comment has been minimized.

@freakboy3742

freakboy3742 Aug 18, 2018

Member

This makes me very skeptical. Why would we want to allow both 'none' as a string value, and None as a symbolic constant, rendered as a string indistinguishable from the string form?

This comment has been minimized.

@rayrrr

rayrrr Aug 18, 2018

Author Contributor

This is a side effect of what you're calling the "original mistake." When making the proposed change, the ValueError's message also coerces Python None to the string 'none'. So, since we are allowing both None and 'none' as values in the proposed change, this is what the message ends up looking like (repeating 'none' twice).

@rayrrr

This comment has been minimized.

Copy link
Contributor Author

rayrrr commented Aug 18, 2018

I agree with you about the underlying problem. Coercing "none" to None never sat well with me either. Can you point me in the right direction to fix the issue at the root?

@rayrrr

This comment has been minimized.

Copy link
Contributor Author

rayrrr commented Aug 18, 2018

I did some more research on this.

If we need to distinguish between Python's None object and either of the NONE constant or the 'none' string literal, that's easy. But if we want to distinguish between the NONE constant and the 'none' string literal, there's no built-in way to do it in Python, because if we set NONE = 'none', then both

NONE == 'none'
and
NONE is 'none'

evaluate to True, and we don't have a === like JavaScript...in fact, the two things we compare even have the same hash and id in Python because of how it uses object references for "variables" internally.

If we need a workaround, I think a magic NONE constant based on a subclass of str is one option worth considering. If we do:

class MagicConstant(str):
    def is_constant(self):
        return True

NONE = MagicConstant('none')

when setting up the constant, then

NONE == 'none' evaluates to True,

but NONE is 'none' evaluates to False

so that could be useful. Magic can be bad, but if we need this functionality, this workaround might be worth it. I've confirmed this approach works on versions 2.7 and 3.6.

@freakboy3742

This comment has been minimized.

Copy link
Member

freakboy3742 commented Aug 19, 2018

So, we will need to differentiate the symbolic None from the string "none", but we don't need to differentiate the constant NONE = 'none' from the string "none" - those last two are equivalent (with the symbolic constant just being a convenience to avoid typos).

@rayrrr

This comment has been minimized.

Copy link
Contributor Author

rayrrr commented Aug 19, 2018

Good. No need for magic! So where do we go to get to the root of this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment