The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,869 other followers

Archive for August 20th, 2019

Some Markdown links on phrasing more difficult markdown for correct rendering

Posted by jpluimers on 2019/08/20

After blogging on Markdown notes in 2014, Markdown support has come a long way. It also means that the documents written in Markdown has become more complex, and that more tools can render it.

Given the vague aspects of many Markdown dialects, rendering can be troublesome (see my post Babelmark 2 online Markdown checker), so below are some links on some aspects I had trouble with getting right.

Note that there are two markdown linters:

Sometimes, issues are present in one, but not in the other; see:

The command line interface to the Ruby version is easier to install than the JavaScript version as everything is in one gem: mdl, unlike the npm, where the cli is in markdown-cli and the library in markdownlint.

–jeroen

Related:

Read the rest of this entry »

Posted in *nix, *nix-tools, Development, Lightweight markup language, MarkDown, pandoc document converter, Power User, Ruby, Software Development | Leave a Comment »

Python line continuation: only use backslash if it gives cleaner code

Posted by jpluimers on 2019/08/20

Since Python is a [WayBack] line-oriented programming language, sometimes you want to wrap longer lines into more readable shorter ones.

Many people struggle with this, see for instance these questions (and excellent answers!):

This struggle is likely why it made it to the [WayBack] style guide. Relevant sections are below.

I had this struggle wile passing multiple parameters to a method creating a very long line, but found I did not need a line continuation as the Python language understands this construct perfectly fine:

    threadManager.append(
        UrlMonitorThread(monitor, "http://%s" % targetHost),
        SmtpMonitorThread(monitor, targetHost, 25),
        SmtpMonitorThread(monitor, targetHost, 587),
        SshMonitorThread(monitor, targetHost, 22))

You could use the line continuation backslash to do this, but often that is not needed or a better way exists (for instance wrapping an expression in parentheses), so here are are the relevant style guide sections:

Code lay-out

Indentation

Use 4 spaces per indentation level.

Continuation lines should align wrapped elements either vertically using Python’s implicit line joining inside parentheses, brackets and braces, or using a hanging indent[7]. When using a hanging indent the following should be considered; there should be no arguments on the first line and further indentation should be used to clearly distinguish itself as a continuation line.

…

Maximum Line Length

Limit all lines to a maximum of 79 characters.

For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters.

Limiting the required editor window width makes it possible to have several files open side-by-side, and works well when using code review tools that present the two versions in adjacent columns.

…

The preferred way of wrapping long lines is by using Python’s implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation.

Backslashes may still be appropriate at times. For example, long, multiple with-statements cannot use implicit continuation, so backslashes are acceptable:

with open('/path/to/some/file/you/want/to/read') as file_1, \
     open('/path/to/some/file/being/written', 'w') as file_2:
    file_2.write(file_1.read())

…

Make sure to indent the continued line appropriately.

Should a line break before or after a binary operator?

For decades the recommended style was to break after binary operators. But this can hurt readability in two ways: the operators tend to get scattered across different columns on the screen, and each operator is moved away from its operand and onto the previous line. Here, the eye has to do extra work to tell which items are added and which are subtracted:

…



To solve this readability problem, mathematicians and their publishers follow the opposite convention. Donald Knuth explains the traditional rule in his Computers and Typesetting series: “Although formulas within a paragraph always break after binary operations and relations, displayed formulas always break before binary operations” [3].


Following the tradition from mathematics usually results in more readable code:


# Yes: easy to match operators with operands
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)



In Python code, it is permissible to break before or after a binary operator, as long as the convention is consistent locally. For new code Knuth’s style is suggested.








–jeroen

				

				
			
Posted in Development, Python, Scripting, Software Development |    Leave a Comment »

		


			

			
… compare two JSON structures and pin-point … the differences – – Nicholas Ring – Google+


			
Posted by jpluimers on 2019/08/20


				

					
I’ve added a few WayBack/Archive.is links to the interesting comments by Zoë Peterson from Scooter Software (of Beyond Compare fame) at [WayBack] … compare two JSON structures and pin-point … the differences – – Nicholas Ring – Google+:


Beyond Compare 4 has an optional “JSON sorted” file format that uses jq to pretty print and sort JSON data before comparing it. It’s not included out of the box yet, but you can get a copy here:


If you’re interested in an actual algorithm and not just an app, I don’t have a suggestion handy, but could dig one up. Tree alignment is more complicated than sequence alignment and we did do research into it, but it was quite a few years ago and didn’t get incorporated into BC. XML alignment algorithms were being actively researched back in the aughts and they should trivially transfer to JSON.

…


It looks like our research mostly ended around 2002, and I wasn’t personally involved in it, so I don’t know how helpful this will be, but here’s what I have:





The general idea in the thread is that JSON – though not as formalised as XML – does have structure, so if you can normalise it, then XML ways of differencing should work.


Normalisation also means that you need to normalise any floating point, date time, escaping, quoting, etc. Maybe not for the faint of heart.


–jeroen

				

				
			
Posted in *nix, *nix-tools, Beyond Compare, Development, diff, JavaScript/ECMAScript, jq, JSON, Power User, Scripting, Software Development, XML, XML/XSD |    Leave a Comment »

		


	
	

		

		

	


	






 











	

		

	

	

	

	

	

	

	

	

	

	

	

	
	


	


	
							
						
						

			
			
						
								
		






	
	

		

			%d bloggers like this: