discussion - possible improvements in python

I was thinking ... python is pretty amazing. But something's I think that would be nice are:

1. Type hinting (which is comming out in php5)
For example. when defining a function it allows you to put in a type to enforce. eg:
This way I don't have to use isisntance on my input params in every function. That'd save alot of validation. I'm not saying make it compulsory, but allowing type hinting would be awesome.

2. Compiling python code.
I like developing in an interpreted language ... makes development time much much faster and easier. But once an app is done, it'd be nice if it could be complied into assembly like c++ purely for speed of execution. Maybe even have a python to c++ converter so you could convert it and then compile it in c++ (one of the fastest languages for execution speed). The current compiler doesn't help in speed up .. its similar to java's dodgy comiler.

Eli

one thing, ewww. sorry but that form is very ugly although i totally agree about the ablity to compile directly to native bytecode! To have a lang like python that could run at C++ speeds would be a huge step forward!

What i think Python needs to do is inforce some kind of structor for its modules i.e. all module names are lowercase, classes in titlecase etc, just to make things more uniform and easier to use (or at least thats my oppinion)

Anyway i have a pet project you might be interested in, its still in the planning stages so your input would be very appreciated even if you dont wana get involved; email me about it.

Mark.

float divison would 8e nice.
such as:
1/2 = 0.5

and something like
1//2 = 0
or
div(1,2) = 0

for int division

this is my one major gripe with python, although i hear that this will finally 8e fi><ed in an upcoming version

ps, sorry 4 the >< and 8s, my key8oard ain't workin right and i don't want to 8other 2 repair it

Hmm ....interesting idea!
The more i thik about it the more I like it.
because naturally 1/2 should give you a half, and you should have to do something different to do integer devis .. not something diff to do natural devis.
I dun mind the // syntax either =P

Why not use the new division syntax right now?
Look at PEP 238 -- Changing the Division Operator.

Why a // operator? Not that i mind the syntax at all but why not just call int() on the float if you want one.. all be it the wrong answer right now i.e. int(0.5) returns 0

*looks forward to the day when Python is type independet*

Edit: this also works..



Mark.

Netytan, a floor operation and a truncation isn't the same thing. The // operator will take the floor, just as / does in Python and C and its derivatives today.

For the rest, I can't exactly grasp what you're trying to say. Are you negative or positive to the change from integer division to true division? Is it just the floor operator you dislike?

Whoa! .... like stepping into a parallel universe after this thread =P
I'm using this from now on!
Bit of a pest to put it all my files .. but I guess python needs to be backwards compatible =/

And Mark, we're trying to make it more natural so that 1/2 becomes 0.5 instead of 0
That is, its a pest to have to remember to convert to a float all the time for an accurate calculation.

Eli

HI perc, sorry thats what you get for trying to reply to stuff 30 seconds after waking up

I'm all for true devision! Infact i see little reason to keep the old way of doing things, i'd prefer to be able to call int() on the float if i needed the answer as a int; get me now?

int() rounds the number down all the time i.e. int(0.5) is 0 instead of 1

I think yogi got me , i can see your point about not having to convert each time.

Mark.

It's important to remember that int() does not round the number down. int() truncates a float; that is, int() discards any parts and keeps only the whole. The effect is the same (as rounding down), but the reason different.
int(), round() and // are all distict operations and have all got distict results.

math.floor is like the // operator, except for always returning a float:

i would really like to have switch (C++,C) in python.

in stead of using a long if.

Get ya perc! switch would be a nice addtion to Python as would incement and decrement operators (++ --) but since they've already been passed over a few times so i dont hold up much hope!

Mark.

There's a very clear reason why they don't allow ++ and --
Good design principles are where your modifiers and accessers are seperated.

num += 7 # <== modifier (ie modifying the variable)
print num # <== accesor (ie accessing the contents of num)
num2 = num # <== accesor (ie accessing the contents of num)

whereas the main use of ++ and -- is such that you can access and modify at the same time. Eg.

&nbsp;&nbsp;num2 = num++

is the same as

&nbsp;&nbsp;num2 = num1
&nbsp;&nbsp;num += 1

whereas

&nbsp;&nbsp;num2 = ++num

is the same as

&nbsp;&nbsp;num += 1
&nbsp;&nbsp;num2 = num1

This is confusing and seperation of modifiers and accessors ensures clearer code. And I definitely support that
_________________________________________________________________

Not sure why they don't have switch. I'm sure they have a good reason for that also. Possibly because if you don't break after the one you want, it falls through and excecutes all other statements

But look at the difference in code of each






The if-elif-else statment is safer in that you don't need to remember the break in each case, which happens soooo much. By dissallowing this you speed up development time due to reducing debugging.

This is pythons greatest feature and number one priority: Minimum development time
And it truly is one of (and I expect 'the') fastest development languages out there. Yet still allows powerful design of the system.

It's also more readable. Some people want it to fall through and execute more than one case in the switch, which makes for code that is very hard to understand what its doing. Again, python avoids this problem which is rampant in perl - confusing code.

Eli

Actually, FLNHST, Python does have a kind of switch using dictionaries.

def DoA(q): print q
def DoB(w): print w+1
def DoC(e): print 2*e

DispatchDict = {"a":DoA, "b":DoB, "c":DoC}

z = 1234

DispatchDict[raw_input("Enter a letter (a-c)")]()

"a", etc, being the cases, DoA, etc being the action to take, and the raw_input being which case you have. You could also have a "default" be enclosing the calling part in a try/except block and put the "default" action in the except block.

I love that functions are first class objects.
Thank you Python Cookbook!