an Oostrum <[EMAIL PROTECTED]> wrote:
>>>>>> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>
>>AP> When someone gets confused over the difference between rebinding or
>>AP> mutating a variable on an intermediate scope, the explanation he
>>AP
#x27;b'] = t['b'] + [1]
__getitem__, key = b
__setitem__, key = b
>>> t['b'] += [2]
__getitem__, key = b
__setitem__, key = b
So to me it seems that when we substitute t['a'] or t['b'] for x,
x is evaluated twice with the augmented version, just like it
is with the not augmented version.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-07-10, Jim Segrave <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>On 2006-07-09, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>> Frank Millman wrote:
>>>
>>>>
On 2006-07-10, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> I disagree. The += version only evaluates the index once, but still has
>> to find the object twice.
>
> No i
for all callables .
> If not, this may be improved in the future.
>
>>> Antoon Pardon
>>> Is there a chance this will be reconsidered?
>
> The items in PEP 3100 have different levels of certainly. Some may even
> get changed after experience with the alpha version
ion), the name is void.
I'm not so sure about that. Local functions can be returned and they
keep their name. Of course it depends on what you mean with the
name of an object. Do you mean the variable name or do you mean
the __name__ attribute?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ime and not really "the
>> Python way"?
>>
>> -- Arcadio
>
> Generally asserts should be used to "enforce" invariants of your code
> (as opposed to typechecking), or to check certain things while
> debugging.
I don't understand this argument. Can't type checking be seen as
enforcing a code invariant?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-08-28, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-08-25, Simon Forman <[EMAIL PROTECTED]> wrote:
>>> ...
>>> Generally asserts should be used to "enforce" invariants of your code
>>> (as
On 2006-08-28, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> There seem to be enough problems that work with ints but not with
>> floats. In such a case enforcing that the number you work with
>> is indeed an int seems fully appropiate.
>
&g
On 2006-08-29, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> At Tuesday 29/8/2006 01:28, Antoon Pardon wrote:
>
>> > Antoon Pardon wrote:
>> >> There seem to be enough problems that work with ints but not with
>> >> floats. In such a case enforcing tha
On 2006-08-29, Simon Forman <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-08-28, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> > Antoon Pardon wrote:
>> >> There seem to be enough problems that work with ints but not with
>> >>
On 2006-08-29, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> At Tuesday 29/8/2006 02:45, Antoon Pardon wrote:
>
>> >>That may be true. But one may wonder if this is a failing of the
>> >>programmer or a failing of the language that doesn't support
>>
g.
In Python there should be one obvious way of doing something. Preferably
this is the only obvious way.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
d write
sequence classes as follows:
class Seq(object):
...
def __getitem__(self, index):
index = int(index)
...
def __setitem__(self, index, value):
index = int(index)
...
I don't know about you but I personally think this is overkill.
I would also
On 2006-08-29, Steve Holden <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-08-29, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>>
>>>At Tuesday 29/8/2006 02:45, Antoon Pardon wrote:
>>>
>>>
>>>>>>That may be tr
ctice by CPython users that relies on the GC to close the
>> db conn.
>
> This point is unrelated to with or ref-counting. Even the standard
> library will close file objects when they are GC'd.
This is not totally true. My experience is that if you use the
tarfile module any
others.
>>
>> Is Python 3k going to fix this sort of thing?
>
> Nope. PEP 3099 (which lists changes that won't be made in Python
> 3000), states that the Python grammar will not be more complex than
> LL(1), and says that simple grammars are more desirable than complex
> ones. There is no hope of this being "fixed".
This idea won't make python more complex than LL(1).
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-09-13, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> This is just an idea of mine, nothing I expect python to adapt.
>> But just suppose the language allowed for words in bold. A word
>> in bold would be considered a res
On 2006-09-13, Paul Rubin wrote:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> This is just an idea of mine, nothing I expect python to adapt.
>> But just suppose the language allowed for words in bold. A word
>> in bold would be considered a reserved word, a word
ould look like crap too. Yes some decisions can cause
some tools to be less usefull. I would say that the right cause
of action is then to adapt those tools. Not to let something like
that stop your decision.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
urn up some old terminal where
you can only type uppercase letters. What if under certain circumstance
I would be forced, to use this old thing. Would I then have a rightfull
complaint against python because it is case significant?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-09-14, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Sep 2006 07:45:02 +, Antoon Pardon wrote:
>
>>>> This is just an idea of mine, nothing I expect python to adapt.
>>>> But just suppose the language allowed for words in bold.
On 2006-09-26, John Roth <[EMAIL PROTECTED]> wrote:
>
> Antoon Pardon wrote:
>>
>> I find this a bit oddly worded. Now the "may always reuse" phrase
>> suggests this is not an obligation and I can certainly understand
>> that in the case of integers.
n the case of integers. But when you enumerate examples you
include None and Booleans, creating the suggestion these don't
have to be implemented as singletons either and that there can be
more than one None, True and False object. Now I probably just
misunderstand, but I'm wondering
using Top in such a way should behave so
too. However I don't see a way of doing that.
So can someone provide ideas to get this behaviour?
If not is there a chance that PEP 326 gets revived?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-09-27, Peter Otten <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> I had written my own module, which works similarly but
>> is somewhat extended. Here is an example of how it can
>> be used and how I would like to use it but get stuck.
>>
On 2006-09-27, Paul McGuire <[EMAIL PROTECTED]> wrote:
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> On 2006-09-27, Peter Otten <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon wrote:
>>>
>>>> I
On 2006-09-27, George Sakkis <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> What bothers me a bit about the rejection of PEP 326 is that one of the
>> reasons stated is:
>>
>> http://mail.python.org/pipermail/python-dev/2004-January/042306.html
>>
On 2006-09-27, OKB (not okblacke) <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> To begin with this already fails:
>>
>>>>> for i in xrange(Top):
>> ... print i
>
> What do you expect this to do? Loop forever?
Yes that is what I
...and then you time your instruction cycles and your disk reads
> so they fall under the read-head at just the right time... [*]
>
> [*] http://www.catb.org/jargon/html/story-of-mel.html
There is no reason to compare what I propose to the story of melvin.
All behaviour of the objects would be well defined and could be
easily understood to those who would read the documentation.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
gt;>> Top > bottom
> True
>>>> bottom > Top
> True
>
> As far as I can see, the only way to avoid edge cases like this is for Top
> (and Bottom) to be built-ins that are special-cased by Python.
An other problem is that if you roll your own, they wont be
On 2006-09-28, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-09-27, OKB (not okblacke) <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon wrote:
>>>
>>>> To begin with this already fails:
>>>>
>>>>&
On 2006-09-28, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-09-27, George Sakkis <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon wrote:
>>>
>>>> What bothers me a bit about the rejection of PEP 326 is that
e to
hair up the code.
In any case it seems I have my answer. I have some suggestions I can
try out, but writing up once own module for extreme values isn't as
easy as is suggested in the rejection of the PEP and there is probably
very little chance to get the PEP reopened.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
to use and maintain the code base.
I would think that this kind of issues is the responsibility of the
project leader. Otherwise you might as well remove the possibilty
of a recursive function. There may always be someone that writes complicated
recursive functions whenever a simple iterative solution would do fine.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
LL(1) languages can be handled by a recursive descent parser.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
; value to f()? "None" doesn't seem to work..
>
> Thanks in advance.
One possible way to do what I think you want is to code as follows:
class Default (object):
pass
def f(var=Default):
if var is Default:
var = 1
return var * 2
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
is an object, (let as call it Default), that would
make code like:
def f(var=1):
Equivallent to:
def f(var=Default)
if var is Default)
var = 1
So that we could write the following without the need of the
f's default value.
def g():
arg = Default
try:
arg = Try_
On 2006-10-04, Paul Rubin wrote:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Now in this case you could start by assigning arg the value 1 and
>> eliminate the if test. However that only works if you know the
>> default value for the argument. What he seems to be a
On 2006-10-04, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> One possible way to do what I think you want is to code as follows:
>>
>> class Default (object):
>>pass
>
> I'd have written
>
> D
On 2006-10-04, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-10-04, Paul Rubin wrote:
>>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>> Now in this case you could start by assigning arg the value 1 and
>>>> elim
On 2006-10-04, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
>
>>> But that can only work if you are the author of f. Take the
>>> following code:
>>>
>>> def myrepeat(obj, times = xxx):
>>> return itertools.repeat(obj, times)
>>>
>>> What value do I have to substitue for xxx
gs[-1] is Default:
args = args[:-1]
else:
break
return f(*args)
The call:
defaulter(f, arg1, arg2, Default, ..., Default)
would then be equivallent to:
f(arg1, arg2)
Or in your case you would call:
defaulter(f, Default)
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-10-04, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> On 2006-10-03, LaundroMat <[EMAIL PROTECTED]> wrote:
>> Suppose I have this function:
>>
>> def f(var=1):
>> return var*2
>>
>> What value do I have to pass to f() if I want it to evalu
HIDEDST1. In both
cases you have to remove one character from the target as well
as one character from the candidate in order to get the
same substring.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
otect against concurrent access and modification?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
a possibility:
wanted = [ (1 - 2*(i%2)) * item for i, item in enumerate(input)]
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
;(\\HasNoChildren) "/" "user/cpapen/vubrations"'
'(\\HasNoChildren) "/" "user/cpapen/wm2addressbook"'
'(\\HasNoChildren) "/" "user/cpapen/wm2prefs"'
'(\\HasNoChildren) "/" "user/cpapen/wm2signature"'
What I have a problem with is the 14th and 15th line.
All other entries are strings but the 14th is a tuple.
and the 15th is an empty string. As far as I can tell
every time a "%" is in the mailbox name I get this kind of
result.
I'm using python 2.3.3 and the imap sytem is Cyrus.
Can someone explain what is going one?
Is this a bug?
If it is, is it fixed in later versions?
Whether or not it is a bug, can I rely on the mailbox
being the last item in the tuple in these cases?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-11-28, Leo Kislov <[EMAIL PROTECTED]> wrote:
>
> Antoon Pardon wrote:
>> This little program gives IMO a strange result.
>>
>> import imaplib
>>
>> user = "cpapen"
>>
>> cyr = imaplib.IMAP4("imap.vub.ac.be")
>&
On 2006-11-29, Leo Kislov <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-11-28, Leo Kislov <[EMAIL PROTECTED]> wrote:
>> >
>> Are there more docs than at http://www.python.org/doc/. I don't find
>> those very helpfull in explaining this.
for partial
application or curry.
> Now, I am sure there are a half-dozen ways to do this.
> I just want the one, new and shiny, Pythonic way. ;-)
The new and shiny, pythonic way depends on what you
really want, your question was a bit vague to answer
that.
--
Antoon pardon
--
http://mail.python.org/mailman/listinfo/python-list
it easy to do the right thing.
That seems to depend on which part of the community you are
talking to. Some do argue that some features shouldn't be
included in the language because the risk of bugs by those
who don't understand how to use it properly, is too high.
That e
Op 2006-02-01, Saizan schreef <[EMAIL PROTECTED]>:
> In an event-driven application i'd like to keep the program alive regardless
> of any exceptions raised by the handlers,
> but still be able to debug them by reading the appropriate TraceBack from
> stderr.
> I can put something like:
>
> try:
(self, _Pair_sum)
self.product = BoundMethod(self, _Pair_product)
self.__init__(...)
So when p is an instance of Pair, p.sum is not your defined
function but a BoundMethod.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
a, and calls it with (b,c) as
> parameters
>
> This means there doesn't need to be a distinction between methods and
> functions, just a different operator to treat a function as if it was a
> method.
That is nice. I wonder if the following is possible in Lua:
fun = a:foo
ule be promoted to this special status? How many
> modules have precisely one function?
For the same reason they are already promoted special status in
classes. Python promotes duck typing so why shouldn't special
functions of modules be treated the same as special methods?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
here are implemenation details that make it not
worth while to implement this. But otherwise I would think it
a bad reason to give up orthogonality just because one can't imagine
what it could be usefull for.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2006-02-08, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2006-02-08, Steve Holden schreef <[EMAIL PROTECTED]>:
>>
>>>Why should a module be callable? What's the advantage? Should we be able
>>>to add two modules
the SomeClass object (which is a subclass of object) has an
> attribute named "__call__". Should that define how the expression
> SomeClass()
> is evaluated? Should that return the string 'Text' or create a
> new instance of SomeClass?
This make me wonder. Would it be possible to do something with
metaclasses so that after
class SomeClass(MetaClass):
...
SomeClass() will be equivalent to MetaClass.__call__(SomeClass)
Just curious.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ite the above as:
for i in (2:5):
print i,
> A second keyword "downto" would allow easy backwards
> loops, and a third "step" will absolutely kill any
> chance of Guido agreeing to this whatsoever.
Well with iterable slices we wouldn't need any new
key
hold.
In python 2.x I would either throw an exception or continuely return
None if the start value isn't given.
For python 3000 I would continously return Bottom or Top if the start
value wasn't given, depending on step being positive or negative.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ay to do this in
>>Python?
>
> It is a deliberate and fundamental design decision in Python that
> assignment is a statement, not an expression with side effects.
The only motivation I have heard for this decision is to easily
find typo related bugs. I can hardly find that a fundamental
design decision.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
r, there
is little use for an Empty Enum. Just as there is little
use for looping over an empty list if you literally
provide that empty list, but maybe somewhere in the future
some automation tool will produce scripts that use Enums.
Why should we possibly make the future production of such
key, value in dict1.iteritems():
try:
dict3[key] = dict2[value]
except KeyError:
pass
Or otherwise with a genexp
dict3 = dict((key, dict2[value]) for (key, value) in dict1.iteritems() if value
in dict2)
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
r and that this would be indicated in the
documentation and reflected in the stdlib?
Would it break much code to make this change? My first impression
would be no, but I could be missing something.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
0,1,3,4] to be returned
> Can someone help please
>
Something like this:
>>> lst = [2,3,1,4,5]
>>> inx = range(len(lst))
>>> inx.sort(lambda x,y: lst[x] - lst[y])
>>> print inx
[2, 0, 1, 3, 4]
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-05-03, Antoon Pardon schreef <[EMAIL PROTECTED]>:
> Op 2005-05-03, custard_pie schreef <[EMAIL PROTECTED]>:
>> I need help sorting a list...I just can't figure out how to sort a list
>> and then return a list with the index of the sorted items in the list
&
work
for you, doesn't imply he looks down on it.
> Everyone can do his homework well without any problems in your logic?
There is difference in asking for help on how to solve a
problem yourself and asking for the solution.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
st a little bit trouble.
>>
> Training wheels do no belong as a permanent part of a bicycle, IMO.
But what is a training wheel depends on your point of view.
IMO the required indentation is more like permanent training wheels
than end block-markers would be. A structure in general has
e residual memory use
> (after the peak) is compact and not evenly spread across
> the address space.
Well nothing. But how do you want to return memory back
to the O.S. when the residual memory use isn't compact
and evenly spread across the address space?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
already smart. It deduces what you want with the += operator
even if you haven't defined an __iadd__ method. If python can be smart
with that, I don't see python being smart with !=.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
choice, which they will have to think about
so their decision what to use is no longer obvious, which it is
if there is only one option.
Yet these kind of remarks are made often enough when someone suggest a
change to python.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2007-06-11, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>| On 2007-06-09, Terry Reedy <[EMAIL PROTECTED]> wrote:
>| > For him to imply that Python is anti-flexibility is
ake the call. Something like:
def returns_less_than_three(func):
return func() < 3
ls.count(returns_less_than_three)
Checking the return values implictly, would make it vey hard if not
impossible to check against the callables themselves if you want to.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
isp-like macros
> haven't taken off.
I find this is a rather sad kind of argument. It seems to imply that
python is only for problems that are rather common or similar to
those. If most people don't care about the kind of problem you
are working on, it seems from this kind of argumen
t
2) let lng be the number of elements.
3) let n range from 0 to 2 ** lng
4) now n represents subset as follows
consider n as a binary number
bit k is set in n <=> lst[k] is a member of the subset.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
can it be done
> without either break or continue? (given that you have to
> stop when you have found it)
It depend on what the language offers. Should PEP 325 be implemented the
code would look something like:
do:
line = fl.readline()
while st not in line:
pass
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
C. The
> learning curve is rather steep IMO, but worth it.
Just a throw in remark, that you may ignore if you wish, but a steep
learning curve means that the subject is easily familiarized and that
the learning period is short.
You seem to use it as if it is the opposite.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>
> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
>
>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>>>
>>> PyObjC is pretty slick (and since Ronald hasn't made any commits
On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
> Michael Bentley wrote:
>> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
>>
>>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
> [...] The
>>>> learning curve is rather
On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2007-04-19, Steve Holden <[EMAIL PROTECTED]> wrote:
>>> Michael Bentley wrote:
>>>> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wrote:
>>>>
>>
On 2007-04-19, Wayne Brehaut <[EMAIL PROTECTED]> wrote:
> On 19 Apr 2007 10:54:20 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> wrote:
>
>>On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>>>
>>> On Apr 19, 2007, at 4:11 AM, Antoon Pardon wro
On 2007-04-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Apr 19, 6:54 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> I don't know how you come to the conclusion that it is a mathematical
>> absurdity but consider this: If you find that common usage
On 2007-04-20, Nigel Rowe <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Apr 2007 19:11, Antoon Pardon wrote in comp.lang.python:
>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
>
>
>
>>> The learning curve is rather steep IMO, but worth it.
>&
On 2007-04-20, Roel Schroeven <[EMAIL PROTECTED]> wrote:
> Antoon Pardon schreef:
>> On 2007-04-19, Wayne Brehaut <[EMAIL PROTECTED]> wrote:
>>> So the remark that " a steep learning curve means that the subject is
>>> easily familiarized and that the
On 2007-04-20, Steve Holden <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2007-04-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> On Apr 19, 6:54 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>>> I don't know how you come to th
On 2007-04-20, Steve Holden <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2007-04-20, Steve Holden <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon wrote:
>>>> On 2007-04-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>>>&
up and down while moving
to the right instead of going left and right while moving up.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2007-04-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 20 Apr, 15:22, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> On 2007-04-20, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>>
>> > Which is nonsense. The goal is to go from A - ignorance - to B -
>
On 2007-04-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 20 Apr, 09:21, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>
>> Indeed I have no wish to bow before common usage.
>
> Then nobody will understand you properly if you start referring to a
> "steep lear
sa but I can't make out what this second variable is supposed
to be from your explanation.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2007-04-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 20 Apr, 16:34, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> On 2007-04-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
>>
>> > You could have knowledge or accomplishment
>> > on the X axis a
On 2007-04-21, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> Antoon Pardon schrieb:
>> On 2007-04-20, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>>>> So if you have the choice between a steep or a shalow income curve
>>>> you will prefer the shalow cur
On 2007-04-22, René Fleschenberg <[EMAIL PROTECTED]> wrote:
> Antoon Pardon schrieb:
>>> Who says the axes are labeled "familiarity" and "learning period"? I
>>> just assume they are labeled (y-axis) "Effort" and (x-axis) "Knowledge&q
On 2007-04-20, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 20 Apr 2007 12:25:40 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>>
>> But if a wrong idea is circulating and nobody ever tries to correct it,
>> p
nts
__getitem__ and __setitem__ in function of attribute access.
The following is an example:
class Rec(object):
def __init__(__, **kwargs):
for key,value in kwargs.items():
setattr(__, key, value)
def __getitem__(self, key):
return getattr(self, key)
de
mment from guido. One can
add something later and come to the conclusion that it would have been
better not included but that in the mean time too much depend on it
to remove it. That seems a perfect description of keeping something
for historical reasons.
So it is possible that one keeps something
On 2007-04-23, Rob Wolfe <[EMAIL PROTECTED]> wrote:
>
> Antoon Pardon wrote:
>> The following is part of the explanation on slices in the
>> tutorial:
>>
>> The best way to remember how slices work is to think of the indices as
>> pointing between c
tended slice:
"HelpA"[4:2:-1] => "Ap"
So this doesn't result in the reverse of the previous expression while
the explanation above suggest it does.
So I suggest to drop this.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2007-04-23, Michael Bentley <[EMAIL PROTECTED]> wrote:
>
> On Apr 23, 2007, at 7:38 AM, Antoon Pardon wrote:
>
>> The following is part of the explanation on slices in the
>> tutorial:
>>
>> The best way to remember how slices work is to think of the in
1501 - 1600 of 1820 matches
Mail list logo
