The Artima Developer Community
Sponsored Link

Weblogs Forum
Python 3000 Status Update (Long!)

47 replies on 4 pages. Most recent reply: Jun 13, 2008 7:43 PM by Brad Schick

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 47 replies on 4 pages [ « | 1 2 3 4 | » ]
Christos Georgiou

Posts: 7
Nickname: tzotzioy
Registered: Mar, 2005

Re: Python 3000 Status Update (Long!) Posted: Jun 19, 2007 4:54 PM
Reply to this message Reply
Advertisement
I've missed many discussions for 14 months now (that's the age of my first son, second is coming), so I'm betting this is a dead horse, but isn't it python3kically obvious that {} is an empty set and {:} is an empty dict?

No?

Strange.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Python 3000 Status Update (Long!) Posted: Jun 19, 2007 4:58 PM
Reply to this message Reply
Some questions.

1) What do you mean by a "view" on a set? Are there different underlying implementations with a common interface?

2) I'm also in trouble with the suggestion that you want to replace range by xrange. The current semantics of xrange does not even support slice operations. The representation of xrange on a REPL is poor and does not show anything about it's behavior. Of course expressions like list(xrange(100))[::2] avoids these problems but it looks like boilerplate. I don't understand the rationale.

anthony boudouvas

Posts: 14
Nickname: objectref
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 19, 2007 5:42 PM
Reply to this message Reply
I read the PEP 3124 and what is all about. It surely contains some interesting points but i am sceptical about Interfaces and Adaptation. These are fine in staticaly checked languages such as Java, C++ and C#. Do we REALLY need this stuff in Python ??

Luciano Ramalho

Posts: 3
Nickname: ramalho
Registered: Jun, 2007

The meaning of == Posted: Jun 19, 2007 6:11 PM
Reply to this message Reply
"Equality comparisons (==, !=) will compare for object identity (is, is not) by default."

Currenly that is the default for the object class, but lists, dicts and so on overload == to make more sense from a user point of view, by doing a deep comparison. Will that change? I always thought the semantics of == and the is operator in Python made a lot more sense than the way it's done in Java, where == always means is.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Python 3000 Status Update (Long!) Posted: Jun 20, 2007 10:31 AM
Reply to this message Reply
A couple of clarifications as I understand from lurking on various Python lists:

Reduce was just moved to the functools module. Should make it possible to use it for those odd cases when it is still useful. Not only does Guide not like reduce, but it also is rarely if ever used by most Python programmers. I expect very few people to miss reduce. There are alternatives now that cover 80% of the common use cases: sum(), max(), min(), any(), all() and .join().

Equality comparison: I can’t remember exactly but I think this refers only to ordering comparisons for objects that do not have a comparison criterion defined. I think Python currently uses the memory address (number) of the object to decide which one is bigger or smaller. This is arbitrary and implementation dependent and will be dropped.

Vlad Kudelin

Posts: 2
Nickname: mabooka
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 20, 2007 11:20 AM
Reply to this message Reply
All the following is to be read by Guido only:-):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

First of all, many-many thanks for this beautiful language. Now that after several years of Python only I have to get back to some other tongues, I pity myself so much...
And, many congats on it being so rapidly accepted and developed. (Some concerns about that, too, but... never mind:-)).

==================
I. Comments on this page
==================

General feelings are:
* Changes are not as dramatic as they could've been: good (e.g. despite rumors, the tab as a block indent is not replaced by a BEL);
* Much more symmetric design (the ancient Greeks knew that symmetry is beautiful).

I am saving my vote about classes, types, exceptions, and functional programming for later: let's see how it will look like. The following are a few instant reactions just from reading this article:

Pros (exciting):
* clear distinction of text and binary streams;
* symmetry in encoding/decoding;
* "print()" vs. "print" and the "," at the eol (I just wrote my own version of a 2to3 tool doing that only a few weeks ago:-));
* mutable data types (!!! Hurra-aaa!!!) -- (but only if I understood it correctly. Please see "features requests"-A below);
* BytesIO : a) symmetry again, b) performance ==> Great.
* function prototypes: OH MAN! Now I can safely remove half of my code (doing all kinds of checking);
// but: see Cons, B).
* decorators (symmetrically) can decorate houses, apartments, bungalows, igloos...


