I think it's better to use
def (L):
assert isinstance(L, list)
...
This has a few of advantages.
You can remove the overhead by running with "python -O".
IDEs such as wingide use it as a helper for type inference.
Just checking that there is an append attribute really doesn't reassure me
that it's even a method.
PEP8 strongly discourages using l as a variable name
John La Rooy
On Wed, Sep 4, 2013 at 10:31 AM, Lars Yencken <[email protected]> wrote:
> (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 <[email protected]> wrote:
>
>> On Wed, Sep 4, 2013 at 9:37 AM, dan <[email protected]> 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
>> [email protected]
>> https://mail.python.org/mailman/listinfo/melbourne-pug
>>
>
>
> _______________________________________________
> melbourne-pug mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/melbourne-pug
>
>
_______________________________________________
melbourne-pug mailing list
[email protected]
https://mail.python.org/mailman/listinfo/melbourne-pug
