Prev: Types missing from "types"module
Next: dbus and properties multivalue
From: rantingrick on 25 Jun 2010 16:07
On Jun 25, 12:36 pm, Emile van Sebille <em...(a)fenx.com> wrote:

> IIRC, IDLE was written by Guido so that he could experience writing in
> python (which he also wrote).  _You_ can either rewrite it or not, but
> realize no one else is going to do it, so stop wasting your time asking
> for it to be rewritten.

I AM rewriting it, however i am heavily contemplating whether i will
or will not share the code with such ungrateful heathens.
From: Alan G Isaac on 25 Jun 2010 16:46
On 6/25/2010 3:52 PM, Dave Angel wrote:
> I said "default", not "only" behavior. I suspect list provides an
> __iadd__ method to provide this ability. Integers do not, and
> therefore neither does the object the OP was asking about.


I have no idea what "default behavior" is supposed to mean.
Mutable objects like a list will generally modify in place.
Immutable objects of course will not. An IntVar is mutable.
You have given no reason for it not to handle ``+=`` in an
unsurprising fashion. It is not an int.

Alan Isaac

From: Emile van Sebille on 25 Jun 2010 18:15
On 6/25/2010 1:07 PM rantingrick said...
> On Jun 25, 12:36 pm, Emile van Sebille<em...(a)fenx.com> wrote:
>
>> IIRC, IDLE was written by Guido so that he could experience writing in
>> python (which he also wrote). _You_ can either rewrite it or not, but
>> realize no one else is going to do it, so stop wasting your time asking
>> for it to be rewritten.
>
> I AM rewriting it, however i am heavily contemplating whether i will
> or will not share the code with such ungrateful heathens.

Idle is dead -- long live idlefork!

http://osdir.com/ml/python.idle/2002-09/msg00105.html


Emile


From: Dave Angel on 25 Jun 2010 18:23
Alan G Isaac wrote:
> On 6/25/2010 3:52 PM, Dave Angel wrote:
>> I said "default", not "only" behavior. I suspect list provides an
>> __iadd__ method to provide this ability. Integers do not, and
>> therefore neither does the object the OP was asking about.
>
>
> I have no idea what "default behavior" is supposed to mean.
> Mutable objects like a list will generally modify in place.
> Immutable objects of course will not. An IntVar is mutable.
> You have given no reason for it not to handle ``+=`` in an
> unsurprising fashion. It is not an int.
>
> Alan Isaac
>
>
To quote the docs,

"If a specific method is not defined, the augmented assignment falls
back to the normal methods. For instance, to execute the statement x +=
y, where /x/ is an instance of a class that has an __iadd__()
<#object.__iadd__> method, x.__iadd__(y) is called. If /x/ is an
instance of a class that does not define a __iadd__() <#object.__iadd__>
method, x.__add__(y) and y.__radd__(x) are considered, as with the
evaluation of x + y."

In other words, if a class defines __add(), but not __iadd__(), then
it'll behave this way. That's what I mean by default.

I didn't say it should, merely that it does. I suspect that __iadd__
didn't exist when IntVar was being defined, and nobody got around to
adding it.

Another part of the docs would seem to encourage IntVar to change:

"An augmented assignment expression like x += 1 can be rewritten as x =
x + 1 to achieve a similar, but not exactly equal effect. In the
augmented version, x is only evaluated once. Also, when possible, the
actual operation is performed /in-place/, meaning that rather than
creating a new object and assigning that to the target, the old object
is modified instead"

DaveA

From: rantingrick on 25 Jun 2010 20:00
On Jun 25, 5:15 pm, Emile van Sebille <em...(a)fenx.com> wrote:

> > I AM rewriting it, however i am heavily contemplating whether i will
> > or will not share the code with such ungrateful heathens.
>
> Idle is dead -- long live idlefork!

Thanks Emile for sharing this. Nobody had told me about the IDLE fork
project. And that is very strange to me considering all the noise i've
made about IDLE over the last year or so. Anyway i was reading from
the "main" IDLEFORK project page and noticed something peculiar...

"""The IDLEfork project was an official experimental development fork
of Python's small, light, 'bundled' integrated development
environment, IDLE."""

....Ok, sounds great!

"""On June 29, 2003 the IDLEfork code base (rev 0.9b1) was merged back
into Python. Its location in the Python source tree was moved from .../
Tools/idle to .../Lib/idlelib, and the IDLEfork project went into
bugfix mode."""

hmm 2003? Bummer. This means that even the newest attempt to upgrade
idle was nearly ~7 years ago? So it seems old IDLE is really living up
to it's name. Looks like the dev cycle is completely "idle" at this
point and suffering the fate of monkey patch syndrome. I think it's
high time we create a new IDLE fork and then mold it back into the
stdlib. This time actually creating a Pythonic IDLE which conforms to
the stdlib for comments, docstrings, working test subjects, etc...

Any module in the stdlib should have proper comments, docstrings on
every method, and most importantly a test case wrapped up in a "if
__name__ == '__main__'" block. And this test case SHOULD NEVER BLOW
CHUNKS! The test case is sooo important to new programmers learning
Python, and i cannot stress that enough!

Now. I would be more than happy to start by doc'ing out all the
methods, classes, modules, etc. However i'm not about to waste my time
if i cannot get the code accepted into the stdlib because "some
people" here hate me.

@OP: I am very sorry to have hijacked your thread. This was not my
intention however the state of IDLE (and any stdlib module) is very
important to the future of Python. And since IDLE is written in
Tkinter there is a connection to the subject matter within this
thread. Although i will admit it's a very distant connection.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Types missing from "types"module
Next: dbus and properties multivalue