Jump to content


Photo

merge requests for PLi's git


  • Please log in to reply
1748 replies to this topic

Re: merge requests for PLi's git #1421 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 29 April 2020 - 19:10

Mostly in Python but also in the C++ code, in enigma2 the "de facto standard" has always been to use tabs as delimiters. Sometimes "space" die-hards added patches that introduced spaces, but most of these we already converted to "the right thing". If there are still places where tabs and spaces are mixed (evil!) they are only a handful and we need to clean them up too.

 

I don't care whether the whole world is misguided and does not understand the meaning of a delimiter in a computer program and really that it does not matter whether it indents 4 of 8 positions and really that you can set the tab width in your favourite editor yourself! And apparently most of the enigma2 developers agreed with me.

 

EDIT: this is the one and only occasion where Schimmelreiter and I agree.


Edited by Erik Slagter, 29 April 2020 - 19:10.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #1422 Dimitrij

  • PLi® Core member
  • 10,021 posts

+338
Excellent

Posted 29 April 2020 - 20:22

Mixing (one file spaces, other tabs) I don't really prefer. Maybe only if we want to move slowly to spaces. (Mixing in one file is bad and shouldn't be done).

 

I really prefer tabs. I don't understand why spaces are the standard. Doesn't make sense for me. For me as long as tabs are allowed we should use them.

Thank you for understanding.
 


GigaBlue UHD Quad 4K /Lunix3-4K/Solo 4K


Re: merge requests for PLi's git #1423 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 29 April 2020 - 21:43

Now the patch replaces >99% tabs by spaces... better replace <1% spaces by taps and that is exactly following the pep guidelines... e2 has usually tabs.... but we’re repeating here... I hope pp also reads and understands.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1424 ims

  • PLi® Core member
  • 13,625 posts

+212
Excellent

Posted 29 April 2020 - 21:47

Now the patch replaces >99% tabs by spaces... better replace <1% spaces by taps and that is exactly following the pep guidelines... e2 has usually tabs.... but we’re repeating here... I hope pp also reads and understands.

It should not be problem with script find all .py files, where line has before first valid char any space, imho.


Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #1425 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 29 April 2020 - 21:52

So pp did it with a script ;)

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1426 ims

  • PLi® Core member
  • 13,625 posts

+212
Excellent

Posted 29 April 2020 - 23:28

it will not be many files ...


Edited by ims, 29 April 2020 - 23:35.

Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #1427 WanWizard

  • PLi® Core member
  • 68,614 posts

+1,739
Excellent

Posted 30 April 2020 - 00:08

I've got a PHP script (I used for PHP files), which should work find for py files too...


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1428 ims

  • PLi® Core member
  • 13,625 posts

+212
Excellent

Posted 30 April 2020 - 01:29

I found with script cca 18 files ... in most cases is problem only in divided pars to more lines with added spaces. Example...

			self.instance.setScrollbarMode(int(
				{ "showOnDemand": 0,
				  "showAlways": 1,
				  "showNever": 2,
				}[mode]))

remove spaces and change it to this?

			self.instance.setScrollbarMode(int(
				{
				"showOnDemand": 0,
				"showAlways": 1,
				"showNever": 2,
				}[mode]))

Edited by ims, 30 April 2020 - 01:29.

Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #1429 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 30 April 2020 - 06:32

Where is pp? He tries to push it to all the others and we know eg openatv merge everything without thinking....

Edited by littlesat, 30 April 2020 - 06:33.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1430 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 30 April 2020 - 09:28

 

I found with script cca 18 files ... in most cases is problem only in divided pars to more lines with added spaces. Example...

			self.instance.setScrollbarMode(int(
				{ "showOnDemand": 0,
				  "showAlways": 1,
				  "showNever": 2,
				}[mode]))

remove spaces and change it to this?

			self.instance.setScrollbarMode(int(
				{
				"showOnDemand": 0,
				"showAlways": 1,
				"showNever": 2,
				}[mode]))

Already better indeed, but if the strings are also indented it's even better, but I am not sure if Python allows it. Or maybe it's the formatting on the forum?


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #1431 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 30 April 2020 - 09:32

BTW if you use the command line version of git, there is an option to show indentation errors (as in: mix tabs/space or leave tabs/space at the end of a line).

[color]
    ui = true
    diff = true

Before you do a commit, do git diff and you'll see the problems. Even after a commit with git show it will show the problems, you can still fix them using git commit --amend when there not pushed yet. Otherwise it will have to be another (fix) commit.


Edited by Erik Slagter, 30 April 2020 - 09:32.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #1432 ims

  • PLi® Core member
  • 13,625 posts

+212
Excellent

Posted 30 April 2020 - 09:58

 

 

I found with script cca 18 files ... in most cases is problem only in divided pars to more lines with added spaces. Example...

			self.instance.setScrollbarMode(int(
				{ "showOnDemand": 0,
				  "showAlways": 1,
				  "showNever": 2,
				}[mode]))

remove spaces and change it to this?

			self.instance.setScrollbarMode(int(
				{
				"showOnDemand": 0,
				"showAlways": 1,
				"showNever": 2,
				}[mode]))

Already better indeed, but if the strings are also indented it's even better, but I am not sure if Python allows it. Or maybe it's the formatting on the forum?

 

 

			self.instance.setScrollbarMode(int(
				{
                                        "showOnDemand": 0,
                                        "showAlways": 1,
                                        "showNever": 2,
				}[mode]))

Yes, it is possible ...

 

Btw - here is list with any spaces before text
 

Attached Files


Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #1433 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 30 April 2020 - 11:08

I suggest shorter than replace tabs by spaces... as the pep says when the common use was tabs in existing projects keep tabs it should be better to go that way...

Edited by littlesat, 30 April 2020 - 11:09.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1434 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 30 April 2020 - 11:21

Shorter is not a valid argument (as Wanwizard already explained).

 

My main issue with spaces is that a given random point in a random file, seeing an indent of 12 spaces, does that mean the indent level is 3 spaces by 4 levels or 4 spaces by 3 levels etc. Using tabs one level is always one character.

 

There are a number of other issues with spaces (like having to backspace over all of them when going back one level) but they are more or less workaroundable. Also using tabs one can configure the shift width themselves, some of use prefer a small shift width, others like a wider shift width. Using tabs, that is never an issue, your not forced to use the same as someone else.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #1435 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 30 April 2020 - 11:50

Shorter was an argument here as pep says the current project already uses tabs most times then keep tabs... with shorter I meant here the required changes... and indeed a tab is a tab and a space comes with one four eight or what else....?

Edited by littlesat, 30 April 2020 - 11:51.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1436 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 30 April 2020 - 12:18

I really don't understand the arguments of the pro-space folks.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #1437 WanWizard

  • PLi® Core member
  • 68,614 posts

+1,739
Excellent

Posted 30 April 2020 - 13:34

This article sums up the debate in the PHP community: http://paul-m-jones....er-tabs-in-php/

 

In the end, it is only about what IMS posted above, indentation and alignment of multi-line statements.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1438 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 30 April 2020 - 15:26

That is also about php... != python where tabs/spaces are important , they are replacing the {} -and- != cpp


Edited by littlesat, 30 April 2020 - 15:26.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1439 WanWizard

  • PLi® Core member
  • 68,614 posts

+1,739
Excellent

Posted 30 April 2020 - 16:56

The spaces/tabs discussion is exactly the same, it has no relation to the language used.

 

They argue that spaces should be used because the example of IMS will look incorrectly formatted if you change your tab setting.

 

Which imho is a rather weak argument. The only point I wanted to make.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1440 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 30 April 2020 - 17:02

Yes I understand the "alignment" issue, but is insignificant compared to the other arguments (I think you agree).

 

I think the point Littlesat is trying to make that compared to C, in Python the delimiter is a syntactical element, the amount of white space has implications on the way the input is interpreted. Which I think is one of the weakest points of Python anyway. Python uses all sorts of heuristics to determine whether indentation has increased, decreased or remained the same from the previous line, very ugly. One more reason to stick to tabs, where one tab is exactly one level of indent, no misinterpretation possible. 


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.



2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users