Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #42852 > unrolled thread

I hate you all

Back to article view | Back to comp.lang.python

Contents

  I hate you all terminatorul@gmail.com - 2013-04-05 14:41 -0700
    Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-06 08:53 +1100
    Re: I hate you all John Gordon <gordon@panix.com> - 2013-04-05 21:55 +0000
      Re: I hate you all terminatorul@gmail.com - 2013-04-05 15:04 -0700
        Re: I hate you all Andrew Berg <bahamutzero8825@gmail.com> - 2013-04-05 17:28 -0500
        Re: I hate you all Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-05 16:42 -0600
          Re: I hate you all terminatorul@gmail.com - 2013-04-05 17:22 -0700
            Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-06 11:35 +1100
              Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 08:07 +0300
                Re: I hate you all Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-04-05 22:28 -0700
                Re: I hate you all Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-05 23:53 -0600
                  Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 09:56 +0300
                    Re: I hate you all Joshua Landau <joshua.landau.ws@gmail.com> - 2013-04-06 11:17 +0100
                      Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 17:22 +0300
                        Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-06 15:30 +0000
                        Re: I hate you all Roland Koebler <r.koebler@yahoo.de> - 2013-04-08 00:52 +0200
                Re: I hate you all Michael Torrie <torriem@gmail.com> - 2013-04-05 23:59 -0600
                  Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-06 06:19 +0000
                Re: I hate you all Michael Torrie <torriem@gmail.com> - 2013-04-05 23:49 -0600
            Re: I hate you all Andrew Berg <bahamutzero8825@gmail.com> - 2013-04-05 19:50 -0500
            Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-06 02:07 +0000
            Re: I hate you all Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-05 21:53 -0600
              Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 08:36 +0300
                Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-06 16:44 +1100
                Re: I hate you all Michael Torrie <torriem@gmail.com> - 2013-04-05 23:58 -0600
                  Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 10:07 +0300
                Re: I hate you all Ethan Furman <ethan@stoneleaf.us> - 2013-04-05 23:00 -0700
                  Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-06 15:37 +0000
                    Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 11:49 -0400
                Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-06 06:55 +0000
                Re: I hate you all Larry Hudson <orgnut@yahoo.com> - 2013-04-06 13:17 -0700
                  Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-07 14:37 +0300
              Re: I hate you all Nobody <nobody@nowhere.com> - 2013-04-06 14:52 +0100
                Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-07 01:20 +1100
                  Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 17:37 +0300
                  Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 11:01 -0400
                    Re: I hate you all Neil Cerutti <neilc@norwich.edu> - 2013-04-06 15:15 +0000
                      Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-06 15:41 +0000
                        Re: I hate you all rusi <rustompmody@gmail.com> - 2013-04-06 09:00 -0700
                      Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 11:59 -0400
                        Re: I hate you all Neil Cerutti <neilc@norwich.edu> - 2013-04-06 18:48 +0000
                    Re: I hate you all rusi <rustompmody@gmail.com> - 2013-04-06 08:31 -0700
                    Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-07 07:29 +1000
                    Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 01:38 +0000
                  Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 01:30 +0000
                    Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 22:15 -0400
                    Re: I hate you all Jason Friedman <jsf80238@gmail.com> - 2013-04-06 20:42 -0600
                    Re: I hate you all Nobody <nobody@nowhere.com> - 2013-04-08 19:43 +0100
                      Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-08 19:48 +0000
                        Re: I hate you all Walter Hurry <walterhurry@lavabit.com> - 2013-04-08 21:25 +0000
                          Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-08 21:29 +0000
                            Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-09 08:00 +1000
                              Re: I hate you all Walter Hurry <walterhurry@lavabit.com> - 2013-04-08 22:51 +0000
                                Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-09 08:57 +1000
                                Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-09 09:33 +0100
                                  Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-09 13:39 +0000
                                    Re: I hate you all Tim Chase <python.list@tim.thechases.com> - 2013-04-09 09:17 -0500
                                    Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-10 00:20 +1000
                                    Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-09 16:51 +0100
                                      Re: I hate you all Walter Hurry <walterhurry@lavabit.com> - 2013-04-09 21:09 +0000
                                        Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-09 23:09 +0100
                                          Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-09 23:21 +0000
                                            Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-10 09:28 +1000
                                              Re: I hate you all Walter Hurry <walterhurry@lavabit.com> - 2013-04-09 23:50 +0000
                                                Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-10 10:31 +1000
                                                  Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-10 02:00 +0000
                                                    Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-10 12:14 +1000
                                            Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-10 00:39 +0100
                                            Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-10 00:41 +0100
                                      Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-09 21:43 +0000
                      Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-09 02:51 +0000
                        Re: I hate you all rusi <rustompmody@gmail.com> - 2013-04-08 21:06 -0700
                          Re: I hate you all rusi <rustompmody@gmail.com> - 2013-04-08 21:52 -0700
                          Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-09 05:19 +0000
            Re: I hate you all "Günther Dietrich" <gd.usenet@spamfence.net> - 2013-04-06 14:55 +0200
          Re: I hate you all terminatorul@gmail.com - 2013-04-05 17:22 -0700
        Re: I hate you all Isaac To <isaac.to@gmail.com> - 2013-04-06 06:35 +0800
        Re: I hate you all Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-05 17:00 -0600
    Re: I hate you all Dylan Evans <dylan@dje.me> - 2013-04-06 14:28 +1000
      Re: I hate you all terminatorul@gmail.com - 2013-04-05 22:13 -0700
        Re: I hate you all Dylan Evans <dylan@dje.me> - 2013-04-07 13:00 +1000
          Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-07 14:44 +0300
            Re: I hate you all Ethan Furman <ethan@stoneleaf.us> - 2013-04-07 11:12 -0700
              Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-07 14:33 -0400
      Re: I hate you all terminatorul@gmail.com - 2013-04-05 22:13 -0700
    Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-06 15:27 +0000
      Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 11:58 -0400
    Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-07 19:25 +0100

Page 1 of 5  [1] 2 3 4 5  Next page →

#42852 — I hate you all

Hello

I just tried python 3.3 with some simple script meant for unit test.

How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not !

I know people have all goten into this frenzy of using either tabs, either spaces for indentation, but using a hard-tab of 8 spaces and a soft tab of 4 spaces has worked fine long before python 3 showed up.

And if they decided to throw a TabError, they should have at least created an option to specify tab size, so I can work around that.

I am aware that so many editors use a tab stop of 4 spaces instead of 8 (which by the way started as a cheap way to work around their initial lack of a "soft tab stop" option, and then was kept at 4 for "compatibility"). But the rest of us who always use a tab stop of 8 should not be forced to change preferences because python reached version 3.

Timothy Madden

[toc] | [next] | [standalone]

#42853

On Sat, Apr 6, 2013 at 8:41 AM,  <terminatorul@gmail.com> wrote:
> Hello
>
> I just tried python 3.3 with some simple script meant for unit test.
>
> How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not !

It is. As long as you're consistent, you can use tabs or spaces
without problems.

You're also most welcome to continue using Python 3.2, or 2.1, or 0.1
(if you're Steven D'Aprano), which might have the semantics you want.

And hey, if you dig into the source, I'm sure you could find how to
make it configurable.

ChrisA

[toc] | [prev] | [next] | [standalone]

#42854

In <64d4fb7c-6a75-4b5f-b5c8-06a4b2b5d0cb@googlegroups.com> terminatorul@gmail.com writes:

> How can python authors be so arrogant to impose their tabs and spaces
> options on me ? It should be my choice if I want to use tabs or not !

You are free to use tabs, but you must be consistent.  You can't mix
tabs and spaces for lines of code at the same indentation level.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#42855

On Saturday, April 6, 2013 12:55:29 AM UTC+3, John Gordon wrote:
> In <64d4fb7c-6a75-4b5f-b5c8-06a4b2b5d0cb@googlegroups.com> terminatorul@gmail.com writes:
> 
> > How can python authors be so arrogant to impose their tabs and spaces
> > options on me ? It should be my choice if I want to use tabs or not !
> 
> You are free to use tabs, but you must be consistent.  You can't mix
> tabs and spaces for lines of code at the same indentation level.

They say so, but python does not work that way. This is a simple script:

from unittest import TestCase

class SvnExternalCmdTests(TestCase) :
    def test_parse_svn_external(self) :
	for sample_external in sample_svn_externals :
	    self.assertEqual(parse_svn_externals(sample_external[0][0], sample_external[0][1]), [ sample_external[1] ])

And at the `for` statement at line 5 I get:

C:\Documents and Settings\Adrian\Projects>python sample-py3.py
  File "sample-py3.py", line 5
    for sample_external in sample_svn_externals :
                                                ^
TabError: inconsistent use of tabs and spaces in indentation


Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ?

You can try the script as it is, and see python 3.3 will not run it

[toc] | [prev] | [next] | [standalone]

#42858

On 2013.04.05 17:04, terminatorul@gmail.com wrote:
> Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ?
The first indent level is done with spaces on the second line (for def)
and then with a tab on the third (and another tab to indent again).
Remember that your for loop is inside the class definition.
-- 
CPython 3.3.0 | Windows NT 6.2.9200 / FreeBSD 9.1

[toc] | [prev] | [next] | [standalone]

#42860

On Fri, Apr 5, 2013 at 4:04 PM,  <terminatorul@gmail.com> wrote:
> They say so, but python does not work that way. This is a simple script:
>
> from unittest import TestCase
>
> class SvnExternalCmdTests(TestCase) :
>     def test_parse_svn_external(self) :
>         for sample_external in sample_svn_externals :
>             self.assertEqual(parse_svn_externals(sample_external[0][0], sample_external[0][1]), [ sample_external[1] ])
>
> And at the `for` statement at line 5 I get:
>
> C:\Documents and Settings\Adrian\Projects>python sample-py3.py
>   File "sample-py3.py", line 5
>     for sample_external in sample_svn_externals :
>                                                 ^
> TabError: inconsistent use of tabs and spaces in indentation
>
>
> Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ?

The "def" line has four spaces.  The "for" line then has a hard tab.
This is ambiguous.  If the hard tab is assumed to have a width of four
spaces, then they are at the same indentation level.  If it is assumed
to have a width of eight spaces, then they are not.