Cons (concerns):
A) Transitional dev-t

I think the plan is too complex (7 steps) and merciless. For starters, writing unit tests: thanks a lot, but that (as a price for changing a version) is unrealistically high for many. Most people are not paid for that but rather for as many lines of new code that fingers can type in a day. Especially if it works for years just fine. (And besides, unit tests are written in Python.:-)).

So... Would be nice to hear a more mankind-friendly plan, something allowing for a smooth gradual transition. I'd like to propose a transparent support for two versions (say 2.6 and 3.0) co-existing and collaborating on a same box, so that one could keep old modules and write new ones in a newer syntax as she pleases. E.g. (I didn't think ab. it, simply improvising):

# !/bin/env python -Y Y3K
# ==> use Py3K interpreter
assert ("no reduce in the following code (-:_")

...
# !/bin/env python
# ==> default: use "Y2K"-backward-compatible version


B)
* function signatures (maybe I was too fast to congratulate): ~~"core language assigns no meaning to....". Oops.
I guess I still have to do type checking of all my APIs manually. Well, it's a good discipline, thanks for keeping me in shape:-).


C)
>> Text streams have a new attribute, the encoding, which can be set explicitly when the stream is opened; if no encoding is specified, a system-specific default is used
-- Fire in the vault! I could give an example when grep doesn't work(!) -- because it "assumes" that the file is binary (although it's Unicode).


X,Y,Z): reduce
reduce is good. Map and reduce is even better. Map w/o reduce is a crutch.

I don't give a damn about reasoning; I just want my reduce.

I'd like to write very simple one-liners in one line.

>>> assert reduce(lambda x,y: x+y,[x and x in string.ascii_uppercase or 0 for x in 'Love Will Save The World']) > len("Py3k")



=============
II. Feature requests
=============
// Sorry I never find energy to use appropriate channels for these; let me use the occasion. I hope my requests are simple and practical.

A) mutable strings (aka "*(pStr + 18)=0;")

I assume that "mutable "bytes" data types" is going to give us just that (and one won't have to 'convert' between mutable and non-mutable afterwards if unnecessary; or, at least, creation of an object from a C string is going to be virtually free, i.e. not involving a memcpy);

-- then, great, thanks.

Otherwise:
instead of ln = ln[:-1]

I really-really would like to be able to do smth. like:
*(pStr + strlen(pStr)) = 0;

The reason is, again, -- performance (and Global Warming): it's just ridiculous to have to create a new object and copy the data ((even putting the performance overhead aside for a minute)), to do simple things like that, and warming up the Atmosphere bt another fraction of a degree every time.

(((NB: Of course a set of library functions like "string.cut_at(position) will never suffice, as programmers need to do all crazy things freely))).



B) new_line-less readline(s)

Typically, one needs (I bet):

for ln in open(flnm):
ln = strip_newline_char(ln);
use(ln)

where "strip_newline_char(ln)" is *not* ln.rstrip(): one needs only to get rid of the '\n' (or whatever the OS defines) but needs all the spaces and tabs
(the latter are information, the '\n' is just a break in a stream of data).

Given that (and given smth. as ugly as this):

def strip_newline_char(ln):
if ln[-1] == '\n': # do a scan
return ln[:-1] # do new(...); do strcpy(...)
...

this call becomes a real performance bottleneck -- when you need to parse terabytes (pretty soon for many - petabytes) of text.

Could we please get (as a new feature):

for ln in open(foo).readstrings(): # or smth.; meaning '\n' or '\r\n' are stripped by Kernighan and Ritchie
...

-- please?..


C): "++"

Could I please use "i++" instead of "i += 1"?.......:-)))).

That would be only fair, keeping in mind that I'll have to type "()" with print from now on...:-).

To make myself clear: Every time I type:

if not d.has_key(k):
d[k] = 0
d[k] += 1

-- I have two strong feelings:
a) a Perl programmer would only have to type one line;
(but then instantly: "I am proud to type these two extra lines, this distinguishes me from a clueless Perl programmer..:-)");
b) I must type " += 1" # ughrt!.. why didn't he go all the way?!

