It's probably a consequence of the parsing algorithm used. A simple mental model is that the tokenizer attempts to match all the token patterns there are, and recognizes the longest match it finds. On a lower-level, the tokenizer works character-by-character, and makes a decision based only on the current state and input character – there shouldn't be any backtracking or re-reading of input.

After joining patterns with common prefixes – in this case, the pattern for int literals and the integral part of the pattern of float literals – what happens in the tokenizer is that it:

1. Reads the 1, and enters the state that indicates "reading either a float or an int literal"
2. Reads the ., and enters the state "reading a float literal"
3. Reads the _, which can not be part of a float literal. The parser emits 1. as a float literal token.
4. Carries on parsing starting with the _, and eventually emits __class__ as an identifier token.

Aside: This tokenizing approach is also the reason why common languages have the syntax restrictions they have. E.g. identifiers contain letters, digits, and underscores, but cannot start with a digit. If that was allowed, 123abc could be intended as either an identifier, or the integer 123 followed by the identifier abc.

A lex-like tokenizer would recognize this as the former since it leads to the longest single token, but nobody likes having to keep details like this in their head when trying to read code. Or when trying to write and debug the tokenizer for that matter.

The parser then tries to process the token stream:

<FloatLiteral: '1.'> <Identifier: '__class__'>

In Python, a literal directly followed by an identifier – without an operator between the tokens – makes no sense, so the parser bails. This also means that the reason why Python would complain about 123abc being invalid syntax isn't the tokenizer error "the character a isn't valid in an integer literal", but the parser error "the identifier abc cannot directly follow the integer literal 123"

The reason why the tokenizer can't recognize the 1 as an int literal is that the character that makes it leave the float-or-int state determines what it just read. If it's ., it was the start of a float literal, which might continue afterwards. If it's something else, it was a complete int literal token.

It's not possible for the tokenizer to "go back" and re-read the previous input as something else. In fact, the tokenizer is at too low a level to care about what an "attribute access" is and handle such ambiguities.

Now, your second example is valid because the tokenizer knows a float literal can only have one . in it. More precisely: the first . makes it transition from the float-or-int state to the float state. In this state, it only expects digits (or an E for scientific/engineering notation, a j for complex numbers…) to continue the the float literal. The first character that's not a digit etc. (i.e. the .) is definitely no longer part of the float literal and the tokenizer can emit the finished token. The token stream for your second example will thus be:

<FloatLiteral: '1.'> <Operator: '.'> <Identifier: '__class__'>

Which, of course, the parser then recognizes as valid Python. Now we also know enough why the suggested workarounds help. In Python, separating tokens with whitespace is optional – unlike, say, in Lisp. Conversely, whitespace does separate tokens. (That is, no tokens except string literals may contain whitespace, it's merely skipped between tokens.) So the code:

1 .__class__

is always tokenized as

<IntLiteral: '1'> <Operator: '.'> <Identifier: '__class__'>

And since a closing parenthesis cannot appear in an int literal, this:

(1).__class__

gets read as this:

<Operator: '('> <IntLiteral: '1'> <Operator: ')'> <Operator: '.'> <Identifier: '__class__'>

The above implies that, amusingly, the following is also valid:

1..__class__ # => <type 'float'>

The decimal part of a float literal is optional, and the second . read will make the preceding input be recognized as one.

Take a look at the three parts of your code I've annotated with numbers in parentheses:

   def run(self,X,Y,lock):
        while True:
               #some calculations which returns x and y 
               with lock :
                 X.value = x
                 Y.value = y

                 # (3) you now try to access an attribute of the arguments
                 # called 'value'
                 print X.value , Y.value , self.process_id


if __name__ == '__main__':
    xL = Value('d',0.0) # (1) these variables are assigned some objects that
    xR = Value('d',0.0) # are returned by the function 'Value'
    yL = Value('d',0.0) 
    yR = Value('d',0.0) 

    lock = Lock()

    a = A('1')
    b = B('2')

    # (2) now your variables are being passed to the 'a.run' and 'b.run'
    # methods
    process_a = Process(target = a.run, args(xL,yL,lock, ))  
    process_b = Process(target = b.run, args(xR,yR,lock, ))

    process_a.start()
    process_b.start()

When you trace through the execution of your code, you can see that it is attempting to access an attribute called value in whatever objects are returned by the function Value. Your error message is telling you that Value is returning float objects, which do not have a value attribute.

One of the following things is (most likely) going wrong for you:

1. The function Value is not doing what you think it is, and it's returning floats when it shouldn't.
2. In your "some calculations which return x and y" code, you're overwriting the X and Y arguments with floats.

Try this instead,

  print(
"{:.3f}% {} ({} sentences)".format(pcent, gender, nsents)
)

Refer the latest docs for more examples and check the Py version!

Mutable objects always create a new object, otherwise the data would be shared. There's not much to explain here, as if you append an item to an empty list, you don't want all of the empty lists to have that item.

Immutable objects behave in a completely different manner:

• Strings get interned. If they are smaller than 20 alphanumeric characters, and are static (consts in the code, function names, etc), they get cached and are accessed from a special mapping reserved for these. It is to save memory but more importantly used to have a faster comparison. Python uses a lot of dictionary access operations under the hood which require string comparison. Being able to compare 2 strings like attribute or function names by comparing their memory address instead of the actual value, is a significant runtime improvement.

• Booleans simply return the same object. Considering there are only 2 available, it makes no sense creating them again and again.

• Small integers (from -5 to 256) by default, are also cached. These are used quite often, just about everywhere. Every time an integer is in that range, CPython simply returns the same object.

Floats however are not cached. Unlike integers, where the numbers 0-10 are extremely common, 1.0 isn't guaranteed to be more used than 2.0 or 0.1. That's why float() simply returns a new float. We could have optimized the empty float(), and we can check for speed benefits but it might not have made such a difference.

The confusion starts to arise when float(0.0) is float(0.0). Python has numerous optimizations built in:

• First of all, consts are saved in each function's code object. 0.0 is 0.0 simply refers to the same object. It is a compile-time optimization.

• Second of all, float(0.0) takes the 0.0 object, and since it's a float (which is immutable), it simply returns it. No need to create a new object if it's already a float.

• Lastly, 1.0 + 1.0 is 2.0 will also work. The reason is that 1.0 + 1.0 is calculated on compile time and then references the same 2.0 object:

  def test():
      return 1.0 + 1.0 is 2.0
  
  dis.dis(test)
    2           0 LOAD_CONST               1 (2.0)
                2 LOAD_CONST               1 (2.0)
                4 IS_OP                    0
                6 RETURN_VALUE
  

  As you can see, there is no addition operation. The function was compiled with the result pointing to the exact same constant object.

So while there is no float-specific optimization, 3 different generic optimizations are into play. The sum of them is what ultimately decides if it'll be the same object or not.