Tricky Areas in Python

[Fredrik Lundh]

Sorry for skipping the 2nd argument to setFoo, that was accidental in my
post. The problem here is: class Sic is "classic" ("legacy",
"old-style") so property won't really work for it (the setter will NOT
trigger when you assign to s.foo and s is an instance of Sic).

what's slightly confusing is that the getter works, at least until you attempt
to use the setter:
.... def getFoo(self):
.... print "GET"
.... return "FOO"
.... def setFoo(self, value):
.... print "SET", value
.... foo = property(getFoo, setFoo)
....

GET
FOO

10

(a "setter isn't part of an new-style object hierarchy" exception would have
been nice, I think...)

</F>

 

[bruno modulix]

let me try.

1) ''.join(lots_of_pieces)

2) This doesn't even work, if something is removed, the list is too
short. So:
[x for x in somelist if not isbad(x)]
well, list comprehension is Python 2.4

2.2.x IIRC

and 2.3 is the standard in many
OSes, so it is possibly not the most portable solution

filter(isbad, somelist)

 

[=?ISO-8859-1?Q?Gerhard_H=E4ring?=]

2.2.x IIRC

List comprehensions were introduced in Python 2.0, according to the
"What's new in ..." document at
http://www.amk.ca/python/2.0/index.html#SECTION000600000000000000000

-- Gerhard

 

[Alex Martelli]

what's slightly confusing is that the getter works, at least until you attempt
to use the setter:

Oh yes, that IS definitely contributing to the confusion -- which is
part of why I think it makes sense to claim this is a "tricky area".

(a "setter isn't part of an new-style object hierarchy" exception would have
been nice, I think...)

Agreed. Alas, a bit too late now, I fear (until 3.0 when old-style goes
away) -- somebody might be (unwisely but "it-sort-of-works" style)
relying on this behavior. Hmmm, maybe a WARNING could be given...


Alex

 

[Alex Martelli]

What's the point of asking "tricky" questions? Aren't you really more
interested in what applications they have worked on and whether they were
successful?

Understanding exactly what contribution they did, to the applications
they worked on, may be even more important. After all, we've all seen
people who worked on app "X" and made a NEGATIVE net contribution to
"X"'s success, compensated by the far better efforts of others on the
team. But it's unlikely that the candidate will actually say "I worked
on X, but my grasp of the language was so feeble that in fact I made it
_worse_ than it would have been without me in the team";-).

I don't know. I'm not sure I need a job with a company that insists on
playing "Programming Jeopardy" during the interview.

I understand how some "quiz-like" questions may rub you the wrong way.
For questions such that knowing the answers is of little or no use on
the job I might even concur -- e.g., "On what exact date was Python 1.0
released" (even if the candidate claims to have been actively part of
that release, he might perfectly well misremember the date!-).

Others are iffier, e.g., "what are all the optional arguments to
built-in function 'open'" -- some people easily memorize those even if
they use them once in a blue moon, others look them up in 2 seconds
every time they need to with a "help(open)" on the interactive
interpreter prompt, so while the knowledge sure doesn't hurt it's not
very important. That's even truer for other functions and classes with
many more, and more obscure, optional arguments.

If I asked such a question in the course of a programming task, I would
consider "hmmm, there's an optional argument for that, I don't remember
it but in real life I'd look it up in a jiffy" perfectly acceptable (if
the candidate appears to have no idea that there IS an optional argument
for a cerrtain purpose, that's slightly less good, but no disaster).

But -- being presented with a flawed solution and asked to help debug it
(by identifying the "tricky issue" on which it fails) appears to me to
be perfectly acceptable. It IS the kind of task you face all the time
IRL, and checks how well you know the language and libraries...


Alex

 

[Bengt Richter]

what's slightly confusing is that the getter works, at least until you attempt
to use the setter:

... def getFoo(self):
... print "GET"
... return "FOO"
... def setFoo(self, value):
... print "SET", value
... foo = property(getFoo, setFoo)
...
10

(a "setter isn't part of an new-style object hierarchy" exception would have
been nice, I think...)

Hm, wouldn't that mean type(sic).__getattribute__ would have to look for type(sic).foo.__get__
and raise an exception (except for on foo functions that are supposed to be methods ;-)
instead of returning type(sic).foo.__get__(sic, type(sic)) without special casing to reject
non-function foos having __get__? I guess it could. Maybe it should.

BTW, I know you know, but others may not realize you can unshadow foo
back to the previous state:
GET
FOO

and that applies even if __delete__ is defined in the property:
... def getFoo(self):
... print "GET"
... return "FOO"
... def setFoo(self, value):
... print "SET", value
... def delFoo(self):
... print "DEL"
... foo = property(getFoo, setFoo, delFoo)
... GET
FOO GET
FOO

but it won't go beyond the instance for del foo
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: Sic instance has no attribute 'foo'

Regards,
Bengt Richter