Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #58933 > unrolled thread

New user's initial thoughts / criticisms of Python

Back to article view | Back to comp.lang.python

Contents

  New user's initial thoughts / criticisms of Python John von Horn <j.h69@btinternet.com> - 2013-11-09 07:08 -0600
    Re: New user's initial thoughts / criticisms of Python Ned Batchelder <ned@nedbatchelder.com> - 2013-11-09 05:22 -0800
    Re: New user's initial thoughts / criticisms of Python Joshua Landau <joshua@landau.ws> - 2013-11-09 13:27 +0000
      Re: New user's initial thoughts / criticisms of Python Jonathan <jtcegh@gmail.com> - 2013-11-09 14:44 -0800
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 10:29 +1100
        Re: New user's initial thoughts / criticisms of Python MRAB <python@mrabarnett.plus.com> - 2013-11-10 00:50 +0000
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 11:54 +1100
        Re: New user's initial thoughts / criticisms of Python Neil Cerutti <neilc@norwich.edu> - 2013-11-11 15:30 +0000
      Re: New user's initial thoughts / criticisms of Python Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2013-11-10 13:24 +0100
    Re: New user's initial thoughts / criticisms of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-09 13:41 +0000
    Re: New user's initial thoughts / criticisms of Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-11-09 16:24 +0200
    Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 01:27 +1100
      Sandboxing Python [was Re: New user's initial thoughts / criticisms of Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-09 15:25 +0000
        Re: Sandboxing Python [was Re: New user's initial thoughts / criticisms of Python] Chris Angelico <rosuav@gmail.com> - 2013-11-10 02:32 +1100
      Re: New user's initial thoughts / criticisms of Python Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-11-10 08:47 +0000
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 20:22 +1100
        Re: New user's initial thoughts / criticisms of Python Ian Kelly <ian.g.kelly@gmail.com> - 2013-11-10 04:39 -0700
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 22:43 +1100
        Re: New user's initial thoughts / criticisms of Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-11-10 12:12 -0500
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-11 10:29 +1100
        Re: New user's initial thoughts / criticisms of Python Terry Reedy <tjreedy@udel.edu> - 2013-11-10 19:13 -0500
    Re: New user's initial thoughts / criticisms of Python rusi <rustompmody@gmail.com> - 2013-11-09 07:38 -0800
      Re: New user's initial thoughts / criticisms of Python Roy Smith <roy@panix.com> - 2013-11-09 10:56 -0500
        Re: New user's initial thoughts / criticisms of Python rusi <rustompmody@gmail.com> - 2013-11-09 08:30 -0800
          Re: New user's initial thoughts / criticisms of Python Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-10 21:36 -0800
            Re: New user's initial thoughts / criticisms of Python Roy Smith <roy@panix.com> - 2013-11-11 09:01 -0500
              Re: New user's initial thoughts / criticisms of Python rusi <rustompmody@gmail.com> - 2013-11-11 07:14 -0800
              Re: New user's initial thoughts / criticisms of Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-11-11 21:05 -0500
              Re: New user's initial thoughts / criticisms of Python Ethan Furman <ethan@stoneleaf.us> - 2013-11-12 14:38 -0800
    Re: New user's initial thoughts / criticisms of Python John von Horn <j.h69@btinternet.com> - 2013-11-09 14:19 -0600
    Re: New user's initial thoughts / criticisms of Python Tim Chase <python.list@tim.thechases.com> - 2013-11-09 14:39 -0600
    Re: New user's initial thoughts / criticisms of Python Mark Janssen <dreamingforward@gmail.com> - 2013-11-09 12:33 -0800
      Re: New user's initial thoughts / criticisms of Python Ned Batchelder <ned@nedbatchelder.com> - 2013-11-09 12:54 -0800
        Re: New user's initial thoughts / criticisms of Python Mark Janssen <dreamingforward@gmail.com> - 2013-11-09 13:21 -0800
    Re: New user's initial thoughts / criticisms of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-09 21:01 +0000
    Re: New user's initial thoughts / criticisms of Python Tim Chase <python.list@tim.thechases.com> - 2013-11-09 15:20 -0600
    Re: New user's initial thoughts / criticisms of Python lorenzo.gatti@gmail.com - 2013-11-11 02:09 -0800
      Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-11 21:39 +1100
        Re: New user's initial thoughts / criticisms of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-11 11:17 +0000
          Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-11 22:32 +1100
          Re: New user's initial thoughts / criticisms of Python Mark Janssen <dreamingforward@gmail.com> - 2013-11-11 14:29 -0800
      Re: New user's initial thoughts / criticisms of Python Robert Kern <robert.kern@gmail.com> - 2013-11-11 11:53 +0000
      Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-11 23:07 +1100
      Re: New user's initial thoughts / criticisms of Python Joshua Landau <joshua@landau.ws> - 2013-11-11 20:50 +0000
      Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-12 09:21 +1100
      Re: New user's initial thoughts / criticisms of Python Joshua Landau <joshua@landau.ws> - 2013-11-12 01:53 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#59034

On 11/10/2013 6:29 PM, Chris Angelico wrote:
> On Mon, Nov 11, 2013 at 4:12 AM, Dennis Lee Bieber
> <wlfraed@ix.netcom.com> wrote:
>>>>> -123 .bit_length()
>> -7
>>
>>          No parens needed if a space precedes the .
>
> Heh! I would call that an inferior alternative to the parentheses
> though; it's so unusual to put a space before the dot that I wouldn't
> consider it something to do in normal code. Anyone coming through and
> editing would see it as a mistake to be fixed.

I have only used int methods in interactive exploration, and have always 
used space. I have never used (), but agree that they are better for 
permanent code. The -7 is really nasty (unless one were to actually want 
that).

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#58954

On Saturday, November 9, 2013 6:38:25 PM UTC+5:30, John von Horn wrote:
> Another useful tool in the programmer's toolbox

> Select DayofWeek

> 	case "mon"

> 	...

> end select


You can typically write this in python as a dictionary

cases = {"mon": do_mon-action, 
         "tue", do_tue_action,
:
:        
}
combined with an 'interpreter'
cases[DayofWeek]()

Some variants:
Need a default?
cases.get(DayofWeek, do_default_action)()

Sometimes nicer to pass some parameters:
cases[DayofWeek](some_relevant_context)

[toc] | [prev] | [next] | [standalone]

#58955

In article <d15d9993-90f2-43bd-824f-a1df6b7a4556@googlegroups.com>,
 rusi <rustompmody@gmail.com> wrote:

> On Saturday, November 9, 2013 6:38:25 PM UTC+5:30, John von Horn wrote:
> > Another useful tool in the programmer's toolbox
> 
> > Select DayofWeek
> 
> > 	case "mon"
> 
> > 	...
> 
> > end select
> 
> 
> You can typically write this in python as a dictionary
> 
> cases = {"mon": do_mon-action, 
>          "tue", do_tue_action,
> :
> :        
> }
> combined with an 'interpreter'
> cases[DayofWeek]()
> 
> Some variants:
> Need a default?
> cases.get(DayofWeek, do_default_action)()
> 
> Sometimes nicer to pass some parameters:
> cases[DayofWeek](some_relevant_context)

All of the above is true, but a more straight-forward way to emulate a 
switch/case is with a series of elifs:

if day_of_week == "mon":
   print "mondays suck"
elif day_of_week == "tue":
   print "at least it's not monday"
elif day_of_week == "wed":
   print "humpday!"
else:
   print "it's some other day"

I've done both.  Both are reasonable translations of switch/case logic 
from other languages.

The elif chain is more straight-forward to understand, especially for 
somebody new to the language.  It also can support more complicated 
selection logic:

elif day_of_week in ['sat', 'sun']:
   print "it's the weekend"

John's version is more modular, and lends itself to doing more dynamic 
things like passing around sets of actions as function arguments.

[toc] | [prev] | [next] | [standalone]

#58956

On Saturday, November 9, 2013 9:26:02 PM UTC+5:30, Roy Smith wrote:
> In article rusi wrote:

> > On Saturday, November 9, 2013 6:38:25 PM UTC+5:30, John von Horn wrote:
> > > Another useful tool in the programmer's toolbox
> > > Select DayofWeek
> > > 	case "mon"
> > > 	...
> > > end select
> > You can typically write this in python as a dictionary
> > cases = {"mon": do_mon-action, 
> >          "tue", do_tue_action,
> > :
> > :        
> > }
> > combined with an 'interpreter'
> > cases[DayofWeek]()
> > Some variants:
> > Need a default?
> > cases.get(DayofWeek, do_default_action)()
> > Sometimes nicer to pass some parameters:
> > cases[DayofWeek](some_relevant_context)

> All of the above is true, but a more straight-forward way to emulate a 
> switch/case is with a series of elifs:

> if day_of_week == "mon":
>    print "mondays suck"
> elif day_of_week == "tue":
>    print "at least it's not monday"
> elif day_of_week == "wed":
>    print "humpday!"
> else:
>    print "it's some other day"

> I've done both.  Both are reasonable translations of switch/case logic 
> from other languages.

> The elif chain is more straight-forward to understand, especially for 
> somebody new to the language.  It also can support more complicated 
> selection logic:

Well

print ( {"mon":"mondays suck",
         "tue":"at least it's not monday",
         "wed":"humpday"
        }.get(day_of_week,"its some other day")
      )

may be dense

Separate into named dictionary and its ok (I think!)

[toc] | [prev] | [next] | [standalone]

#59049

On Saturday, November 9, 2013 10:30:26 AM UTC-6, rusi wrote:
> [...]
> Well
>
> print ( {"mon":"mondays suck",
>          "tue":"at least it's not monday",
>          "wed":"humpday"
>         }.get(day_of_week,"its some other day")
>       )
> may be dense
> Separate into named dictionary and its ok (I think!)

Proper code formatting can do WONDERS for readability!

## START CODE ##
d = {
    "mon":"mondays suck",
    "tue":"at least it's not monday",
    "wed":"humpday"
    }
default = "some other day"
target = "tue"
print d.get(target, default)
target = "blah"
print d.get(target, default)
## END CODE ##

Of course you could create something "reusable" and "interface-ee".

## START CODE ##
class UsageError(Exception):
    pass

class Case(object):
    def __init__(self, defaultDict=None, defaultValue=None):
        self.d = defaultDict or {}
        self.defaultValue = defaultValue

    def __str__(self):
        return "Case({0})".format(self.d)

    def __call__(self, key):
        try:
            v = self.d[key]
        except KeyError:
            v = self.defaultValue
        return v

    def __getitem__(self, k):
        raise UsageError("RTFS MAN!!!")

if __name__ == '__main__':
    import calendar
    d = {
        "mon":"mondays suck",
        "tue":"at least it's not monday",
        "wed":"humpday"
        }
    case = Case(d, "some other day")
    try:
        case["tue"]
    except UsageError:
        print 'Stopped improper useage.'
    print case
    lst = [s.lower() for s in calendar.weekheader(3).split(' ')]
    for dayName in lst:
        print "Case.__call__({0!r}) -> {1!r}".format(dayName, case(dayName))
## END CODE ##

[toc] | [prev] | [next] | [standalone]

#59075

> On Saturday, November 9, 2013 10:30:26 AM UTC-6, rusi wrote:

> > print ( {"mon":"mondays suck",
> >          "tue":"at least it's not monday",
> >          "wed":"humpday"
> >         }.get(day_of_week,"its some other day")
> >       )

In article <8618d47d-518c-4f35-a879-57fad7525411@googlegroups.com>,
 Rick Johnson <rantingrickjohnson@gmail.com> wrote:
> Proper code formatting can do WONDERS for readability!
> 
> d = {
>     "mon":"mondays suck",
>     "tue":"at least it's not monday",
>     "wed":"humpday"
>     }
> default = "some other day"
> target = "tue"
> print d.get(target, default)
> target = "blah"
> print d.get(target, default)

I agree that Rick's version is better than rusi's version, but possibly 
not for the the reason Rick thinks it is :-)  rusi's version has a 
"parsing surprise" in it.  As a human scans the code, the thought 
process goes something like this:

> > print ( {"mon":"mondays suck",

"OK, I'm going to print a dictionary"

> >          "tue":"at least it's not monday",

"Yeah, still looks like I'm printing a dictionary"

> >          "wed":"humpday"

"Yeah, more dictionary, this still makes sense, I'm just waiting to get 
to the and of the dictionary so I can print it"

> >         }.get(day_of_week,"its some other day")

"Oh, my!  I'm not printing a dictionary after all!  I'm doing a get() on 
it!"

> >       )

"Ugh, what's this close paren?  Does it terminate the get(), or the 
print()?  I need to go back and count open parens to make sure"

[toc] | [prev] | [next] | [standalone]

#59081

On Monday, November 11, 2013 7:31:07 PM UTC+5:30, Roy Smith wrote:
> > On Saturday, November 9, 2013 10:30:26 AM UTC-6, rusi wrote:

> > > print ( {"mon":"mondays suck",
> > >          "tue":"at least it's not monday",
> > >          "wed":"humpday"
> > >         }.get(day_of_week,"its some other day")
> > >       )

>  Rick Johnson  wrote:
> > Proper code formatting can do WONDERS for readability!
> > d = {
> >     "mon":"mondays suck",
> >     "tue":"at least it's not monday",
> >     "wed":"humpday"
> >     }
> > default = "some other day"
> > target = "tue"
> > print d.get(target, default)
> > target = "blah"
> > print d.get(target, default)

> I agree that Rick's version is better than rusi's version, but possibly 
> not for the the reason Rick thinks it is :-)  rusi's version has a 
> "parsing surprise" in it.  As a human scans the code, the thought 
> process goes something like this:

