I hate you all

[Grant Edwards]

Python 3 broke a lot of things. Pull on your big-boy underwear and
deal with it.

Python 3 requires that you wear _underwear_?

That seems entirely arbitrary, and violates the god-given rights of
telecommuters to write code wearing nothing but a bathrobe!

Hell, for all I know, there may be people who go into the office
without underwear. Though I think the lonely, unbathed, unshaven,
robe-wearing telecommuter will be the poster-child for the worldwide
campaign against the undwearist fascists trying to impose their
sartorial dictates on Python users. Next, we need to pick a song...

 

[Grant Edwards]

Bjarne Stroustrup likes it, and I agree with him that code is
even easier to read that way, especially in hard-copy.

I'd have to disagree. There are too many times when things are easier
to read/maintain by visually aligning columns:

* struct/array initializers

* constant definitions

* parallel/identical operations on multiple different variables

* vertical alignment of a parameter lists in multi-line function calls

 

[Roy Smith]

Python 3 requires that you wear _underwear_?

Only at PyCon.

 

[Roy Smith]

[Mad that in 3.3 you can no longer use ambiguous mixtures of spaces
and tabs within a single indent level.]

My boss would refer to this as a failure to be "bug-compatible" with
the previous version.

Whether or not to maintain bug-compatibility when you bring out a new
version is one of the eternal debates. No matter what you do, it's
going to annoy somebody...

I remember the first VAX was got. We used some third-party serial card
because it cost a small fraction of the official DEC version. We had
all sorts of trouble with it. Eventually it turned out that the
third-party card was operating correctly according to the DEC specs, but
the driver had been written to work against genuine DEC hardware, which
didn't follow their own published spec!

I vaguely remember it had to do with how the DMA processor dealt with
odd-sized block transfers. As I recall, there was a software patch to
the driver which allowed it to work with the correctly implemented
hardware, but I could be messing up most of the details.

Great machine, that VAX. For only $100k, three or four people could
play rogue at the same time!

 

[Roy Smith]

Bjarne Stroustrup likes it

This is supposed to impress me?

Yeah, most of the books I recall that used this were C++ books.

 

[rusi]

I'd have to disagree. ?There are too many times when things are easier
to read/maintain by visually aligning columns:

?* struct/array initializers

?* constant definitions

?* parallel/identical operations on multiple different variables

?* vertical alignment of a parameter lists in multi-line function calls

I believe that it is at least possible to wish for the best of all
worlds.
http://nickgravgaard.com/elastictabstops/ (browser needs java)

Pragmatically I continue to use emacs with a fixed-width font.
Not claiming I am too happy with this choice. That includes a whole
lot of stuff, not just fonts

 

[Neil Cerutti]

This is supposed to impress me?

Hehe. No! But he's got enough clout to give the notion some
traction.

Yeah, most of the books I recall that used this were C++ books.

Yes, that would be why I bet.

 

[Chris Angelico]

What makes sense for a word processor and what makes sense for a
programming language are two very different things.

Yes. I was just completing the set, since the heading didn't specify
*for programming languages*.

ChrisA

 

[Steven D'Aprano]

3. Tab stops are measured in something other than characters.

With variable-width fonts, it's illogical to set tab stops in
characters. DeScribe Word Processor defined them in centimeters, way
back in the early... well, I didn't meet it till the 90s, but I don't
know how long it had been around before that.

Am I the only one here who has used a typewriter?

Tab stops were set manually, to a physical distance into the page, using
a mechanical stop. This long predates the "rule" that tab stops are every
8 characters.

If your editor doesn't support setting tab stops to at least single pixel
resolution, it's not supporting tabs, it's supporting something else that
it merely calls "tabs".

 

[Steven D'Aprano]

What makes sense for a word processor and what makes sense for a
programming language are two very different things.

Word processors are almost always working with blocks of running text,
set in proportional fonts, often with multiple font sizes and styles. It
is usually assumed that line breaks are ephemeral, i.e. as the text gets
edited and reformatted, lines will re-flow.

Word processors mostly use tabs for aligning text, e.g. in tables and
lists. Exactly the same thing that tabs are used for in source code.

Large blocks of running text are irrelevant, because tabs are rarely used
inside large blocks of running text.

Program text is almost always(*) displayed in a fixed-width font. No
font information is carried along with the program text at all; it is
assumed the reader will pick a font and size of their own preference,

And tab settings.

If you're going to complain that changing the tab settings will break the
layout of the source code, so will changing the font and size.

 

[Roy Smith]

Am I the only one here who has used a typewriter?

Tab stops were set manually, to a physical distance into the page, using
a mechanical stop. This long predates the "rule" that tab stops are every
8 characters.

Yup. I learned on a good old manual, with mechanical "Tab Set" and "Tab
Clear" function.

Of course, on an 029, you set the tab stops by punching a drum card.

If your editor doesn't support setting tab stops to at least single pixel
resolution, it's not supporting tabs, it's supporting something else that
it merely calls "tabs".

Yup. I use emacs. "M-X edit tab stops" does that. Like so much else
about emacs, I haven't used that feature in years (gee, maybe decades),
but it's nice to know it's there.

 

[Jason Friedman]

Am I the only one here who has used a typewriter?

I used one. And http://en.wikipedia.org/wiki/White-Out. And

http://en.wikipedia.org/wiki/Correction_tape.

My wife typed her dissertation on this:
http://en.wikipedia.org/wiki/File:Hardwarewordprocessor.png.

 

[Timothy Madden]

On 06.04.2013 23:17, Larry Hudson wrote:
[...]

What you want and what you think are irrelevant. The Python language
(whatever version) is already defined. If you want to use it, you have
to accept it and adapt to what it is. Live with it and move on.
Complaining about it is a complete waste of time -- it's NOT going to
change just because YOU don't like it.

Adding an option for fixed size tabs will not change the language
(and someone even suggested I patch my own copy, but this discussion is
not about me, is about tabs).

And in actual practice, that has been shown to be a Good Thing.

Yes, I agree, it is. It just could have been better.

Timothy Madden

 

[Timothy Madden]

Then you see my point, unless you are being told what to use by a boss
then there are plenty of other languages you can choose from. Python is
rigid about it's format, that's just what it is and a lot of people like
it but if it's not your thing then some other language will probably
suit you better. However, if you are working for a company, or OSS
project, you are probably going to have your style dictated whatever
language you use [...]

I am ok with the people that like python the way it is.

But an option from python authors to make tabs work the way they used to
would have been nice.

Just my opinion, I do see other people here think otherwise...


Timothy Madden

 

[Ethan Furman]

I am ok with the people that like python the way it is.

Really? 'Cause I totally missed that from the subject line...

 

[Mark Lawrence]

On 05/04/2013 22:41, (e-mail address removed) wrote:

snipped as loads of comments already made.

Timothy Madden

The BDFL's view from many moons ago
www.python.org/doc/essays/ppt/regrets/PythonRegrets.ppt slide 3.

 

[Roy Smith]

Really? 'Cause I totally missed that from the subject line...

Take this logically...

1) Ethan hates all clp readers

2) Ethan does not hate people who "like python the way it is"

I therefore deduce that Ethan believes there are no clp readers who
"like python the way it is". This may be a mistaken belief, but at
least there's no logical contradiction.

 

[Roland Koebler]

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

 

[Nobody]

Am I the only one here who has used a typewriter?

Tab stops were set manually, to a physical distance into the page, using
a mechanical stop. This long predates the "rule" that tab stops are every
8 characters.

And your point is?

Typewriters don't have a tab "character". The information regarding tab
stops is conveyed out-of-band from the typist to the typewriter, and
doesn't need to persist beyond the time taken to type the document.

 

[Grant Edwards]

And your point is?

The point is that there is little historical precedent for assuming
that tab stops are evenly and equally spaced across the page (let
alone one particular fixed, even spacing) -- and people who mix spaces
and tabs based on such false assumptions are responsible for their own
bleeding foot.

Typewriters don't have a tab "character". The information regarding tab
stops is conveyed out-of-band from the typist to the typewriter, and
doesn't need to persist beyond the time taken to type the document.

And the same is true when you don't mix tabs and spaces when indenting
Python code. If you use tabs alone when indenting Python code it
doesn't matter where the tabs are set -- they don't even have to be
equally spaced -- the meaning of the source file is unambiguous.

If you mix tabs and spaces, then you've got to provide out-of-band
information regarding the position of the tab stops in order to make
the source code unambiguous. Since there's no mechanism to provide
that OOB tab stop info, mixed tabs and spaces isn't accepted.