ecause
> the last item in data is mutable. But this will NOT work:
>
> data = [0, None, 2, 0]
> ref = data[-1]
> ref = 1
> assert data[-1] == 1
>
> because ints are immutable. So the distinction between modifying a
> mutable object in place and assigning is important.
I wonder couldn't this be done with properties?
Write somekind of property so that if you manipulate a.x it would
manipulate data[-1]
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
signment operator (let use @= for it) next to a
(re)bind operator.
We could then have something like the following.
a = 5
b = a
a @= 7
b ==> would result in 7.
I think such option is usefull and I sometimes miss it in python.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-11-14, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> We could then have something like the following.
>>
>> a = 5
>> b = a
>> a @= 7
>> b ==> would result in 7.
>
> Ouch! :-(((
>
> Can't you live with
Op 2005-11-14, Mike Meyer schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Op 2005-11-10, Mike Meyer schreef <[EMAIL PROTECTED]>:
>>> [Context recovered from top posting.]
>>> "[EMAIL PROTECTED]" <[EMAIL PROTEC
Op 2005-11-14, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 14 Nov 2005 11:20:53 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>Op 2005-11-14, Paul Rubin schreef :
>>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>> We could then have someth
Op 2005-11-15, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 15 Nov 2005 08:51:59 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>Op 2005-11-14, Bengt Richter schreef <[EMAIL PROTECTED]>:
> [...]
>>> You may be interested in reviewing
>&
Op 2005-11-15, Mike Meyer schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>> Like having an assignment operator (let use @= for it) next to a
>>>> (re)bind operator.
>>>> We could then have something like the following.
Op 2005-11-16, Mike Meyer schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Op 2005-11-15, Mike Meyer schreef <[EMAIL PROTECTED]>:
>>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>>>> Like having an assig
.. GTK+ etc
Well I think if you visit http://www.pygtk.org/, it will answer most of
your questions.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
of behavior?
Well you have two above. Maybe someone can think of something
else.
Which behaviour are you looking for?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
to higher
>> precision, I'd have more digits of course.
>
> You have described, if memory serves, a Taylor series, and those
> coefficients are 1/3!, 1/5!, 1/7!, etc.
Well if you had infinite precision numbers you might be right.
However in numerial analysis, one often uses
t I'm mostly interesseted
in a conditional expression. Whether it is "then-if-else" or "if-then-else"
seems less important to me.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ts resemble english.
(2) May make some constructs more readable for the beginners, but
IMO (1) makes for more readabiliy over the long term.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ening with lists?.
And isn't something like this already possible with properties, except
for the scoping.
If python would develop the property idea a bit further and have
variables that would call a function each time they are accessed,
something like this could work.
--
Antoon Pardon
-
ple are fighting the language, sometimes
the best approach is to change the language so that there is
less reason to fight the language.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
gt; convincing reasons.
>
> The usual response is "That's not the Python way." That's not calling
> someone dumb, just pointing out that they don't yet fully understand
> the Python way.
"That is not the Python way", is just saying "Python
Op 2005-11-24, Simon Brunning schreef <[EMAIL PROTECTED]>:
> On 24 Nov 2005 10:21:51 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> But only Guido, thinks like Guido and then even Guido may now think
>> differently than he thought before. And what if Guido had a bad
x27;t think the underscore prefixes are very usefull.
They constantly flag to take care with a specific variable, while
that variable is nothing special within the module itself.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-11-24, Simon Brunning schreef <[EMAIL PROTECTED]>:
> On 24 Nov 2005 11:30:04 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> > But he's consistently a
>> > better judge of language design than I am, and in all likelihood
>> > better than y
Op 2005-11-24, Roel Schroeven schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-11-24, Mike schreef <[EMAIL PROTECTED]>:
>>>and many a time. I've been annoyed (in Java and MS christelijke vorm er van.
>>>frameworks)
>
> Antoon, I don
Op 2005-11-24, Mike Meyer schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>> The usual response is "That's not the Python way." That's not calling
>>> someone dumb, just pointing out that they don't yet fully und
esn't mean that it doesn't do so.
Well this seems to be the main conflict between those who would
like Python to go a bit further and those that oppose it.
Should the priority be to enable python's philosophy or should
it be the priority to limit python to only allow it's philosophy.
On
seem to
me a valuable suggestion even if the proposer didn't understand how it
will fit.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
thing that uses field identifiers to address components,
Not something that uses indexing.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-11-26, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
> On Thu, 24 Nov 2005 12:55:07 +, Antoon Pardon wrote:
>
>> Suppose I have the following code.
>>
>> from module import __take_care__
>>
>> __private_detail__ = ...
>>
>>
Op 2005-11-25, Mike Meyer schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Op 2005-11-24, Mike Meyer schreef <[EMAIL PROTECTED]>:
>>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>>> The usual response is "Tha
Op 2005-11-25, Mike Meyer schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Well this is, is one thing I have a problem with.
>>
>> The python people seem to be more concerned with fighting things
>> that could be used counter
Op 2005-11-28, Serge Orlov schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> No it wasn't. From what I have picked up, the ternary operator
>> was finaly introduced after one of the developers tripped over
>> the commonly used idiom to simulate a ternary operat
the impression that what is considered pythonic
or not is more related to who proposes it that to what the
proposal is and that after one has so decided the right
rules are selected to defend that decision.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
foolish about the consistency that all sequence types
have a count method?
The way this "pearl of wisdom" is used in this newsgroup, I expect
one day someone to use "+" for substraction and '-" for addition and
then when people complain about that not being consistent they get
answered by the above quote.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-11-28, Duncan Booth schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> So suppose I want a dictionary, where the keys are colours, represented
>> as RGB triplets of integers from 0 to 255. A number of things can be
>> checked by index-like methods.
>
5 (7)
> 35 LOAD_CONST 6 (8)
> 38 BUILD_LIST 5
> 41 COMPARE_OP 6 (in)
I'm probably missing something, but what would be the problem if this
list was created during compile time?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
way of doing it?
You mean something like this:
>>> class Foo:
... def __init__(self, v):
... self.value = v
...
>>> def show(self):
... print self.value
...
>>> import new
>>> f = Foo(17)
>>> f.show = new.instancemethod(show, f)
>>> f.show()
17
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-11-28, Duncan Booth schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> I'm sure I could come up with an other example where I would like
>> to have both some list method and use it as a dictionary key and
>> again people could start about that impl
On 2005-11-28, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>>> >>> def func(x):
>>> ... if x in [1,3,5,7,8]:
>>> ... print 'x is really odd'
>>> ...
>>> >>> dis.dis(func)
>&g
On 2005-11-28, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>>
>> No I gave an example, you would implement differently. But even
>> if you think my example is bad, that would make it a bad argument
>> for tuples having list methods. Tha
On 2005-11-28, Mike Meyer <[EMAIL PROTECTED]> wrote:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Op 2005-11-25, Mike Meyer schreef <[EMAIL PROTECTED]>:
>>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>> Well this is, is one thing I have
On 2005-11-29, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> The question is, should we consider this a problem. Personnaly, I
>> see this as not very different from functions with a list as a default
>> argument. In that case we often have
On 2005-11-29, Bengt Richter <[EMAIL PROTECTED]> wrote:
> On 29 Nov 2005 08:27:43 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>On 2005-11-28, Duncan Booth <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon wrote:
>>>
>>>>
>>>>
On 2005-11-29, Mike Meyer <[EMAIL PROTECTED]> wrote:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>> You see, you can make languages more powerful by *removing* things
>>> from it.
>> You cast this in way to general terms. The logic conclusion
>> fr
On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> But lets just consider. Your above code could simply be rewritten
>> as follows.
>>
>> res = list()
>> for i in range(10):
>> res.append(i*i)
>>
>
On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>>> The left one is equivalent to:
>>>
>>> __anon = []
>>> def Foo(l):
>>>...
>>>
>>> Foo(__anon)
>>> Foo(__anon)
>>
&
On 2005-11-30, Christophe <[EMAIL PROTECTED]> wrote:
> Antoon Pardon a écrit :
>> On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote:
>>
>>>Antoon Pardon wrote:
>>>
>>>>But lets just consider. Your above code could simply be rewritt
doesn't matter which
axis the point is on. So counting how many of the coordinates are
zero is natural way to check if a point is on an axe. Doing a find
is a natural way to check if a point is on an axis and at the same
time find out which one.
So that a sequence is heterogenous in this sense doesn't imply
that count, find and other methods of such kind don't make sense.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
that since iteration is at the heart
of methods like index, find and count, that supporting iteration
is sufficient reason to support these methods.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
On 2005-11-30, Dave Hansen <[EMAIL PROTECTED]> wrote:
> On 30 Nov 2005 10:57:04 GMT in comp.lang.python, Antoon Pardon
><[EMAIL PROTECTED]> wrote:
>
>>On 2005-11-29, Mike Meyer <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon <[EMAIL PROTECTED]> wr
On 2005-11-30, Mike Meyer <[EMAIL PROTECTED]> wrote:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> On 2005-11-29, Mike Meyer <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>>> You see, you can make languages m
On 2005-12-01, Mike Meyer <[EMAIL PROTECTED]> wrote:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> I know what happens, I would like to know, why they made this choice.
>> One could argue that the expression for the default argument belongs
>> to the code fo
On 2005-12-01, Steve Holden <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2005-12-01, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>
>>>Mike Meyer wrote:
>>>
>>>
>>>>So why the $*@& (please excuse my Perl) does "
On 2005-12-01, Mike Meyer <[EMAIL PROTECTED]> wrote:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> On 2005-12-01, Mike Meyer <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>> I know what happens, I would like to
On 2005-12-02, Bengt Richter <[EMAIL PROTECTED]> wrote:
> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon wrote:
>>>
>>>>> The lef
Op 2005-12-02, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 2 Dec 2005 13:05:43 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>On 2005-12-02, Bengt Richter <[EMAIL PROTECTED]> wrote:
>>> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <[EMAIL PROTECTED]&g
gt;> having to use so many temp variables, for either numbers or functions,
>> can work against both concision and clarity.
>
> For some people, the second form is clearer.
But there is no suggestion that this should be the obligatory form.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-12-06, [EMAIL PROTECTED] schreef <[EMAIL PROTECTED]>:
>
> Antoon Pardon wrote:
>> Op 2005-12-06, [EMAIL PROTECTED] schreef <[EMAIL PROTECTED]>:
>> >
>> > Paul Rubin wrote:
>> >> > Why use temporary variables when all you have to do i
t arguments
in favor of the lambda are the possibility to use an expression
as a parameter, this may be an acceptable alternative for
those who use lambda now
I don't know how well name parameters would fit in with the
rest of python though.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
markers when I program python.
In the past that was just by using comments like:
if ...:
...
#end
But lately I have been wondering about doing the following:
end = None
...
if ...:
...
end
IMO it looks better, but I'm reluctant because it suggest
some checking by the compilor, which just doesn't happen.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
n is not that visible.
The problem is that situations arise where your code can't be
read continuously. e.g. it can be spread over pages in a book.
It isn't always clear whether the code on the new space is
equally idented as the code on the previous space.
Other situations arise where indentation alone isn't a clear
indication of how many scopes are left.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-12-07, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> But lately I have been wondering about doing the following:
>> end = None
>> ...
>> if ...:
>> ...
>> end
>> IMO it looks better, but I'm reluctant be
Op 2005-12-07, Ben Sizer schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-12-06, Ben Sizer schreef <[EMAIL PROTECTED]>:
>> > Of course. However I would argue that indented scope is one way of
>> > doing so. Scope is instantly vis
Op 2005-12-07, Christophe schreef <[EMAIL PROTECTED]>:
> Paul Rubin a écrit :
>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>
>>>But lately I have been wondering about doing the following:
>>>end = None
>>>...
>>> if ...:
>>&
on't do it, but it has bothered me. The direction I'm thinking
of right now is doing all such initialisation within an initialisation
function, all temporary variables or scaffolding functions, defined
in that function will disappear automatically when the function has
done its job.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-12-07, Zeljko Vrba schreef <[EMAIL PROTECTED]>:
> On 2005-12-07, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>
>> What I don't understand is, that most people who have a problem
>> with scope by indentation, want to introduce braces. I think
>> br
gt; or at least the sensible ones do.
But sometimes you mess up and your code is no longer indented as it
should. If you marked the end of the indentations, you can easily
correct this.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-12-08, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
> On Thu, 08 Dec 2005 08:23:52 +, Antoon Pardon wrote:
>
>> Op 2005-12-07, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
>>> On Wed, 07 Dec 2005 15:26:59 +, Zeljko Vrba wrote:
>>
Now slices are objects in python, I was wondering if slice
notation will be usable outside subscribtion in the future.
Will it ever be possible to write things like:
a = 4:9
for key, value in tree.items('alfa.': 'beta.'):
--
Antoon Pardon
--
http://mail.python.org/mai
Op 2005-12-09, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Now slices are objects in python, I was wondering if slice
>> notation will be usable outside subscribtion in the future.
>>
>> Will it ever be possible to write things like:
>&g
Op 2005-12-09, Duncan Booth schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Will it ever be possible to write things like:
>>
>> a = 4:9
>> for key, value in tree.items('alfa.': 'beta.'):
>
> The first of these works fine,
Op 2005-12-09, Duncan Booth schreef <[EMAIL PROTECTED]>:
> Antoon Pardon asked:
>
>
>> If we have lst = range(10), we can write
>>
>>lst[slice(3,7)]
>>
>> instead of
>>
>>lst[3:7]
>>
>> Now my impression is that sh
On 2005-12-09, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>>> If the user can write
>>>
>>>for key in tree['a':'b']:
>>>
>>> then he can write:
>>>
>>>for key in tree[&
ariables could be usefull for when you want to manipulate
such an individual number.
> My class is written, tested and complete before you've even decided on
> your API. And you don't even really get the benefit of abstraction: I have
> two public attributes (x and y) that I c
On 2005-12-10, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> So lets agree that tree['a':'b'] would produce a subtree. Then
>> I still would prefer the possibility to do something like:
>>
>> for key in tree.iterkeys(&#
On 2005-12-10, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> In general I use slices over a tree because I only want to iterate
>> over a specific subdomain of the keys. I'm not iterested in make
>> a tree over the subdomain. Making such a subtr
On 2004-12-29, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> Op 2004-12-23, Scott David Daniels schreef <[EMAIL PROTECTED]>:
>>>This is half the problem. In the period where an element is in the
>>>wrong hash bucket, a new ent
bject can be
> used as kay in a dict.
This is not true.
> So you can use tuples for 'composed key'.
lists can be so used too. Just provide a hash.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-01-10, Bruno Desthuilliers schreef <[EMAIL PROTECTED]>:
> Antoon Pardon a écrit :
>> Op 2005-01-08, Bruno Desthuilliers schreef <[EMAIL PROTECTED]>:
>>
>>>worzel a écrit :
>>>
>>>>I get what the difference is between a tuple and
27;t on
your XP box, that is a bug)
> Traceback (most recent call last):
>File "", line 1, in
> OSError: [Errno 17] File exists: 'c:\\temp\\a.txt'
Which is exactly as it should, provided you actually used the os.O_EXCL
flag twice.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
>>> twice(Vec(1.0,2.0))
Vector[2.0, 4.0]
>>>
I suppose what can be done with a vector class could have been
done with a complex class should complex numbers not have been
native to python.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-01-11, Reinhold Birkenfeld schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-01-10, Bruno Desthuilliers schreef <[EMAIL PROTECTED]>:
>>> Antoon Pardon a écrit :
>>>> Op 2005-01-08, Bruno Desthuilliers schreef <[EMAIL PROTECTED]>
These are both great
> languages, and mental gymnastics would probably do me good, but I
> wouldn't want it as part of my day-to-day requirements...)
Your day-to-day requirements are a contract between you and your
employer or between you and your clients. That you don't want
mental gymnastics as part of that, shouldn't be a concern for
how the language develops.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
se of the class, as you suggest by writing that
your code no longer looks like the equation you have on paper.
In that case I suggest the class was poorly done.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
uld
> obfuscate the whole language.
That zen is already broken. Look at the number of answers one gets
if a newbee askes for a ternary operator. I think that a simple
ternary operator or macro's with an official supported macro that
implemented the ternary operator would have been far closer
u assign a mutable to a new name and modify the object through
either name, you see the change through both names.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-01-13, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Well, it seems that Guido is wrong then. The documentation clearly
>> states that an expression is a statement.
>
> no, it says that an expression statement is a statement.
= [3]
> ...
>>>> spam = Spam()
>>>> spam2 = Spam()
>>>> spam.eggs
> [3]
>>>> spam2.eggs
> [3]
>>>> spam.eggs.append(5)
>>>> spam.eggs
> [3, 5]
>>>> spam2.eggs
> [3, 5]
>
Well I find this a confusi
I do that, people will tell me how bad that it
is, because it will keep a reference to the value which
will prevent the garbage collector from harvesting this
memory.
Besides python allows more than one statement on the same line.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
t; >>> foo.x += 1
> >>>
> >>> print foo.x
> 1
> >>> print Foo.x
> 0
>
> although the += operator looks like an inplace add it isn't.
> it is just syntactic sugar for foo.x = foo.x + 1.
Except is x belongs to a mutable class that impleme
>
> Well I find this a confusing behaviour on python's part. The fact
> that instance.field can mean something different, depending on
> where in a statement you find it, makes the behaviour inconsistent.
>
> I know people in general here are against declarations, but declarations
> could IMO provi
Op 2005-01-13, hanz schreef <[EMAIL PROTECTED]>:
>
> Antoon Pardon wrote:
>> So if I have a call with an expression that takes more than
>> one line, I should assign the expression to a variable and
>> use the variable in the call?
>
> Yes, that's someti
Op 2005-01-13, Terry Reedy schreef <[EMAIL PROTECTED]>:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Op 2005-01-13, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
>>> Antoon Pardon wrote:
>>>
&g
no, expressions CAN BE USED as statements. that doesn't mean
> that they ARE statements, unless you're applying belgian logic.
No I am applying set logic. Any string that is in the set of
valid expressions is also in the set of valid statements.
Like any animal that is in the set of dogs is also in the
set of mamals.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-01-14, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> No I am applying set logic. Any string that is in the set of
>> valid expressions is also in the set of valid statements.
>
> According to Python's grammar, this is not th
Op 2005-01-14, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>> no, expressions CAN BE USED as statements. that doesn't mean
>>> that they ARE statements, unless you're applying belgian logic.
>>
>> No I am applying
e in
Python.
It is not impossible in Python. It may be discouraged but it is not
impossible since I have already done so.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-01-14, Roel Schroeven schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> IMO we have a: dogs are mamals kind of relationship in Python.
>
> I see what you mean, but I don't think it's true.
>
>> Every expression can be used where a statement is
Op 2005-01-14, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-01-14, Peter Maas schreef <[EMAIL PROTECTED]>:
>>
>>>I have summarized the discussion about the usability of lists (and
>>>and other mutable types)
Op 2005-01-14, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-01-13, hanz schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
>>>>So if I have a call with an expression that takes more than
&g
Op 2005-01-17, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
> [...]
>>>"A foolish consistency is the hobgoblin of little minds". Rules are made
>>>to be broken.
>>
>>
>> Like only use immutables as dictionary keys.
&
Op 2005-01-17, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-01-17, Steve Holden schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>[...]
>>>
>>>>>"A foolish con
Op 2005-01-17, Just schreef <[EMAIL PROTECTED]>:
> In article <[EMAIL PROTECTED]>,
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>> Op 2005-01-17, Steve Holden schreef <[EMAIL PROTECTED]>:
>
>> > There you go with the minutiae again. Ho
Op 2005-01-17, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> I don't see a big difference between these principles
>> and the hash key principle, so in the end may be we
>> should just stick with the more general principle:
>>
&
601 - 700 of 1820 matches
Mail list logo