Yes I did not like my own version for similar reason: I expect the
switch order (classic C) to be
1. expression
2. body
3. default

The following does not quite do it but is it better?

def switch(val, default, body_dict):
    return body_dict.get(val,default)

day=...
switch(day,  "something else",
             {"mon"  : "mondays suck",
              "tue"  : "at least it's not monday",
              "wed"  : "humpday"
             }
      )

Of course one can flip the body and the default but I find that looks more confusing.

[toc] | [prev] | [next] | [standalone]

#59143

On Mon, 11 Nov 2013 09:01:07 -0500, Roy Smith <roy@panix.com> declaimed the
following:


>"Ugh, what's this close paren?  Does it terminate the get(), or the 
>print()?  I need to go back and count open parens to make sure"

	No... You need to use an editor/IDE that will highlight the matching
parens for you...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#59249

On 11/11/2013 06:05 PM, Dennis Lee Bieber wrote:
> On Mon, 11 Nov 2013 09:01:07 -0500, Roy Smith <roy@panix.com> declaimed the
> following:
>
>
>> "Ugh, what's this close paren?  Does it terminate the get(), or the
>> print()?  I need to go back and count open parens to make sure"
>
> 	No... You need to use an editor/IDE that will highlight the matching
> parens for you...

I have one of those, and I still sometimes miss one.  :/

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#58962

On Sat, 09 Nov 2013 07:08:25 -0600, John von Horn wrote:

Thanks so much for the replies. I'll get my head down and keep on going. 
Sometimes it's great to be wrong. I have a good feeling about this 
language. It's also nice that I can tap into this pool of knowledge that 
is comp.lang.python - I'll be heading down to that watering hole on a 
regular basis. *Help, Help - the python's got me, I've been ambushed*

And a "thank you" [guys] - alright!

My next program:

print 'And a '"thank you"' [guys] to the screen, expanding the list of 
guys to their individual names that have replied to my opening comment.
displayed as a comma delimited list.

Time to say "goodbye" to "Hello World" and take it to the next level. 
First floor, here I come.

We are on a mission! I'm lovin' it.

JvH

[toc] | [prev] | [next] | [standalone]

#58963

On 2013-11-10 01:27, Chris Angelico wrote:
> > Is everyone happy with the way things are? Could anyone recommend
> > a good, high level language for CGI work? Not sure if I'm going
> > to be happy with Perl (ahhh, get him, he's mentioned Perl and is
> > a heretic!) or Python. I would very much value any constructive
> > criticism or insights.  
> 
> If by CGI you actually literally mean CGI, then most of us don't
> have any experience with it.

While there might be some die-hards in the group that would accuse
you (the OP) of heresy, most folks here are pragmatics that will shrug
and reply "if {Perl,PHP,Ruby,Pike,JavaScript,...} solves your problem,
go for it.  We just can't help you much unless it's Python".  Much
like I'm a vi/vim guy, but if emacs/Sublime/notepad/nano/ed/edlin/cat
works for you, then go for it.

