Vlad Kudelin
Posts: 2
Nickname: mabooka
Registered: Jun, 2007
|
|
Re: Python 3000 Status Update (Long!)
|
Posted: Jun 20, 2007 8:20 AM
|
|
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!!!
|
|