Arc Forumnew | comments | leaders | submitlogin
1 point by ivankirigin 6169 days ago | link | parent

1. It's a toy problem, I get it. But how much information is conveyed?

I suppose you could call any library from any language with enough leg work, but it is easier and shorter in the same language. Python talks to C very easily, and there is an IMMENSE number of C libraries. OpenCV is an excellent, open-source computer vision toolkit that already have python bindings. My point is that the programmers using a language will benefit greatly from a community of people building tools that can easily be used in that language.

2. At times, making things explicit is easier to read. After I finish my current project, I'll learn Arc and see. It's just really nice sometimes to say

  if aPythonDictionary.has_key("username"):
    ...


4 points by EliAndrewC 6169 days ago | link

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 6169 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 6169 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 6169 days ago | link

Gahd, I can never remember that.

-----

1 point by greatness 6169 days ago | link

Are you suggesting:

  (if (arctable "username") ... )
is somehow difficult to read? (arguable, this is an arctable and not a dictionary which is closer to an associated-list. If it were an associated-list you'd be able to do it as either:

  (if (assoc "username" arc-alist) ... )
or

  (if (alref arc-alist "username") ... )
I'd hardly call any of these difficult to understand; though perhaps assoc would make more sense if the list were the first parameter and the key the second like the alref works. i.e.

  (assoc list key)
rather than:

  (assoc key list)
Because at the minute alref and assoc are not conforming to the same standards, which make them rather awkward to use.

-----

1 point by ivankirigin 6169 days ago | link

I'm not suggesting anything about a language I don't know :)

But, the point about explicitness stands, as there is not something similar to "has_key" in the syntax in your examples.

-----

1 point by greatness 6169 days ago | link

True, but the returns are more useful (assuming has_key returns T if it has the key. I am unfamiliar with python I'm afraid).

If the current syntax is difficult to memorize, you could always write a simple function which abstracts it away into something you're more familiar with:

  (def haskey (ls key) (alref ls key))
Then you can use it:

  (if (haskey mylist "username") ... )

-----