Most of the major frameworks *can* be run as CGI (rather than FastCGI
or WSGI), but performance is usually abysmal because the entire
program is restarted for each request (whereas FCGI/WSGI have
long-running processes that exact the spin-up cost once).  It's more
of a party trick or proof-of-concept than anything you'd want to put
into high-traffic production. Django[1], CherryPy[2], Flask[3],
web.py[4], web2py[5] all support deploying in a CGI environment (it
looks like Pylons/Pyramid might too, but I couldn't scare up a link
for explicit directions).

I'm personally partial to Django because it offers so much out of
the box, but I've done work in a couple of the others too (doing some
CherryPy contract work currently).

-tkc

[1] http://joemaller.com/1467/django-via-cgi-on-shared-hosting/

[2] http://tools.cherrypy.org/wiki/RunAsCGI

[3] http://flask.pocoo.org/docs/deploying/cgi/

[4] http://webpy.org/cookbook/cgi-apache

[5] http://web2py.com/book/default/chapter/13

[toc] | [prev] | [next] | [standalone]

#58964

A little late, but a couple of cents worth more data:

> I've just got a few thoughts I'd like to share and ask about:
>
> * Why not allow floater=float(int1/int2) - rather than floater=float
> (int1)/float(int2)?

This has to do with evaluation order, the stuff inside the parens gets
evaluated first, resulting in an integer for versions of python less
than v3.

