Archive
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: Copy effective-computed CSS style for specific HTML paragraph
I’m in the process of setting up a temporary landing page for the trafilm project, where I need apart from showing the trafilm logo to also show some text description about the project, till I set up an instance of MonoX Social CMS for it, like the one in ClipFlair’s Community website (ClipFlair Social).
Since ClipFlair Social has some nice text styling, I decided to borrow the style of one of its home page paragraphs, using Firefox web browser’s developer tools (accessible via F12 key).
Being at the Inspector tab of the dev tools (which is the default when they first open), using the “Pick element” tool (first one on the dev tools pane’s toolbar on the left), I select the paragraph that looks nicely styled and I go to the Computed tab at the Style view, then press CTR+A to select all computed style CSS declarations for that paragraph element and press CTRL+C or right click and select Copy to copy them to the clipboard.
If pasted (CTRL+V) in some text editor like Window’s Notepad that looks like a big ugly line, since they contain Unix-style line-endings, that is LF (linefeed) and not Windows-style ones (CRLF, Carriage Return + Line Feed), but editors like Wordpad or Notepad++ can show them nicely and even convert line endings from Unix to Windows and vice-versa if you wish so (e.g. in Notepad++ the respective actions are at Edit / EOL Conversion menu).
So, this is the copied Computed CSS style for that paragraph:
border-bottom-color: #333;
border-bottom-style: none;
border-bottom-width: 0px;
border-image-outset: 0 0 0 0;
border-image-repeat: stretch stretch;
border-image-slice: 100% 100% 100% 100%;
border-image-source: none;
border-image-width: 1 1 1 1;
border-left-color: #333;
border-left-style: none;
border-left-width: 0px;
border-right-color: #333;
border-right-style: none;
border-right-width: 0px;
border-top-color: #333;
border-top-style: none;
border-top-width: 0px;
color: #333;
cursor: default;
font-family: "Open Sans",sans-serif;
font-size: 14px;
font-weight: 400;
letter-spacing: 0px;
line-height: 24px;
margin-bottom: 20px;
margin-left: 0px;
margin-right: 0px;
margin-top: 0px;
padding-bottom: 10px;
padding-left: 0px;
padding-right: 0px;
padding-top: 0px;
-moz-border-bottom-colors: none;
-moz-border-left-colors: none;
-moz-border-right-colors: none;
-moz-border-top-colors: none;
As you can see, it has lots of stuff that isn’t needed, unless you want to be sure your style doesn’t get affected by style of parent elements. In my case I decided to trim it down a bit:
color: #333;
font-family: "Open Sans",sans-serif;
font-size: 14px;
font-weight: 400;
letter-spacing: 0px;
line-height: 24px;
margin-bottom: 20px;
margin-left: 0px;
margin-right: 0px;
margin-top: 0px;
padding-bottom: 10px;
padding-left: 0px;
padding-right: 0px;
padding-top: 0px;
Adding around the text above (which is represented by the CSS comment /* … */ below) a CSS selector to wrap those declarations in order to make a proper CSS rule-set:
p {
}
and passing to CSS LINT tool to help us clean up the CSS we get no errors, but several warnings:
For example, as explained at W3Schools.com, in CSS one can use shorthand margin and padding properties:
The
margin
property is a shorthand property for the following individual margin properties:
margin-top
margin-right
margin-bottom
margin-left
CSS has properties for specifying the padding for each side of an element:
padding-top
padding-right
padding-bottom
padding-left
…so one wonders why Firefox Dev Tools don’t spit those out with that order and give them in bottom, left, right and top order instead.
Also instead of 0px, one is suggested to always write 0 instead, since zero will always be zero irrespective of the CSS units used for it (at least for the currently available CSS unit systems that is). This is merely to save in bandwidth I think, since 0px is better, suggesting to anyone modifying this value in the future they’d better use “px” [pixels] instead of say “pt” [points]).
So we clean up this CSS into (pay attention to the order of values in margin and padding shorthand declarations, which is top, right, bottom, left, that is clockwise starting from the top side of the HTML elements targeted via the CSS rule selector, which is a paragram – p – in our case):
p {
color: #333;
font-family: "Open Sans",sans-serif;
font-size: 14px;
font-weight: 400;
letter-spacing: 0;
line-height: 24px;
margin: 0 0 20px 0;
padding: 0 0 10px 0;}
Pasting at CSS LINT online tool again we get no warnings anymore (apart from no errors):
One might also remove the redundant space chars at the end of each line that Firefox places when copy-pasting the style declarations. Notepad++ can do it via Edit / Blank Operations / Trim Trailing Space menu command: