(completely on the programming side)
I haven't mastered it, but there seems to be an art to testing your type
assumptions early in Python.
For example, if you are expecting to be passed in a list that you're going
to append to, or some compatible duck type, you might add a statement to
the top of your function:
def f(l):
append = l.append
...
append(v)
at the top of your code. If you get some other incompatible type, it fails
early rather than in the bowels of your program. These kinds of things
really help you to be productive and safe in a duck-typing world.
On 4 September 2013 10:04, Javier Candeira <jav...@candeira.com> wrote:
> On Wed, Sep 4, 2013 at 9:37 AM, dan <dan.pe...@gmail.com> wrote:
> > Slightly off topic but don't worry you're not the only one who finds it
> > daunting:
> >
> http://www.abc.net.au/news/2013-08-29/preference-deals-could-benefit-micro-parties-at/4920822
> >
> > It's obviously broken and needs to be fixed but awesome that there's a
> tool
> > to help work around it in the interim.
>
> Trying to keep the offtopic on-topic, there is an interesting
> parallell between the cognitve loads associated with preferential
> voting and the type of direct democracy practiced in California (where
> they have many ballots at each election for with particular laws or
> "initiative") and the micromanaging of types, access modifiers etc. in
> enterprisey languages such as Java.
>
> There are tradeoffs everywhere. More control means more mental load.
> Lower mental load means less control. Coming from a country where
> Parliament is picked by closed lists, I appreciate the added control
> of preference ranking for Parliament here. But it certainly adds a
> mental toll.
>
> Coming from a language like Python 2, some people appreciate type
> annotations in Python 3, so they don't have to perform guards in their
> code at runtime.
>
> At Monash we're already running our first semester of Data Structures
> and Algorithms using Python instead of Java. I'm now translating
> sample code for students's pracs, and I find myself having to decide
> at every point whether to let some type errors (like comparisons of
> uncomparables types) pass to be caught by the Python runtime, or to
> catch them and do something myself. All of those are errors that would
> be caught by the Java compiler.
>
> It's interesting to see the student forums, because most of the errors
> the students get stuck at are type errors (looking at a Node object
> instead of extracting the item, assigning a variable from a function
> that returns None), and all of those would have been previously caught
> by their IDE. Now they have do debug on the run, and use their brain
> instead of leveraging better tools.
>
> Tradeoffs.
>
> J
> _______________________________________________
> melbourne-pug mailing list
> melbourne-pug@python.org
> https://mail.python.org/mailman/listinfo/melbourne-pug
>
_______________________________________________
melbourne-pug mailing list
melbourne-pug@python.org
https://mail.python.org/mailman/listinfo/melbourne-pug
