Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2003
    Posts
    325
    Rep Power
    12

    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:
    Code:
    def fn(self, int num, object):
       pass
    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
  2. #2
  3. Hello World :)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2003
    Location
    Hull, UK
    Posts
    2,537
    Rep Power
    69
    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.
    programming language development: www.netytan.com Hula

  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2003
    Posts
    25
    Rep Power
    0
    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
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2003
    Posts
    325
    Rep Power
    12
    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
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Posts
    133
    Rep Power
    12
    Why not use the new division syntax right now?
    Code:
    from __future__ import division
    Look at PEP 238 -- Changing the Division Operator.
  10. #6
  11. Hello World :)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2003
    Location
    Hull, UK
    Posts
    2,537
    Rep Power
    69
    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..

    Code:
    >>> 1.0/2.0
    0.5
    >>>
    Mark.
    Last edited by netytan; December 19th, 2003 at 07:22 AM.
    programming language development: www.netytan.com Hula

  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Posts
    133
    Rep Power
    12
    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?
  14. #8
  15. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2003
    Posts
    325
    Rep Power
    12
    Originally posted by percivall
    Why not use the new division syntax right now?
    Code:
    from __future__ import division
    Look at PEP 238 -- Changing the Division Operator.

    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
  16. #9
  17. Hello World :)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2003
    Location
    Hull, UK
    Posts
    2,537
    Rep Power
    69
    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.
    programming language development: www.netytan.com Hula

  18. #10
  19. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Posts
    133
    Rep Power
    12
    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.
    Code:
    >>> -1. / 2
    -0.5
    >>> int(-1. / 2)
    0
    >>> round(-1. / 2)
    -1.0
    >>> -1 / 2
    -1
    >>> from __future__ import division
    >>> -1 / 4
    -0.25
    >>> int(-1 / 4)
    0
    >>> -1 // 4
    -1
    >>> round(-1 / 4)
    -0.0
    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:
    Code:
    >>> from __future__ import division
    >>> -1 / 2
    -0.5
    >>> -1 // 2
    -1
    >>> math.floor(-1 / 2)
    -1.0
    Last edited by percivall; December 19th, 2003 at 01:32 PM.
  20. #11
  21. No Profile Picture
    404 Error
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Location
    http://hester.dns2go.com
    Posts
    18
    Rep Power
    0
    i would really like to have switch (C++,C) in python.

    in stead of using a long if.
  22. #12
  23. Hello World :)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2003
    Location
    Hull, UK
    Posts
    2,537
    Rep Power
    69
    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.
    programming language development: www.netytan.com Hula

  24. #13
  25. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2003
    Posts
    325
    Rep Power
    12
    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

    Code:
    switch (var): # if it was in python syntax
      case 1:
        # do something
        # break
      case 2:
        # do something
        # break
      default:
        # do something
        # break
    Code:
    if var=1:
        # do something
    elif var=2:
        # do something
    else:
        # do something

    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
  26. #14
  27. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2003
    Posts
    25
    Rep Power
    0
    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!
    Last edited by TheBlackMamba; December 20th, 2003 at 03:41 AM.
  28. #15
  29. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2003
    Posts
    325
    Rep Power
    12
    Yea it's cool that you can pass around functions (and even classes which you can intantiate then).

    But still seems a little hacky.
    I prefer the if-elif-else statements inplace of switch statements
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo