Arc Forumnew | comments | leaders | submit | EliAndrewC's commentslogin
4 points by EliAndrewC 6273 days ago | link | parent | on: Two brief ideas

This is a little nit-picky, but the canonical way of checking for the existence of a key in a Python dictionary is

    if "username" in some_dict:
        ...

-----

1 point by bayareaguy 6273 days ago | link

Even since this started to work, I still prefer some_dict.has_key("username") because then if an ordinary string accidently found its way into some_dict I'd get a runtime error instead of a silent logic bug.

-----

1 point by ivankirigin 6273 days ago | link

Yah, and I usually just try to grab it, with a default value. Both these options are fine:

  some_dict.get("username", "default")
or

  try:
    u = some_dict["username"]
  except KeyError:
    # long error case code if needed

-----

1 point by akkartik 6273 days ago | link

Gahd, I can never remember that.

-----


If I were using Python and CherryPy then I'd say something like:

    class Root:
        def form(self):
          return render("form.html")
        
        def link(self, foo):
          cherrypy.session["foo"] = foo
          return render("link.html")
        
        def message(self):
          data = {"foo": cherrypy.session["foo"]}
          return render("message.html", data)
Obviously I'd need to write three templates for the three pages.

This is a neat example, since it shows how terse Arc can be. I'd be interested to see how well this scales to a large site. For example, I normally like keeping my HTML and Python code separate, so that when I have thousands of lines of each, it's easier to sift through it all and find what I'm looking for. However, if my code were consistently this much shorter, then that wouldn't be as necessary.

-----

1 point by EliAndrewC 6275 days ago | link | parent | on: Optional Parenthesis

Exactly so, thank you. I've since Googled to find how to do code formatting, so I shouldn't have this problem in the future. Thanks for posting the correct code.

-----

2 points by EliAndrewC 6276 days ago | link | parent | on: Optional Parenthesis

Well I agree that we should only omit parens where it's 100% unambiguous where the actual parens would be. There'd need to be a very small number of simple rules/exceptions (such as "every new level of indentation denotes an extra parenthesis unless ____").

A few years ago Paul Graham seemed to think this would work. However, it may be that he tried it and found that it would be too problematic. I'm hoping that he simply has been too busy to implement it so far.

-----

2 points by EliAndrewC 6276 days ago | link | parent | on: Optional Parenthesis

Right; my impression was always that Arc would basically just insert the parens for you on every level of indentation.

-----

2 points by roger_purves 6276 days ago | link

On "code should be written to read":

I like scheme a lot; and the parentheses never bothered me. But one device which could provide a gradual path through the thicket of parentheses, and perhaps make Arc more inviting to beginners, would be the:

        hide/show invisibles
of word processors. There could even be levels:

       hide/show some invisibles
       hide/show more invisibles
       hide/show all invisibles
Roger Purves

-----

1 point by EliAndrewC 6276 days ago | link

Yeah, personally I don't really care whether this is even a language feature or an editor feature. The ability to hide/show more or fewer is certainly interesting.

-----

2 points by EliAndrewC 6277 days ago | link | parent | on: Optional Parenthesis

Since the indentation didn't come through, here's a link to what it should look like:

http://pastebin.com/f4a6cfbd6

As for parens not mattering, I agree that they don't matter all that much when the code is being written due to editors taking care of it. But I find that the code that uses whitespace to replace some parens to be much more readable.

-----