On Tue, 25 Oct 2005 10:44:07 +0200, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>Alex Martelli wrote:
>
>>> my hard-won ignorance, and admit that I don't see the
>>> problem with the property examples:
>>>
>>> > class Sic:
>>> > def getFoo(self): ...
>>> > def setFoo(self): ...
Tim Roberts <[EMAIL PROTECTED]> wrote:
> "PyPK" <[EMAIL PROTECTED]> wrote:
> >
> >What possible tricky areas/questions could be asked in Python based
> >Technical Interviews?
>
> What's the point of asking "tricky" questions? Aren't you really more
> interested in what applications they have wor
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
>
> >> > class Sic:
> >> > def getFoo(self): ...
> >> > def setFoo(self): ...
> >> > foo = property(getFoo, setFoo)
> >
> > Sorry for skipping the 2nd argument to setFoo, that was accidental in my
> > post
bruno modulix wrote:
> beza1e1 wrote:
>>well, list comprehension is Python 2.4
>
> 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#SECTION00060
-- Gerhard
--
http://mail.py
beza1e1 wrote:
> 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 possib
Alex Martelli wrote:
>> my hard-won ignorance, and admit that I don't see the
>> problem with the property examples:
>>
>> > class Sic:
>> > def getFoo(self): ...
>> > def setFoo(self): ...
>> > foo = property(getFoo, setFoo)
>
> Sorry for skipping the 2nd argument to s
Alex Martelli wrote:
> No, LC goes back a long way -- I think it was in 2.0 already, 2.1 for
> sure.
$ python1.5 -c "print [x for x in 'abc']"
File "", line 1
print [x for x in 'abc']
^
SyntaxError: invalid syntax
$ python2.0 -c "print [x for x in 'abc']"
['a', 'b', 'c']
I w
Tim Roberts wrote:
> "PyPK" <[EMAIL PROTECTED]> wrote:
>>What possible tricky areas/questions could be asked in Python based
>>Technical Interviews?
>
> What's the point of asking "tricky" questions? Aren't you really more
> interested in what applications they have worked on and whether they wer
"PyPK" <[EMAIL PROTECTED]> wrote:
>
>What possible tricky areas/questions could be asked in Python based
>Technical Interviews?
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?
I don't know
beza1e1 <[EMAIL PROTECTED]> wrote:
> let me try.
>
> 1) ''.join(lots_of_pieces)
Yep.
> 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 and 2.3 is the standard in many
> OSes, so it
beza1e1 wrote:
> well, list comprehension is Python 2.4 and 2.3 is the standard in many
> OSes, so it is possibly not the most portable solution
You're probably remembering "generator expressions", which were added in
Python 2.4 and aren't available in earlier versions. They fit in a
similar pl
beza1e1 wrote:
> 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 and 2.3 is the standard in many
> OSes, so it is possibly not the most
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 and 2.3 is the standard in many
OSes, so it is possibly not the most portable solution
I had to look u
Alex Martelli wrote:
>
>>>class Base(object)
>>>def getFoo(self): ...
>>>def setFoo(self): ...
>>>foo = property(getFoo, setFoo)
>>>
>>>class Derived(Base):
>>>def getFoo(self):
>>
[snip]
> the solution, in Python 2.4 and earlier, is to use
> one extra
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
...
> my hard-won ignorance, and admit that I don't see the
> problem with the property examples:
>
> > class Sic:
> > def getFoo(self): ...
> > def setFoo(self): ...
> > foo = property(getFoo, setFoo)
Sorry for skipping t
Steven D'Aprano wrote:
> Those two are easy. However, and this is where I show
> my hard-won ignorance, and admit that I don't see the
> problem with the property examples:
>> class Base(object)
>> def getFoo(self): ...
>> def setFoo(self): ...
>> foo = property(getFoo
Steven D'Aprano wrote:
> Alex Martelli wrote:
> Those two are easy. However, and this is where I show my hard-won
> ignorance, and admit that I don't see the problem with the property
> examples:
>
>> class Base(object)
>> def getFoo(self): ...
>> def setFoo(self): ...
>>
Alex Martelli wrote:
> I like to present code that seems like it should work, but has some kind
> of relatively subtle problem, either of correctness in some corner case,
> or of performance, etc -- and I ask them what they would say if they
> were to code-review that code, or how they would help
PyPK wrote:
> hmm Thats one thing. Also I was thinking of something like benefites of
> python over other languages.
That's fairly context-dependant *and* subjective.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@
Andrew Durdin <[EMAIL PROTECTED]> wrote:
> On 10/24/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > I may branch out into more advanced stuff such as asking
> > for an example use case for a closure, a custom descriptor, or an import
> > hook, for example
>
> Isn't that approaching things from t
On 10/24/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
> I may branch out into more advanced stuff such as asking
> for an example use case for a closure, a custom descriptor, or an import
> hook, for example
Isn't that approaching things from the wrong angle? You're asking them
to synthesise a pro
PyPK <[EMAIL PROTECTED]> wrote:
> What possible tricky areas/questions could be asked in Python based
> Technical Interviews?
I like to present code that seems like it should work, but has some kind
of relatively subtle problem, either of correctness in some corner case,
or of performance, etc --
I usually start by asking how you make variables "private" within
classes. That seems to tell me if they understand something about the
design of the language and it's a quick filter to tell if they know
something about the syntax.
The other question that I use is asking about 3rd party libraries
hmm Thats one thing. Also I was thinking of something like benefites of
python over other languages. Probably that coould be one ?
--
http://mail.python.org/mailman/listinfo/python-list
PyPK wrote:
> What possible tricky areas/questions could be asked in Python based
> Technical Interviews?
I would try to check if the applicant understands the Python data model:
http://docs.python.org/ref/objects.html Because I thinkt that's
fundamental to understanding the Python language and
What possible tricky areas/questions could be asked in Python based
Technical Interviews?
--
http://mail.python.org/mailman/listinfo/python-list
26 matches
Mail list logo
