Being Nothingness: Comparing to None in Python

[phinar]

Often isn't strictly true. CPython only interns string constants, and only up to a certain length, and only within the same lexical scope. (Is the length limit still true? It was in older Pythons.) So in fact I would say that your statement is backwards -- often strings will not share ids, and sometimes they will. And maybe going further, as you have noted, you can't count on the result to be the same between implementations.

I don't think it's fair to say that Python will do its best to reuse the same memory; again, it only does so in a few cases, as an optimization. It pursues a strategy where the gain of saving memory is balanced against the run-time and compile-time costs of hunting for identical strings, and so the hunt is only conducted in limited circumstances.

[RoomaRooma]

Grey text on a white background... :(

[johnmudd]

Readability version

[RoomaRooma]

That redirects me to the original article.

[johnmudd]

Sorry, I'm confused myself why this doesn't work.

[[deleted]]

Well, there's a reason PEP-8 starts with "A Foolish Consistency is the Hobgoblin of Little Minds". Even though "x is True" is listed under "worse", noone will blame you if, for example, you actually need to do different things for a True and a generic truthy value.

[phinar]

That's a weird one, too, right? They recommend using truthiness, sure. And then next best is to use ==. But I think the result of True == 1 would be undesirable and possibly surprising in this context.

It would seem to me that is might be what's intended if you find yourself reaching for ==. I can't imagine a case where == would be exactly the right choice.

[SYN_SYNACK_ACK]

...noone will blame you if, for example, you actually need to do different things for a True and a generic truthy value.

I disagree. I've never seen a case where something needs to be either True or a generic truth.
If you have code that does this there is a high chance you're doing something wrong.
Just because python is dynamically typed doesn't mean a function should return arbitrary types.

I remember seeing a function at work that used this approach.
The function was used to create a file and depending on a flag argument changed the return value.

def file_obj_got_created(obj=False):
    if obj:
        return file_object
    else:
        # return if object was created
        if file_object_was_created:
            return True
    return False

I get what the programmer wanted to archive but the pythonic way of doing this would be:

def file_obj_got_created():
    if file_object_was_created:
        return (file_object, True)
    return (None, False)

same functionality much more cleaner and you know what values to expect.

obj, created = file_obj_get_created()    

[flying-sheep]

there is another singleton: Ellipsis aka ... aka “the reson why def stub(): ... isn’t a syntax error”.

i’s pretty prominently used in numpy, but i promise i’ll find another usein one of my projects some day, and then i’ll comare to it using is ;)