Python 2 resolved this ambiguity by assuming that a hard tab was
simply equivalent to four or eight spaces (I don't remember which).
The problem with assuming this is that the assumption made by Python
does not necessarily match the tab width selected by the user, with
the result that lines that *look* like they are at the same
indentation level might actually be different (and vice-versa),
leading to hard-to-find bugs.

Python 3 instead resolves this ambiguity by not allowing it.

In the code above, because the "def" line has four spaces, the
indentation of the "for" line that is subordinate to it needs to also
start with four spaces (and then you can continue the indentation with
tabs or spaces as you prefer).  Because the line after the "for" line
is subordinate to it, it also then needs to begin with the same exact
indentation used by the "for" line (in the sample provided, it
currently does).

My suggestion: choose to use either all tabs or all spaces within a
file, and then you won't have this problem.

[toc] | [prev] | [next] | [standalone]

#42867

On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote:
[...]
> The "def" line has four spaces.  The "for" line then has a hard tab.
> This is ambiguous.  If the hard tab is assumed to have a width of four
> spaces, then they are at the same indentation level.  If it is assumed
> to have a width of eight spaces, then they are not.
[...]

The correct tab stop positions have always been at 8 character columns apart.
The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.

And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

Thank you,
Timothy Madden

[toc] | [prev] | [next] | [standalone]

#42870

On Sat, Apr 6, 2013 at 11:22 AM,  <terminatorul@gmail.com> wrote:
> On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote:
> [...]
>> The "def" line has four spaces.  The "for" line then has a hard tab.
>> This is ambiguous.  If the hard tab is assumed to have a width of four
>> spaces, then they are at the same indentation level.  If it is assumed
>> to have a width of eight spaces, then they are not.
> [...]
>
> The correct tab stop positions have always been at 8 character columns apart.
> The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.
>
> And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

If you're indenting four spaces per level, then indent four spaces per
level. The code you posted would work perfectly if the indentation is
four spaces, then eight spaces, then twelve spaces. The problem is
that you have a stupid editor that's enforcing tabs instead of certain
multiples of spaces - get one that'll keep them all as spaces and you
won't have a problem.

Or use actual tabs, and set the displayed tab width to whatever you
feel like. That works, too. Neither option causes any problems with
any sane tools.

ChrisA

[toc] | [prev] | [next] | [standalone]

#42885

On 06.04.2013 03:35, Chris Angelico wrote:
> On Sat, Apr 6, 2013 at 11:22 AM,  <terminatorul@gmail.com> wrote:
>> On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote:
>> [...]
>>> The "def" line has four spaces.  The "for" line then has a hard tab.
>>> This is ambiguous.  If the hard tab is assumed to have a width of four
>>> spaces, then they are at the same indentation level.  If it is assumed
>>> to have a width of eight spaces, then they are not.
>> [...]
>>
>> The correct tab stop positions have always been at 8 character columns apart.
>> The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.
>>
>> And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.
>
> If you're indenting four spaces per level, then indent four spaces per
> level. The code you posted would work perfectly if the indentation is
> four spaces, then eight spaces, then twelve spaces. The problem is
> that you have a stupid editor that's enforcing tabs instead of certain
> multiples of spaces - get one that'll keep them all as spaces and you
> won't have a problem.

My editor is not the problem, of course, this is about what I think is 
right. I think I should be given the option to use tabs as I always 
have, and at least to use them with the default tab size, as python 2 
used to.

> Or use actual tabs, and set the displayed tab width to whatever you
> feel like. That works, too. Neither option causes any problems with
> any sane tools.

Well this is the problem, the tab size is not "whatever I like", tab 
stops are 8 character columns apart (default).

Changing the tab size from this default is what makes the code 
incompatible, not the tabs themselves. So the solution is simple: do not 
change tab size from the default.

People say I can use tabs all the way, just set them to the indent I want.

Well, I always had my indent independent of the tab size. Which is the 
way it should be, after all, since one can indent with or without tabs, 
so indent should not be tied to them.

But now I can not; python no longer lets me do that.

Tab size should be 8, so now python 3 says: either indent at 8 with 
tabs, either drop tabs and indent with spaces (just the same as if tabs 
are not allowed).

But that is so wrong. I can indent at 4 (or any value), and still use 
tabs, as long as the interpreter knows tab stops are 8 columns apart. 
There is no "ambiguity" and no way to change the meaning of the code.

So as a comparison we have:

  - the good old rules
	- python has use the default tab stops of 8 columns
	- indent is independent of tab stops

  - the new rules
	- python is independent of the tab stops
	- indent is now tied to the tab stop, so users have to :
		- use non-default tab size (8 is too much), or
		- drop tabs altogether

The new rules may look flexible at first sight, but the net effect they 
have is they push me to use non-default tab size (which is not good), or 
drop the tabs, which I could have used before python 3 just fine.

Thank you,
Timothy Madden

[toc] | [prev] | [next] | [standalone]

#42887

On Fri, Apr 5, 2013 at 10:07 PM, Timothy Madden <terminatorul@gmail.com> wrote:
>
> On 06.04.2013 03:35, Chris Angelico wrote:
>>
>> On Sat, Apr 6, 2013 at 11:22 AM,  <terminatorul@gmail.com> wrote:
>>>
>>> On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote:
>>> [...]
>>>>
>>>> The "def" line has four spaces.  The "for" line then has a hard tab.
>>>> This is ambiguous.  If the hard tab is assumed to have a width of four
>>>> spaces, then they are at the same indentation level.  If it is assumed
>>>> to have a width of eight spaces, then they are not.
>>>
>>> [...]
>>>
>>> The correct tab stop positions have always been at 8 character columns apart.
>>> The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.
>>>
>>> And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.
>>
>>
>> If you're indenting four spaces per level, then indent four spaces per
>> level. The code you posted would work perfectly if the indentation is
>> four spaces, then eight spaces, then twelve spaces. The problem is
>> that you have a stupid editor that's enforcing tabs instead of certain
>> multiples of spaces - get one that'll keep them all as spaces and you
>> won't have a problem.
>
>
> My editor is not the problem, of course, this is about what I think is right. I think I should be given the option to use tabs as I always have, and at least to use them with the default tab size, as python 2 used to.
>
>
>> Or use actual tabs, and set the displayed tab width to whatever you
>> feel like. That works, too. Neither option causes any problems with
>> any sane tools.
>
>
> Well this is the problem, the tab size is not "whatever I like", tab stops are 8 character columns apart (default).
>
> Changing the tab size from this default is what makes the code incompatible, not the tabs themselves. So the solution is simple: do not change tab size from the default.
>
> People say I can use tabs all the way, just set them to the indent I want.
>
> Well, I always had my indent independent of the tab size. Which is the way it should be, after all, since one can indent with or without tabs, so indent should not be tied to them.
>
> But now I can not; python no longer lets me do that.
>
> Tab size should be 8, so now python 3 says: either indent at 8 with tabs, either drop tabs and indent with spaces (just the same as if tabs are not allowed).
>
> But that is so wrong. I can indent at 4 (or any value), and still use tabs, as long as the interpreter knows tab stops are 8 columns apart. There is no "ambiguity" and no way to change the meaning of the code.
>
> So as a comparison we have:
>
>  - the good old rules
>         - python has use the default tab stops of 8 columns
>         - indent is independent of tab stops
>
>  - the new rules
>         - python is independent of the tab stops
>         - indent is now tied to the tab stop, so users have to :
>                 - use non-default tab size (8 is too much), or
>                 - drop tabs altogether
>
> The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), or drop the tabs, which I could have used before python 3 just fine.
>
>
> Thank you,
> Timothy Madden