I just did a grep: in all of my code, it's >70% "+= 1" and only <30% "+= smth.else".

A nice and clean shortcut that people with certain background would appreciate, no philosophy here.

D) "__"s.

Classes need some access control. It all works fine as is, but only up to a certain size. After that, -- even if I own a whole library and am the only developer, -- I can make a mistake.
Please protect us by introducing some equivalents of "public" / "private" / "protected".


_______________

Again and again,

Thanks for this b-e-a-u-t-i-f-u-l language!!!

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Python 3000 Status Update (Long!) Posted: Jun 20, 2007 11:26 AM
Reply to this message Reply
> I live in Phoenix, and the 21st just happens to be my
> birthday! I'd love to hear you speak, but, pray tell,
> where *is* the Phoenix office? My Google-fu is weak...

To anyone in the Phoenix area who wants to attend, here's the URL to register:

http://services.google.com/events/phoenix_speakers07

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Python 3000 Status Update (Long!) Posted: Jun 20, 2007 3:04 PM
Reply to this message Reply
> All the following is to be read by Guido only:-):
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ==================
> I. Comments on this page
> ==================

I did not follow the instructions and read your post. I hope it was meant as a joke. In any case I had to chuckle:

Cons:
A)
#!/home/vlad/py3/python
# ==> use Py3K interpreter

and

#!/bin/env python
# ==> default: use "Y2K"-backward-compatible version

B)
Just add signature checking to pylint or ask somebody who cares enough to do it. What? You say nobody wants to do it? Well I am sorry I guess nobody cares enough about signature checking to do the work.

C)
Don’t use the default then. Specify the encoding when you open the file. For the rest of us the default of UTF-8 will probably work fine.

X,Y,Z)
You‘ve got to be kidding! That example is precisely one reason why reduce should be discouraged.
You can trivially rewrite that with an easier to understand and shorter version:

assert sum(x.isupper() for x in 'Love Will Save The World')> len("Py3k")

Requests:
A)
Done too much C lately? Mutable data is evil! You get into aliasing problems. The only reason why we have them is because of space and speed; if that wasn’t a concern we would be better of making everything immutable. With the new byte type you should be able to do this anyway: bStr[18]=0 and bStr[-1]=0

B)
This is indeed a common enough idiom that it might be useful to formalize it somehow. Personally doing use(ln[:-1]) and use(ln.strip()) worked good enough for me not to bother to much.

C)
No, just no. How many operators do you want (http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf)? Thinking of it, why don’t you just use Perl instead? plenty more opportunities to write clever code.

And if you are writing:

if not d.has_key(k):d[k] = 0
d[k] += 1

it is your own fault. The ++ operator will save you exactly 1 character. Use this instead:

from collections import defaultdict
d=defaultdict(int)
d[k]+=1

Clearer and will save more lines of code than ++ in the long run.

D)
At least right now when some clueless soul makes all attributes private there is a way around that.

Bruce Eckel

Posts: 874
Nickname: beckel
Registered: Jun, 2003

Re: Python 3000 Status Update (Long!) Posted: Jun 20, 2007 6:09 PM
Reply to this message Reply
Any chance we could get rid of mandatory self in classes, as long as everything is up for grabs? I don't think any other mainstream language does this, as an example of "we don't need it." It's the one place in the language where we are forced to do more work, instead of less.

Vlad Kudelin

Posts: 2
Nickname: mabooka
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 21, 2007 3:51 AM
Reply to this message Reply
nes,
thanks for your comments. I still am hoping that Guido will read my post (although "his eyes only" was of course a joke).

Sorry for polluting this forum, but I think I must comment ((briefly)), as your reply suggests that I can be misunderstood.

> B)
> Just add signature checking to pylint or ask somebody who
> cares enough to do it. What? You say nobody wants to do
> it? Well I am sorry I guess nobody cares enough about
> signature checking to do the work.

To me, it is clear that external tools and language features are two different pairs of shoes.
// If I need to explain this, let's take it offline.
In fact I right now must write (my own) generic typechecking code, -- otherwise creating interfaces with 100s of methods safely would be absolutely impossible.
I would not need to do that if there were a language feature.
Note that type checking was a major, major superior feature of C++ over C.
Now let's ask the community: am I the only weirdo having such issues?

>
> C)
> Don’t use the default then.

This one made me really LOL.
(Let's take it offline if you wonder why).


> X,Y,Z)
> You‘ve got to be kidding! That example is precisely one
> reason why reduce should be discouraged.
> You can trivially rewrite that with an easier to
> understand and shorter version:
>
> assert sum(x.isupper() for x in 'Love Will Save The World')> len("Py3k")

The "example" was me having some fun, it is of course not realistic. However:
why "++" is one operator "too many", but sum etc. (vs. the only -- but generic-- reduce) is not?
Besides all, shorter is not the goal / the point. Clarity, transparency, simplicity, etc... - is.
Somebody here had expressed it very clearly and beautifully by using the "mapping to the brain" wording.


>
> A)
> Done too much C lately?

Any problems with that? Do you hate c? Python wraps up c code, let me remind you.
/* I wish I wouldn't, but there's no other way (currently) to build some real-world apps all in Python. */

> Mutable data is evil! You get into
> aliasing problems.
The evil is also: Iraq, Iran, Afghanistan... But: if you watch "Rambo-3" now, you'll find out that the Afghans are closest friends who lead the Holy War.


> The only reason why we have them is
> because of space and speed;

That is precisely the reason. Up to 70% of time is spent in "ln = ln[-1]". It can render to many hours....

> With the
> new byte type you should be able to do this anyway:
> bStr[18]=0 and bStr[-1]=0

That's all I needed, thank you.


>
> B)
> This is indeed a common enough idiom that it might be
> useful to formalize it somehow. Personally doing
> use(ln[:-1]) and use(ln.strip()) worked good enough for me
> not to bother to much.

It doesn't work for me. See above (performance).


>
> C)
> No, just no.
> ) Thinking of it, why don’t you just use Perl instead?

"++" didn't come from Perl. (Meaning: bouncing the same "why don't you" question back to you).


> And if you are writing:
>
> if not d.has_key(k):d[k] = 0
> d[k] += 1
>
> it is your own fault. The ++ operator will save you
> exactly 1 character. Use this instead:
>
> from collections import defaultdict
> d=defaultdict(int)
> d[k]+=1

I totally disagree that that is clearer; defaultdict is by far less transparent and clearly much more to type (esp. including import),
-- but again (repeating myself), typing more is not a problem (please re-read the original), it's "typing more without sense".
" += 1" doesn't make sense, given that "++" exists .

>
> D)
> At least right now when some clueless soul makes all
> attributes private there is a way around that.

-- I removed all my comments on this.

thanks, cheers, regards, whatever.

Justin Johnson

Posts: 1
Nickname: justinj
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 21, 2007 7:01 AM
Reply to this message Reply
> Any chance we could get rid of mandatory self in
> classes, as long as everything is up for grabs?

In just about every language I've seen that doesn't use such a scoping identifier, you'll find ad-hoc coding standards for marking class instance variables. For example prefix with "m_" or postfix with "_" in C++ is common.

Not having a scoping prefix makes naming variables more annoying in some methods. Currently you can do this:


def set_properties(self, name, age, address):
self.name = name
self.age = age
self.address = address


because the member variables are scoped using 'self'. With automatic scoping:


def set_properties(self, inname, inage, inaddress):
name = inname
age = inage
address = inaddress


Also, are the above variables at instance scope or local? This isn't a problem in languages such as C++ because local variables are specified directly along with their type.

I've seen a few objections to 'self' over time but if you think about it it makes good sense.

Jeffrey Jacobs

Posts: 3
Nickname: timehorse
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 21, 2007 8:11 AM
Reply to this message Reply
> Any chance we could get rid of mandatory self in
> classes, as long as everything is up for grabs? I don't
> think any other mainstream language does this, as an
> example of "we don't need it." It's the one place in the
> language where we are forced to do more work, instead of
> less.

Well, I do prefer self. Actually, I never liked that you always have an implied this parameter in C++ and Java. You should spell things out, and imply nothing. Plus, it makes it easy to distinguish class-methods. What's more, although this is evil, you don't HAVE to call it self in python. You could call it "this". We only use self by convention and by using convention, code becomes more legible. But the language doesn't, no should it (IMHO) include a requirement for the local object reference to literally be self.

What irks me most, actually, is a lack of a similar convention for "instantiated class". E.g., when using the super function, you need to lexicographically include the typographic name of the class in the call. You can't use self.__class__ as that would subvert the MRO for derived classes and potentially lead to recurrsion. No, for a class A:

class A(B):
  def myBase(self):
    super(A, self).myBase()


As a programmer, I would prefer not to have to repeat the name of the class I'm defining. Ideally, I'd expect super to be compiled and bound to the outer class automatically. But since we're on the topic of explicitness maybe a better solution would be something like:

class A(cls, B):
  def myBase(self):
    super(cls, self).myBase()


The idea being that the first parameter to a class definition is a name that binds to a reference to the class being defined. That name can be used anywhere within that class definition and its scope is only with a given class's definition. That way, if B also uses cls for the name of its self-reference, it will not collide with A's.

Of course, this would mean that every class had to be defined with parenthesis if it wanted to use cls, but then, if it has no bases, it probably (though not necessarily) does not need super.

Anyway, now that you mentioned it, I WANT MY SELF FOR CLASS DEFINITIONS! Whaaaaaaaan. :)

Jeffrey Jacobs

Posts: 3
Nickname: timehorse
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 21, 2007 8:32 AM
Reply to this message Reply
> C): "++"
>
> Could I please use "i++" instead of "i +=
> 1"?.......:-)))).

Can of worms, my friend. First of all, who looks at an operator and thinks, "Ooo! that operator could be a bit more sonic..." Wait, wrong debate. Where was I?

Oh, yeah. So, first you say you need a unary operator for increment (++), right? Next thing, since it's an operator, classes should be able to override it, so we add __inc__. Then some programmers realize what they really want is increment and update, and others want update and increment. So now you have to provide __inc_post__ and __inc_pre__. Then, someone realizes they need a decrement, not an increment, so you get a++, ++a, --a, a--, __dec_pre__, __dec_post__, __inc_pre__ AND __inc_post__. Hachi Machi!

Yeah, being able to write a++ would be cool, but in the end, is it really worth it?

Ruben Reifenberg

Posts: 2
Nickname: ratsberg
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 21, 2007 9:10 AM
Reply to this message Reply
Yeah! Even while in fear of porting a lot of code, it will be worth it. I am always keen on pain when removing legacies :-)
(print, explicit long, exc_info ... I won't sorrow. Maybe len and "x in list" can go the same way in favour of list methods ?)

There's still one change scaring me: The annotated signature syntax.
    Uuups.
Do we really want a bigger syntax that still lacks exception declaration, and even worse: lacks restrictions that exceed the simple data type check? This was a good deal in the 1980s but not today.

I remember great plans about interfaces that overlap with the annotations. These included powerful restrictions like "x <= 3000", or dependencies between args. Are these plans gone?
There might even new legacy program code coming up: Tons of signatures that check for parameters having a type or class. The future may require that we check for parameters fulfilling an interface instead.
-> I'm afraid this detail is the legacy of tomorrow, introduced to quickly gain a base for the generic functions.

Dave Benjamin

Posts: 10
Nickname: ramenboy
Registered: Nov, 2003

Re: Python 3000 Status Update (Long!) Posted: Jun 22, 2007 12:37 PM
Reply to this message Reply
Guido,

In your presentation last night you had one slide which talked about the "str" vs "bytes" types in Python 3000. On the bottom of that slide was something like:

str(b"asdf") == "b'asdf'"

However, in discussing this slide (very briefly) you said that a type constructors like "str" could be used to do conversion. It seems like "str" is behaving more like "repr" in this case, which seems unusual and less useful to me. Was this a typo, or is this actually the way it's supposed to work? What's the rationale?

Thanks for coming out to Phoenix!
Dave

Flat View: This topic has 47 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Python 3000 Status Update (Long!) Previous Topic   Next Topic Topic: Scala steadily marches towards world domination!


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us