> Give me a float (or an error message) from evaluating everything in the
> brackets. Don't make me explicitly convert everything myself (unless I
> want to)

You only have to give one float value:  int1/float(int2).  The
environment converts it to a floating point operation when either of
the two is a float value.  (try:  1/2.0, for example)

> * No sign of a select .. case statement
>
> Another useful tool in the programmer's toolbox

I agree on this one, though I prefer C's syntax of switch/case.  The
if/then/elif "ladder" of python is a bit cumbersome, but was chosen to
reduce language size -- a value with mixed reviews.

> * Call me pedantic by why do we need a trailing comma for a list of one
> item? Keep it intuitive and allow lstShopping=[] or ["Bread"] or
> ["Bread", "Milk","Hot Chocolate"] I don't like ["Bread",]. It bugs me.

This one got answered, it has to do with the parser when dealing with parens.

> Is everyone happy with the way things are?

No, but Python is still the best language.

> Could anyone recommend a good,
> high level language for CGI work? Not sure if I'm going to be happy with
> Perl (ahhh, get him, he's mentioned Perl and is a heretic!) or Python.

Personally, I wouldn't recommend Python for web scripts.  But I'm
biased and am speaking from where I see the field of computer
languages heading.

MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#58965

On Saturday, November 9, 2013 3:33:30 PM UTC-5, zipher wrote:
> Personally, I wouldn't recommend Python for web scripts.  But I'm
> biased and am speaking from where I see the field of computer
> languages heading.
> 
> MarkJ
> Tacoma, Washington

I'd be interested to hear your thoughts on where the field of computer languages is heading, and how that affects the choice of languages for building web sites.

--Ned.

[toc] | [prev] | [next] | [standalone]

#58968

> I'd be interested to hear your thoughts on where the field of computer languages is heading, and how that affects the choice of languages for building web sites.

Well, there aren't that many groupings towards which languages
specialize for (not including embedded or other application-specific
domains).  There's OS scripting, Web scripting, and then the otherwise
general-purpose "normative" languages in the middle of those two
extremes.  But this view presumes a model of computation which hasn't
settled into wide agreement.
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#58966

On 09/11/2013 20:33, Mark Janssen wrote:
>
>> * Call me pedantic by why do we need a trailing comma for a list of one
>> item? Keep it intuitive and allow lstShopping=[] or ["Bread"] or
>> ["Bread", "Milk","Hot Chocolate"] I don't like ["Bread",]. It bugs me.
>
> This one got answered, it has to do with the parser when dealing with parens.
>

It got answered and was simply mistaken, no comma is needed but a comma 
will be accepted.  How did the parser enter into this, or are you also 
thinking about tuples?

 >>> mylist=['Bread']
 >>> mylist
['Bread']
 >>> mylist=['Butter',]
 >>> mylist
['Butter']

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#58967

On 2013-11-09 21:01, Mark Lawrence wrote:
> no comma is needed but a comma  will be accepted. 

I find the optional trailing comma particularly useful (and painful in
languages that don't accept it) for doing inline lists to produce
cleaner version-control diffs.  I write most of my code like this
(with a trailing comma):

  lst = [
    "one",
    "two",
    "three",
    ]

so when I go to add something, the diff looks much more readable like

     "two",
     "three",
+    "four",
     ]

instead of

     "two",
-    "three"
+    "three",
+    "four"
     ]

which makes me look at all of the modified lines to validate exactly
what did (and didn't) change.

-tkc

[toc] | [prev] | [next] | [standalone]

#59060

Regarding the "select" statement, I think the most "Pythonic" approach is using dictionaries rather than nested ifs. 
Supposing we want to decode abbreviated day names ("mon") to full names ("Monday"):
day_abbr='mon'

day_names_mapping={
    'mon':'Monday',
    'tue':'Tuesday',
    'wed':'Wednesday',
    'thu':'Thursday',
    'fri':'Friday',
    'sat':'Saturday',
    'sun':'Sunday'
    }
try:
    full_day_name=day_names_mapping[day_abbr.casefold()]
except KeyError:
    raise GoodLuckFixingItException('We don't have "'+day_abbr+'" in our week')

This style is more compact (usually one line per case) and more meaningful (generic processing driven by separate data) than a pile of if statement, and more flexible: 

full_day_names=('Monday','Tuesday','Wednesday','Thursday','Friday','Saturday','Sunday')
day_names={x.casefold()[0:3] : x for x in full_day_names}
#

A dict can also contain tuples, lists, and nested dicts, consolidating multiple switches over the same keys and organizing nested switches and other more complex control structures.

[toc] | [prev] | [next] | [standalone]

#59061

On Mon, Nov 11, 2013 at 9:09 PM,  <lorenzo.gatti@gmail.com> wrote:
> Regarding the "select" statement, I think the most "Pythonic" approach is using dictionaries rather than nested ifs.
> Supposing we want to decode abbreviated day names ("mon") to full names ("Monday"):

That's an obvious mapping, though. If you're using a select/switch
statement to handle straight-forward one-to-one mappings, then yes,
obviously the better way to do it is to use a dictionary. In the more
general sense, a switch/case block is much more directly translated
into if/elif/else statements. You can't, for instance, build up a
dictionary that handles inequalities, but you can do that with elif.

That is, normally you can't. I have occasionally built up mappings
that handle inequalities - it's a form of denormalization. Consider
the following logic:

A 'minor weapon' is based on a roll of a 100-sided dice. If it's 01 to
70, "+1 weapon: 2,000gp [weapon]"; if it's 71 to 85, "+2 weapon:
8,000gp [weapon]"; if 86 to 90, "Specific weapon [minor specific
weapon]"; and if 91 to 100, "Special ability [minor special weapon]
and roll again".

My code to handle that starts out with this array:

"minor weapon":({
    70,"+1 weapon: 2,000gp [weapon]",
    85,"+2 weapon: 8,000gp [weapon]",
    90,"Specific weapon [minor specific weapon]",
    100,"Special ability [minor special weapon] and roll again",
}),

(that's Pike; in Python it'd be a list, or maybe a tuple of tuples),
and denormalizes it into a lookup table by creating 70 entries quoting
the first string, 15 quoting the second, 5, and 10, respectively. So,
with a bit of preprocessing, a lookup table (which in this case is an
array (list), but could just as easily be a dict) can be used to
handle inequalities. But this is because lookup tables can be treated
as data, where if/elif/else blocks have to be code; there are roughly
42 million such lookup tables in the code I snagged that from, and
having code for each one would work out far less manageable. Normally,
you'll want to render inequalities with code as if/elif.

ChrisA

[toc] | [prev] | [next] | [standalone]

#59064

On Mon, 11 Nov 2013 21:39:27 +1100, Chris Angelico wrote:

> My code to handle that starts out with this array:
> 
> "minor weapon":({
>     70,"+1 weapon: 2,000gp [weapon]",
>     85,"+2 weapon: 8,000gp [weapon]",
>     90,"Specific weapon [minor specific weapon]", 100,"Special ability
>     [minor special weapon] and roll again",
> }),
> 
> (that's Pike; in Python it'd be a list, or maybe a tuple of tuples), and
> denormalizes it into a lookup table by creating 70 entries quoting the
> first string, 15 quoting the second, 5, and 10, respectively.

Ewww :-(

Imagine having to print out the dict looking for an error in the lookup 
table. Or imagine the case where you have:

0...20000: do this
20001...890001: do that
890001...890003: do something else

Don't get me wrong, it's a clever and reasonable solution for your 
specific use-case. But I'd much rather have a lookup table variant that 
matches on intervals.

Hmmm... if you had an interval data type, which was hashable, that would 
probably be trivial... what am I missing? Ah, of course, what I'm missing 
is that although you're storing intervals as the keys, you're matching 
regular ints.

I wonder if this would be a good use-case for Antoine Pitrou's 
TransformDict?

http://www.python.org/dev/peps/pep-0455/


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#59067

On Mon, Nov 11, 2013 at 10:17 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 11 Nov 2013 21:39:27 +1100, Chris Angelico wrote:
>> denormalizes it into a lookup table by creating 70 entries quoting the
>> first string, 15 quoting the second, 5, and 10, respectively.
>
> Ewww :-(
>
> Imagine having to print out the dict looking for an error in the lookup
> table. Or imagine the case where you have:
>
> 0...20000: do this
> 20001...890001: do that
> 890001...890003: do something else
>
> Don't get me wrong, it's a clever and reasonable solution for your
> specific use-case. But I'd much rather have a lookup table variant that
> matches on intervals.

Of course it's "Ewww" in isolation :) But just imagine there are piles
and piles of these tables, themselves keyed by keyword, and I want to
be able to let untrusted people create tables (which means they
basically have to be data, not code). Also, bear in mind, all the
tables are based around dice that can be physically rolled, so none
has more than 100 entries after denormalization. Quite a lot of the
tables actually have unique entries per value (eg it's a d10 roll,
with ten unique outputs), so it's simplest to just turn all the tables
into that format; that way, the main code needs worry about one type
only, and the preprocessor handles the denormalization.

And if there's an error in the lookup table, well, you look at the
normalized version, not at the one that actually gets parsed :) That's
basically like looking back at the Python source code rather than the
disassembled byte-code; apart from actually debugging the preprocessor
itself (which can be done with a ten-entry table that's easily
eyeballed), the denormalized version needn't be looked at by a human.

But this is a very VERY specific situation. Normally it's best to just
use an if/elif block. That's why this looks so "Ewww". :)

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web