http://www.xkcd.com/1172/

[toc] | [prev] | [next] | [standalone]

#42891

On Fri, Apr 5, 2013 at 11:07 PM, Timothy Madden <terminatorul@gmail.com> wrote:
> Changing the tab size from this default is what makes the code incompatible,
> not the tabs themselves. So the solution is simple: do not change tab size
> from the default.

So in other words, everybody must be forced to use 8-character tabs
because you want to be able to mix tabs and spaces.

> People say I can use tabs all the way, just set them to the indent I want.
>
> Well, I always had my indent independent of the tab size. Which is the way
> it should be, after all, since one can indent with or without tabs, so
> indent should not be tied to them.
>
> But now I can not; python no longer lets me do that.

Honestly, I really don't understand why you *want* to do that.  If
your indentation is 4 characters, then that would be the natural tab
width to use.  If you're not going to tie your indent to your tabs,
then why even use tabs in the first place?

> The new rules may look flexible at first sight, but the net effect they have
> is they push me to use non-default tab size (which is not good),

What makes that not good?  There is no law anywhere that says tabs are
8 characters.  That's just an arbitrary amount that looked appropriate
to the people designing the first teletypes.

[toc] | [prev] | [next] | [standalone]

#42899

On 06.04.2013 08:53, Ian Kelly wrote:
> On Fri, Apr 5, 2013 at 11:07 PM, Timothy Madden <terminatorul@gmail.com> wrote:
[...]
> So in other words, everybody must be forced to use 8-character tabs
> because you want to be able to mix tabs and spaces.
>
>> People say I can use tabs all the way, just set them to the indent I want.
>>
>> Well, I always had my indent independent of the tab size. Which is the way
>> it should be, after all, since one can indent with or without tabs, so
>> indent should not be tied to them.
>>
>> But now I can not; python no longer lets me do that.
>
> Honestly, I really don't understand why you *want* to do that.  If
> your indentation is 4 characters, then that would be the natural tab
> width to use.  If you're not going to tie your indent to your tabs,
> then why even use tabs in the first place?
>
>> The new rules may look flexible at first sight, but the net effect they have
>> is they push me to use non-default tab size (which is not good),
>
> What makes that not good?  There is no law anywhere that says tabs are
> 8 characters.  That's just an arbitrary amount that looked appropriate
> to the people designing the first teletypes.

I am aware that 7 bytes per tab character (or 14/28, in UTF-16, UTF-32!) 
will not justify the time spent debating.

The reason I want to use tabs is that I think there is nothing wrong 
with them.

The reason why everybody should use 8-character tabs is so that I and 
the rest of the world can use `grep` / `findstr` on their code, and 
still see lines of code properly aligned in the terminal. Or to be able 
to print fragments of code as plain text only, and get the proper alignment.

But most importantly, the reason that tab size should be 8 is so that 
all of us people in this world can freely exchange formatted text like 
source code without having to first consider if "will it look the same 
in their editor ? What tab size do they use ?"

In other words, the solution to "different people's definition of tabs" 
is not to drop them, but only to get a common default. Which is already 
there: 8 columns between every tab stop.

What python 3 does is a different attitude, and that is:

everyone likes their own indent. Although I personally find it annoying, 
I am aware that many people use an indent of 2 spaces, some use even 3. 
Moreover, many C programers still like 8 spaces per indent.

So some development environments find it an advantage to use tabs only 
for indentation, and every programmer is then free to set the tab stop 
to their liking. Everyone will see the indent they like, with no changes 
in the byte stream for the file.

Why I think this is wrong is a little difficult for me explain. First, I 
admit this approach toward tabs has some value and is tempting for me, 
too. But it assumes everything, everywhere can configure tab sizes. 
Consoles and printers usually do not. Next, even if they can, most 
people, including all non-technical personal, never bother to change 
settings. Then this also assumes I change settings to my liking on 
several computers I use (maybe I work for several clients each with 
their computers, most people have a work computer and a home computer, 
maybe also a laptop and a tablet/smart device). Last, this is also not 
helpful if two sometimes use the same computer from time to time, and do 
not want to switch users all the time.

So this is not a very good approach, and I have the feeling that most 
python programmers and development environment prefer to use only spaces 
than to use variable tab sizes.

So the right solution remains a proper default setting for the tab size, 
and then we no longer have to drop tabs from source code files.

Thank you,
Timothy Madden

[toc] | [prev] | [next] | [standalone]

#42904

[Multipart message — attachments visible in raw view] — view raw

On 6 April 2013 07:56, Timothy Madden <terminatorul@gmail.com> wrote:

> On 06.04.2013 08:53, Ian Kelly wrote:
>
>> On Fri, Apr 5, 2013 at 11:07 PM, Timothy Madden <terminatorul@gmail.com>
>> wrote:
>>
> [...]
>
>> So in other words, everybody must be forced to use 8-character tabs
>> because you want to be able to mix tabs and spaces.
>>
>>  People say I can use tabs all the way, just set them to the indent I
>>> want.
>>>
>>> Well, I always had my indent independent of the tab size. Which is the
>>> way
>>> it should be, after all, since one can indent with or without tabs, so
>>> indent should not be tied to them.
>>>
>>> But now I can not; python no longer lets me do that.
>>>
>>
>> Honestly, I really don't understand why you *want* to do that.  If
>> your indentation is 4 characters, then that would be the natural tab
>> width to use.  If you're not going to tie your indent to your tabs,
>> then why even use tabs in the first place?
>>
>>  The new rules may look flexible at first sight, but the net effect they
>>> have
>>> is they push me to use non-default tab size (which is not good),
>>>
>>
>> What makes that not good?  There is no law anywhere that says tabs are
>> 8 characters.  That's just an arbitrary amount that looked appropriate
>> to the people designing the first teletypes.
>>
>
> I am aware that 7 bytes per tab character (or 14/28, in UTF-16, UTF-32!)
> will not justify the time spent debating.
>
> The reason I want to use tabs is that I think there is nothing wrong with
> them.
>

So use them


> The reason why everybody should use 8-character tabs is so that I and the
> rest of the world can use `grep` / `findstr` on their code, and still see
> lines of code properly aligned in the terminal. Or to be able to print
> fragments of code as plain text only, and get the proper alignment.
>

