Archive

Posts Tagged ‘raw_input’

Python rstrip and whitespace

Was just reading

https://www.w3schools.com/python/ref_string_rstrip.asp

which says

The rstrip() method removes any trailing characters (characters at the end a string), space is the default trailing character to remove.

Notes:

1) the chars param was added at Python 2.2.3, can’t use it at older versions as noted at

https://docs.python.org/2.6/library/string.html

string.rstrip(s[, chars])
Return a copy of the string with trailing characters removed. If chars is omitted or None, whitespace characters are removed. If given and not None, chars must be a string; the characters in the string will be stripped from the end of the string this method is called on.

Changed in version 2.2.3: The chars parameter was added. The chars parameter cannot be passed in earlier 2.2 versions.

2) from the official doc and other docs too I read the default is to remove whitespace characters, not just the space char:

https://python-reference.readthedocs.io/en/latest/docs/str/rstrip.html

chars
Optional. String specifying the set of characters to be removed. If omitted or None, the chars argument defaults to removing whitespace. The chars argument is not a prefix; rather, all combinations of its values are stripped.

Not sure what is considered whitespace in various Python versions though. At least in Python2 it wasn’t removing \r in both Solaris and MSYS2 (a POSIX environment on Windows) where I just tried.

For example, I was just debugging some program that was working in Python 3, but in Python 2 it was moving the cursor to the start of the line when printing a raw_input prompt with some string it had read before…
…the issue proved to be that it was opening a file with ‘r’ mode instead of ‘rU’ which is universal newlines mode – https://www.python.org/dev/peps/pep-0278/ – converts \r\n to \n – and it seems that rstrip was failing to remove the \r from the end of those strings.

In Python 3 it was either using the universal newlines mode by default and thus stripping the \r from strings while reading from the file, or the rstrip was removing \r too in Python3, but I guess it was the 1st case (didn’t do any more check since the universal newlines read file open mode fixed the issue in Python 2 for me).

Speaking of that, I wonder whether Python considers whitespace differently on Windows and on Unixes (aka having [l/r]strip commands remove \r on the 1st but not on the 2nd case), which would be an extra complexity when writing portable s/w.

HowTo: make raw_input & input work the same in both Python 2 and 3

Was just trying to make a Python 2 script work in Python 3 and at first it seemed I just needed a small change to add missing parentheses to the argument of a couple of print statements.

But then another issue came up, it wasn’t understanding the command raw_input(somePrompt) that was occuring at various places in that file to input text from the console.

Various solutions were proposed at

https://stackoverflow.com/questions/954834/how-do-i-use-raw-input-in-python-3/62825723

but I think I came up with a cleaner looking solution that works in both Python2 and Python3, that should allow one to use either raw_input or input in both Python2 and Python3 with the semantics of Python2’s raw_input (aka the semantics of Python3’s input).

# raw_input isn't defined in Python3.x, whereas input wasn't behaving 
# like raw_input in Python 2.x. This should make both input and raw_input 
# work in Python 2.x/3.x like the raw_input from Python 2.x 
try: input = raw_input
except NameError: raw_input = input

In practice this came up from ideas at other answers on that SO thread. It tries to define input as raw_input which should fail in Python3.x since raw_input is undefined. In that case it will catch a NameError exception and do the reverse, aka define raw_input as input. However in Python2 the first command should execute fine, overriding the insecure input of Python2.x to work the same as raw_input (not trying to interpret input strings that is). Actually that is what Python 3.x input does.

Wonder why they didn’t declare it like that in the first place though, breaking compilation of Python2 programs. After all semantically only Python2 programs that were using the old insecure input would have an issue, not those that were using raw_input which is the semantics Python3 promotes with its newer input.

%d bloggers like this: