RELEASED Python 3.0 final

[bearophileHUGS]

Andreas Waldenburger:

My point is: If you mix tabs and spaces in a way that breaks code,
you'll find out pretty easily, because your program will not work.

- Most newbies don't know that.
- Sometimes it may produce wrong results.
- And even if you are an expert when you go changing a little a source
code that mixes tabs and spaces you usually break the code.
Is this enough for you?

Bye,
bearophile

 

[Andreas Waldenburger]

Andreas Waldenburger:

- Most newbies don't know that.
- Sometimes it may produce wrong results.
- And even if you are an expert when you go changing a little a source
code that mixes tabs and spaces you usually break the code.
Is this enough for you?

No.

While you are right on all accounts, forcing uniformity would still
interfere with (some) people's coding styles, "wrong" as they might be.
Python is not Gnome.

Maybe having Python issue warnings for inconsistent whitespace per
default might be a good idea. But that's about as far as I would go.


/W

 

[Peter Pearson]

It's more than warnings. With properly crafted
combinations of spaces and tabs you can get code which
looks like it has a certain indentation to the human
observer but which looks like it has different indentation
(and thus different semantics) to the byte code compiler.
There is often no warning.

Fascinating. Has anybody developed demo code that looks,
during code review, as if it prints a Snoopy calendar, but
really, during execution, emails your password file to
Minsk? The security implications are intriguing. What's the
most underhanded thing anybody has seen done?

 

[Terry Reedy]

Andreas Waldenburger:

It's a strong source for bugs, especially for newbies, that I have
hoped to see removed from Python3 (my first request of this was years
ago). I was nearly sure to see this wart removed from Python3, and now
I hear it's presents still. I don't understand why they haven't fixed
it.

Did you or someone fine a specific rejection of disallowing mixture in
3.0, or did no one specifically suggest it and offer to make the change?

 

[Hendrik van Rooyen]

I hereby recommend “pish and tosh†for use by anyone who wants to
counter someone's point. It beats by a country furlong the invective
that has become regrettably common here in recent months.

I second the motion to use pish and tosh for a first level of disagreement.

I recommend the rather archaic "Balderdash" as the next step in the
escalation of disagreement...

- hendrik

 

[Fernando H. Sanches]

Whenever has it been a pythonic ideal to "not allow" stuff? You get
warnings. Everything else is up to you.

/W

Python has "not allowed stuff" for a long time.

For example, it disallows statements in lambdas.

"Disallowing" is not bad. Disallowing bad practices (like mixing tabs
and spaces) is actually good!

I agree that the tab/space thing should be changed. Would it be too
hard to make the parser see if the indentation is consistent in the
whole file? This is a annoying source of problems, specially since you
can't tell a whitespace from a tab just looking at it.

And I personally disliked most of the changes (specially the ones on
map and reduce). I hope functional programming doesn't get even more
hindered in future releases, because I believe these changes only made
Python weaker.

Well, anyway, congratulations for everyone for Python 3 release. Some
of the changes were a real improvement (like the Unicode sources). And
I hope that, in the end, these changes help making Python a better
language.

 

[Andreas Waldenburger]

On Thu, 4 Dec 2008 11:52:38 -0600 (e-mail address removed) wrote:
[snip]
Whenever has it been a pythonic ideal to "not allow" stuff? You get
warnings. Everything else is up to you.

[snip]

Python has "not allowed stuff" for a long time.

For example, it disallows statements in lambdas.

Which is sensible (for Python) because it does not have block
delimiters.

Also, lambdas are syntactic sugar for special use cases. It's not
like they are needed at all. But sometimes mixing tabs and spaces can
be needed (think coding standards).

What else is disallowed?

"Disallowing" is not bad. Disallowing bad practices (like mixing tabs
and spaces) is actually good!

This presupposes that mixing tabs and spaces is "bad". That's like
saying C++ is bad.

I agree that the tab/space thing should be changed. Would it be too
hard to make the parser see if the indentation is consistent in the
whole file?

Maybe not, but it would be rather hard to agree on what can be
called consistent and what can not, I think. You can mix spaces and
tabs consistently, just as you can use any one consistently.

This is a annoying source of problems, specially since
you can't tell a whitespace from a tab just looking at it.

There are editors that let you show different symbols for spaces and
tabs (I know, I know ...).

And I personally disliked most of the changes (specially the ones on
map and reduce). I hope functional programming doesn't get even more
hindered in future releases, because I believe these changes only made
Python weaker.

+1


/W

 

[je.s.te.r]

And I personally disliked most of the changes (specially the ones on
map and reduce). I hope functional programming doesn't get even more
hindered in future releases, because I believe these changes only made
Python weaker.

The functional programming aspect of Python is one of my favorite
parts, having a mixed background in functional/non-functional languages.

 

[Steven D'Aprano]

Andreas Waldenburger:

It's a strong source for bugs, especially for newbies, that I have hoped
to see removed from Python3 (my first request of this was years ago). I
was nearly sure to see this wart removed from Python3, and now I hear
it's presents still. I don't understand why they haven't fixed it.

"It"? Context please... snipping unnecessarily quoted text is a good
thing, but please leave enough context for people to know what you're
talking about.

I think you're talking about mixed spaces/tabs in the one module.
Frankly, I question just how "strong" a source of bugs it really is. Oh,
I don't doubt that there are circumstances where it can cause bugs, but I
don't remember the last time the solution to some newbie's problem on
comp.lang.python was "use spaces or tabs but not both". My gut feeling is
that you have to have a fairly unusual set of circumstances before it
causes actual bugs.

So perhaps nobody on the python-dev team have fixed it yet because nobody
cares enough to do the work, or it's unexciting and tedious to fix. Or
maybe python-dev *think* they've fixed it, and the fact that it isn't
fixed is a bug that needs reporting.

Then this is the third thing I don't like of Python3 (the other two
being the removal of automatic tuple unpacking in function signature and
the wart of literals for empty set/dict).

Er, what do you mean? What wart?

 

[Steven D'Aprano]

The functional programming aspect of Python is one of my favorite parts,
having a mixed background in functional/non-functional languages.

map is still a built-in.

reduce is moved to functools.

I think the only change to map is that instead of returning a list, it
returns an iterator. What this means is that Python's functional
programming aspect is now lazy, and that's a good thing.

 

[Aahz]

The language has undergone an incompatible divide. Hopefully the
community need not do the same.

Pish and tosh. James was clearly making a funny; there's not *that* much
difference between 2.x and 3.x.

 

[bearophileHUGS]

Steven D'Aprano:

I think you're talking about mixed spaces/tabs in the one module.<
Right.


My gut feeling is that you have to have a fairly unusual set of circumstances before it causes actual bugs.<

I don't mix tab and spaces in my code, and my editor is able to
convert them, so after the first few days of Python coding, it more or
less never caused me problems.
But such thing in code written by others has caused me enough
troubles, I am generally unable to edit such code keeping it
functional, so I have to (sometimes by trial and error) convert it to
a space only (or tabs only) format.
Such troubles aren't that large compared for example to the usual
troubles I receive writing and comping C++ code, but enough compared
to the usual smoothness of coding in Python

Er, what do you mean? What wart?<

Not using {:}/{} as literals for empty dict/set.

Bye,
bearophile

 

[Dotan Cohen]

I second the motion to use pish and tosh for a first level of disagreement.

I recommend the rather archaic "Balderdash" as the next step in the
escalation of disagreement...

http://bash.org/?23396

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

×-ב-×’-ד-×”-ו-×–-×—-ט-×™-ך-×›-ל-×-מ-ן-× -ס-×¢-×£-פ-×¥-צ-ק-ר-ש-ת
ا-ب-ت-Ø«-ج-Ø­-Ø®-د-Ø°-ر-ز-س-Ø´-ص-ض-Ø·-ظ-ع-غ-Ù-Ù‚-Ùƒ-Ù„-Ù…-Ù†-Ù‡â€-Ùˆ-ÙŠ
Ð-Б-Ð’-Г-Д-Е-Ð-Ж-З-И-Й-К-Л-Ðœ-Ð-О-П-Р-С-Т-У-Ф-Ð¥-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я
а-б-в-г-д-е-Ñ‘-ж-з-и-й-к-л-м-н-о-п-Ñ€-Ñ-Ñ‚-у-Ñ„-Ñ…-ц-ч-ш-щ-ÑŠ-Ñ‹-ÑŒ-Ñ-ÑŽ-Ñ
ä-ö-ü-ß-Ä-Ö-Ü

 

[Mensanator]

I second the motion to use pish and tosh for a first level of disagreement.

I recommend the rather archaic "Balderdash" as the next step in the
escalation of disagreement...

As a W.C. Fields fan, I love his "non-swearing"
vocabulary:

- Drat

- Dag nab it

- Holy Mother of Pearl!

etc.

 

[MRAB]

As a W.C. Fields fan, I love his "non-swearing"
vocabulary:

- Drat

- Dag nab it

- Holy Mother of Pearl!

etc.

Holy Zarquon's Singing Fish! (Hitch-hiker's Guide to the Galaxy)

But don't say B*****m.
http://www.bbc.co.uk/cult/hitchhikers/guide/belgium.shtml

 

[William McBrine]

I agree that the tab/space thing should be changed. Would it be too hard
to make the parser see if the indentation is consistent in the whole
file?

*Something* has changed. I had a piece of code where, without realizing
it, I had a tab mixed in with the spaces at the start of one line in a
block. In 2.5, it worked, silently. In 3.0, I got an indentation error.

 

[je.s.te.r]

map is still a built-in.
reduce is moved to functools.

I realize that, but that wasn't how it was looking a few years ago. I'm
just saying that any move away from functional programming in Python
would be a negative in my eyes.