Oh thanks. I liked using my four character tabs, but I guess you *are* so
important that I'm going to have to change everything I do just for you.
It's obviously not good enough for you just to not mix tabs and spaces so
that we can both enjoy ourselves because that would make *you*, the holiest
of all, have to put some effort in. No, I totally understand and will now
go and change everything after Python is changed to break hundreds of files
of codes for you.


> But most importantly, the reason that tab size should be 8 is so that all
> of us people in this world can freely exchange formatted text like source
> code without having to first consider if "will it look the same in their
> editor ? What tab size do they use ?"
>

Hrm. Hrm. Hrrrrmmm.

Hrrrrmmmm.

No, you're right: spaces are totally not for this in any way and that
no-one has ever made this point before and who the hell cares if you're
reading code with a different indent size anyway it's not like it affects
the actual code.

Yours frustratedly,

Joshua Landau

----------------------------------------------------------------------------------------------------------------

But seriously, please at least look like you've read other people's posts.
It doesn't matter what tabstop you use as long as you don't mix. If your
code depends on tab size then it's categorically wrong. Other people's tab
sizes are as valid. I use tabs because of the variation it lets me have - I
can switch tab sizes on the fly - and it's faster on "dumb" editors. So let
me do that.

But let us assume we were going to standardise on TAB == 8 SPACES. It would
*still* be bad to mix tabs and spaces. Hence you'd change Python in exactly
0 ways. So *what do you want from us*?

[toc] | [prev] | [next] | [standalone]

#42913

On 06.04.2013 13:17, Joshua Landau wrote:
[...]
>
> Yours frustratedly,
>
> Joshua Landau
>
> ----------------------------------------------------------------------------------------------------------------
>
> But seriously, please at least look like you've read other people's
> posts. It doesn't matter what tabstop you use as long as you don't mix.

When the default tab size is 8, than tab size does matter.

Because it is too much to use as indent size. If you still want to use 
tabs, you are now supposed to change tab size from the default. I 
believe using non-default tab size in a public environment like 
open-source code is bound to cause formatting problems for someone at 
some point.

> If your code depends on tab size then it's categorically wrong. Other
> people's tab sizes are as valid. I use tabs because of the variation it
> lets me have - I can switch tab sizes on the fly - and it's faster on
> "dumb" editors. So let me do that.
>
> But let us assume we were going to standardise on TAB == 8 SPACES. It
> would *still* be bad to mix tabs and spaces. Hence you'd change Python
> in exactly 0 ways. So *what do you want from us*?

Well all previous (python 2) code is meant to work for a tab size of 8. 
You may call this "categorically wrong", but it has been there a long 
while, is is still in use, and it sticks to the default.

Spaces-only can achieve compatibility between different people settings 
for formatted text like source code. But so does a common default for 
the tab size, and with that we do not have to limit ourselves to spaces 
only.

Now I understand python 3 people may already use tabs with a size of 4, 
as you said. Although I tried to show this is not good practice, (and 
that not many people do that, really, since most of them prefer to use 
all-spaces instead), still I do not expect the people to change their 
settings.

What I would expect is some option in python to make tabs work the way 
they used to. I want a choice for me to preserve my settings, the same 
way you want to preserve yours.

What I want should not be much to ask, since this is how python 2 used 
to do things.

I admit such a '--fixed-tabs' option, that will make tab stops be 8 
columns apart, and allow any number of spaces like in python 2, makes 
the code I write dependent on that option.

But the option will run all code written for the new "python 3 way", and 
brings back some compatibility, so it is not that bad. And some people 
might actually want it.

Timothy Madden

[toc] | [prev] | [next] | [standalone]

#42921

On 2013-04-06, Timothy Madden <terminatorul@gmail.com> wrote:

> When the default tab size is 8, than tab size does matter.

There is no default size.  The size of a tab isn't even constant
across a line -- they're individually adjustable.  The tabs "default" 
to wherever they were left by the last person who used the typewriter.

All assumptions about the size or predictabilty of tabs are erroneous.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#43030

Hi,

> Well all previous (python 2) code is meant to work for a tab size of
> 8.
yes, but even in Python 2, mixing spaces and tabs is considered bad
style and should be avoided. And code-checkers like pylint (which I
can recommend to everyone) create a warning.

> You may call this "categorically wrong", but it has been there a
> long while, is is still in use, and it sticks to the default.
As I said, mixing tabs and spaces for indentation was *always* a bad
idea, and is discouraged also in Python 2.

> Spaces-only can achieve compatibility between different people
> settings for formatted text like source code. But so does a common
> default for the tab size,
But there's no such thing as "default tab size". Configuring the
tab-size is quite common among programmers.


But why do you insist on using tabs at all? The best way -- in my
opinion -- is to use the tab- and backspace-key for indentation, and
let the editor convert it to spaces. (And use some tool to convert
all tabs in the old code.)

I don't see *any* advantage of mixed spaces and tabs, but quite some
disadvantages/problems.

> What I would expect is some option in python to make tabs work the
> way they used to. I want a choice for me to preserve my settings,
> the same way you want to preserve yours.
>
> What I want should not be much to ask, since this is how python 2
> used to do things.
> 
> I admit such a '--fixed-tabs' option, that will make tab stops be 8
> columns apart, and allow any number of spaces like in python 2,
> makes the code I write dependent on that option.
There's no need to add this to Python 3, since you already have what
you want. Simply use:

expand yourscript.py | python3


regards
Roland

[toc] | [prev] | [next] | [standalone]

#42893

On 04/05/2013 11:53 PM, Ian Kelly wrote:
>> The new rules may look flexible at first sight, but the net effect they have
>> is they push me to use non-default tab size (which is not good),
> 
> What makes that not good?  There is no law anywhere that says tabs are
> 8 characters.  That's just an arbitrary amount that looked appropriate
> to the people designing the first teletypes.

Ahh but assuming tabs are the equivalent of 8 spaces can save 7 bytes
per tab character in the source code!  Think of the savings.

[toc] | [prev] | [next] | [standalone]

#42894

On Fri, 05 Apr 2013 23:59:18 -0600, Michael Torrie wrote:

> On 04/05/2013 11:53 PM, Ian Kelly wrote:
>>> The new rules may look flexible at first sight, but the net effect
>>> they have is they push me to use non-default tab size (which is not
>>> good),
>> 
>> What makes that not good?  There is no law anywhere that says tabs are
>> 8 characters.  That's just an arbitrary amount that looked appropriate
>> to the people designing the first teletypes.
> 
> Ahh but assuming tabs are the equivalent of 8 spaces can save 7 bytes
> per tab character in the source code!  Think of the savings.

If we standardize on 1025 spaces per indent, and use tabs, we can save 
1KiB per indent. Let's see now... looking at a typical piece of code in 
my code base, I make it that the average line of code is indented about 
1.75 levels. (I use a lot of top-level functions, and few classes). With 
an average line length of 50 characters, plus indentation, we can reduce 
the size of a typical Python module by ninety-seven percent!

Of course, what we save in disk space, we lose in monitor size, but I'm 
sure that the price of 300 inch monitors will soon become quite 
affordable.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#42895

On 04/05/2013 11:28 PM, Benjamin Kaplan wrote:
> http://www.xkcd.com/1172/

How did I ever miss this before?  That is truly awesome.

[toc] | [prev] | [next] | [standalone]

#42872

On 2013.04.05 19:22, terminatorul@gmail.com wrote:
> And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.
Python (at least Python 3) has no concept of tab size. A tab is one
character, and how an editor or terminal or whatever chooses to display
it has nothing to do with Python. If you want to convert tabs to a
specific number of spaces or vice versa, there are multiple tools out
there you can use. In fact, many editors have the functionality built in.

Use all tabs or use all spaces. Any editor that isn't broken will let
you do either without problems.
-- 
CPython 3.3.0 | Windows NT 6.2.9200 / FreeBSD 9.1

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web