RELEASED Python 3.0 final

[Andreas Waldenburger]

On Fri, 5 Dec 2008 12:16:47 -0800 (PST) "Fernando H. Sanches"
<fernandohsanches at gmail.com> wrote:

> On Dec 4, 5:45 pm, Andreas Waldenburger <geekm... at usenot.de> wrote:
> > On Thu, 4 Dec 2008 11:52:38 -0600 s... at pobox.com 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



-- 
My real email address is constructed by swapping the domain with the
recipient (local part).