[snip too-long subject]

[Josiah Carlson]

 >>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
**end quote**

[snip attached file information and comments]


> now, about the requests. i want to see python more symmetrical and 
> consistent. this way it could be advertised/marketed easier to places 
> with serious portability AND maintainability thinking, over other 
> pure-procedural languages. Is anyone is interested in that?

I'm all for Python being used in more places (as are most people here), 
but I am not for changing the language to suit someone's arbitrary 
opinion on what it should be.  You'll likely find others who are also 
against arbitrary changes that seem to suit an individual's sense of 
'what should happen'.  Read some of the "suggested changes" to syntax 
and behavior that others have offered here, and you'll notice a strong 
tendency for the suggestions to be generally disliked (if not loathed).

Guido and others in python-dev seem to be doing a pretty good job of 
keeping things together.  While Guido has some regrets (in terms of 
Python's behavior), he seems much happier than regretful, and I doubt 
many (if any) of your "suggestions" will go far, because I don't believe 
that /any/ of your suggestions are Pythonic.


> - i want the documentation to be fully interlinked (in current 
> hierarchy) and to have another alternative hierarchy - from usage-point 
> of view - if i say list, ALL about lists should be there, and not 
> separated in 3+ different places, so either a lot bookmarks are to be 
> kept, or 10+ clicks to get the next piece of info. Same goes for most 
> data/execution things. it can be done as simple links-only-layer - i 
> dont mind. Probably data-model and execution model are best to follow as 
> template.

I find that the documentation index 
(http://www.python.org/doc/current/lib/genindex.html) to be quite 
useful, as well as google.

>  - order of variable assignments in class namespace to be offered/passed 
> to the metaclass, as separate argument or the (now dict) namespace 
> argument to be properly ordered iterable (moving the dict creation from 
> C into python metaclass - well, if any. type(name,bases,dictiterable) 
> can still do it in C). Order can be safely ignored if not needed.

I understand that for some reason this is important to you.  However, 
previous to your initial post about it, I've never heard of anyone 
having a need for the assignment order of class variables.  This 
suggests that very few people have a need for it, further shown by the 
fact that no one replied to your post saying, "hey, I've wanted to do 
this too, tell me if you figure it out".

I did reply to your post, if only because I thought you wanted 
/instance/ variable assignment order, which /has/ been brought up in 
other contexts.


> - i want somehow to turn the { MY order of dict values here } syntax 
> into as-is-ordered thing! Could be even with some pragma switch that 
> would create my dictOrder (or some builtin one) instead of internal 
> hashed mapping! This is equivalent to above, but for plain value dicts 
> (and not the attribute namespaces, represented as dicts). Function 
> keyword args can be another thing to keep order of - if required. (a 
> sort of execution-namespace control pragma)

Ordered mappings are probably not currently supported in Python because:
"Special cases aren't special enough to break the rules."

Dictionaries are great.  Dictionaries are fast.  Lets not mess them up 
by slowing them down.


> - the notion of iterators/ generators, and notion of interfaces are so 
> powerful but so poorly advertised - and used. Now there is itertools - 
> PERFECT! but i have to import it while waster things like map() are 
> still sitting at plain view - hence - from lamer's point of view - 
> easier to use.

Perhaps you didn't mean "lamer", such a term is quite rude.  If you 
/did/ mean "lamer", then that would make you a "troll".

There are 12 functions in itertools.  Adding 1 built-in function takes 
the word of Guido.  Adding 12 built-in functions would likely take the 
word of most of the core developers of Python, and god.  The itertools 
module is the proper location, as determined by Guido and others in 
python-dev.

As for map and other builtins being in plain view, even if they are not 
iterators/generators, they are still useful.


> - what about try: finally: over generators? PEP288. gee, 50 lines of 
> iterator class instead of 5 with yield just becasue i _have_ to close a 
> file...

If it takes you 50 lines to close a file after yielding it, you're doing 
something wrong.

Checking the source code that you attached, you use yield once, which 
doesn't seem like it is iterating over file handles or file names.

Post the code in a reply, and I'm sure someone will show you how to 
clean it up.


> - all builtin functions that do not add value to the language as 
> language should move into separate module (e.g. map, zip, sum etc... vs 
> callable, isinstance, builtin type-constructors) and not be so 
> over-emphasized.

map, zip, sum, etc. are used in a large amount of production code. 
Moving them somewhere else would break every piece of code that uses 
them.  This is not going to happen soon, possibly ever.

If you don't like their location, create a module that modifies 
__builtins__ that gets imported by site.py.  Something like the 
following would work...

#my_confused_builtins.py

move_me = ['map', ...]
for i in move_me:
     exec("%s = __builtins__.%s"%(i,i))
     exec("del __builtins__.%s"%i)

#include the following line in site.py
import my_confused_builtins


> - all interfaces (not types!) - e.g. containers (__get/set/delitem) - 
> should be named 'interfaces' - now this is vaguely called 'customization'.

I don't know why they initially decided on "customization" for a name, 
perhaps it is because we are customizing the behavior of various 
operations on new objects.

FYI, almost all of the __ops__ are listed in the documentation for the 
operator module.


> - how do i check if x is iterable?

try:
     iter(x)
except:
     #x is not iterable

> - (i see this goes in python2.4, PEP289)  [snip comments]

PEP 289 has been accepted, so your comments on it are late.


> - IMO most funcs now needing a list or dict should be happy with proper 
> iterable. ( Eventualy funcs needing only iterable over single values may 
> have *args instead, and for key-balue tuples **kargs instead. but this 
> isnt that important.)

Where any iterable makes sense (and not just a list), the Python is 
moving that direction, and if all goes well, (I believe), that will be 
the case in the future.

For objects that need a dictionary, usually it is because they use a 
dictionary for its primary purpose, looking up and storing arbitrary 
values.  Certainly any arbitrary sequence or iterable can be used as a 
dictionary, but when people say dictionary, they usually mean something 
with (approximately) O(1) access time for any element, that can be 
queried and written to multiple times (you can only search an iterable 
once, and can't write at all).


> - i would like to be able to control somehow what constructors are 
> available for example to eval() - so i can patch them (operator *) - so 
> things like
[snip limitation argument]


Check the compiler module.  When you have an AST, you can do all the 
checks your heart desires.

There may be a project to create a restricted python execution 
environment for such tasks, but a better idea is to not allow eval() and 
exec() statements at all.


> - i want the list head/tail notation:
>   a, b, *c = somelisthere
>   apart of all else, it helps future maintenance and readability of the 
> program, and this IS important if python is to be used for serios things 
> in serios places. ah, i might like simmetrical thing for dicts but you 
> will not like it:
>   'a':var1, 'b':var2, **rest = dictionaryhere

I doubt Python is going here.  If you want head/tail of a list...

def head_tail_list(lst, count=1):
     return tuple([lst[i] for i in xrange(count)] + lst[count:])

a,b,c = head_tail_list(somelisthere, 2)


If you want the head/tail of a dict...

def head_tail_dict(dct, *items):
     return tuple([dct.pop(i) for i in items] + [dct])

var1, var2, rest = head_tail_dict(dictionaryhere, 'a', 'b')


Personally, I think that the syntax you give is ugly, and have had 
little need to do anything close to what you describe.  I've also not 
seen anyone who uses lisp-like car/cdr operations in Python.  One thing 
you should remember is that Python lists are actually arrays.  Pulling 
an element off the front is very wasteful (computationally).

Also considering that the functional equivalent to what you want is a 
1-liner in either case, I see little reason for any of this 
functionality to be included with Python now or in the future.


> [btw, anyone interested in very thin framework for UI-via-html-forms?
> all is in python, even the form description, html etc.
> it's 75%-done, with most things showable.]

Sounds neat.  Perhaps you should create a sourceforge.net project for it.

  - Josiah