May I propose that the developers consider keeping this release *beta*
until after the present Python moratorium? That is, don't let it be
marked as *official* until after, say, Python 3.3.
There are so many features taken from 3.0 that I fear that it will
postpone its adoption interminably (it is, in practice, treated as
"beta" software itself). By making it doctrine that it won't be
official until the next "major" Python release, it will encourage
those who are able, to just make the jump to 3.0, while those who
cannot will have the subtle pressure to make the shift, however
gradual. Additionally, it will give the community further incentive
to make Python3 all that it was intended to be. Personally, the
timing of v3 prevented me from fully participating in that effort,
and, not ignoring the work of those who did contribute, I think many
of us feel that it has not reached its potential.
Just a small suggestion... .. .
marcos
Whether 3.x is adopted by developers is IMO not influenced by the 2.7 release
schedule. At least the effect is highly speculative. So please simply release
2.7 when it's ready.
Ciao, Michael.
3.x won't be adopted by developers until it's fixed. As of now, it's
seriously broken and unsuitable for production.
>
> Ciao, Michael.
In what ways do you consider it broken?
Cheers,
Chris
Issue 8093. Remarkably, this apparently hasn't been noticed before.
I expect 2.7 will be around for a long time.
>
> Cheers,
> Chris- Hide quoted text -
>
> - Show quoted text -
I think you left your hyperbole level too high so I turned it down for
you. I don't know of _anyone_ who uses IDLE to run production code,
nor do I follow how one errant IDE shows that Python 3.x as a language
is broken.
Planning to buy a Toyota?
>> > 3.x won't be adopted by developers until it's fixed. As of now, it's
>> > seriously broken and unsuitable for production.
>>
>> In what ways do you consider it broken?
>
> Issue 8093. Remarkably, this apparently hasn't been noticed before.
I think that tells you that it's an unimportant bug that doesn't really
effect many people much, and a million miles from implying that Python
3.x is "seriously broken and unsuitable for production".
> I expect 2.7 will be around for a long time.
As reported on the bug tracker, this bug effects Python 2.7 as well. It's
possible this bug goes back to, what? Python 2.5? 2.4? 2.3? Older? Who
knows?
http://bugs.python.org/issue8093#msg102818
In any case, IDLE is one IDE out of many, and not really up to
professional quality -- it's clunky and ugly. It isn't Python, it is a
tool written in Python.
--
Steven
>>> 3.x won't be adopted by developers until it's fixed. As of now, it's
>>> seriously broken and unsuitable for production.
Not. Many though will wait until 3.2 and greater library availability,
which *is* coming.
>> In what ways do you consider it broken?
>
> Issue 8093.
IDLE is not Python. And are you really sure this is 3.x-only problem or
that it is not a Windows-only problem.
> Remarkably, this apparently hasn't been noticed before.
Because it requires somewhat rare circumstances. Start an infinite loop
from IDLE, perhaps specifically on Windows. Try to restart. Patiently
wait for restart to happen (several seconds, and iffy) instead of
killing the runaway process from TaskManager.
> I expect 2.7 will be around for a long time.
That was always expected independently of this issue.
Terry Jan Reedy
But this is a tool that is a part of the python distribution and often
recommended to python beginners as their first IDE. So IDLE is
responsible for the first impression on Python to many.
If IDLE is considered as of low quality and ugly, after so many years,
why it is not fixed or replaced?.
I'm just wondering.
joaquin
It affects me ... a LOT.
> and a million miles from implying that Python
> 3.x is "seriously broken and unsuitable for production".
Maybe because I'm a user, not a developer.
>
> > I expect 2.7 will be around for a long time.
>
> As reported on the bug tracker, this bug effects Python 2.7 as well. It's
> possible this bug goes back to, what? Python 2.5? 2.4? 2.3? Older? Who
> knows?
I can't imagine my not having noticed this before.
It's plausible I might not have noticed the runaway
processes, but the fact that I can't eject a USB
drive would have been very obvious.
>
> http://bugs.python.org/issue8093#msg102818
>
> In any case, IDLE is one IDE out of many, and not really up to
> professional quality -- it's clunky and ugly. It isn't Python, it is a
> tool written in Python.
You have no idea what the cause is, yet you're
certain that the symptom is confined to IDLE.
That's the kind of thinking that leads to such
bugs in the first place.
>
> --
> Steven
<Imagines Benjamin dancing folkdances on tables full of food>
> to announce the first beta release of Python 2.7.
Cool!
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
Which comes first, library availability or
a working system?
>
> >> In what ways do you consider it broken?
>
> > Issue 8093.
>
> IDLE is not Python.
The Task Manager doesn't say "IDLE", it says "pytonw".
> And are you really sure this is 3.x-only problem
No, I didn't say it was, just that that's where
I noticed it. I haven't been using the latest 2.x
upgrades because I switched to 3.x.
> or
> that it is not a Windows-only problem.
Could very well be. But when YOU target a specific
operating system, isn't the onus on YOU to make it
work within that system? If you're not content to
be a big fish in a small pond, then you better
figure out a way to make it work.
>
> > Remarkably, this apparently hasn't been noticed before.
>
> Because it requires somewhat rare circumstances. Start an infinite loop
> from IDLE, perhaps specifically on Windows. Try to restart. Patiently
> wait for restart to happen (several seconds, and iffy)
Not iffy at all. If it responds to the menu and I can
click on Restart, it succeeds.
> instead of
> killing the runaway process from TaskManager.
Why on earth would I want to do that? Then I lose
the entire history of whats printed in the window.
You've got a serious problem if you expect the
TaskManager to be used for normal operations.
>
> > I expect 2.7 will be around for a long time.
>
> That was always expected independently of this issue.
I hear 2.7 doesn't work either. I'll back off on that
comment.
>
> Terry Jan Reedy
Which toolset should the IDE target? Native Windows? QT? Gnome? Cocoa?
Something else? That will require a widget library. How many widget
libraries should Python ship with? Two? Three? Five? Which ones?
wxPython? PythonCard? Something else? They tend to be very large. Do the
Python developers then become responsible for fixing bugs in the widget
libraries?
Python ships with, at most, a single GUI toolset, tkinter, which targets
the Tcl/Tk toolkit. Consider it the lowest common denominator of modern
GUIs, although I hear that Tk now supports native widgets. But that still
requires work. See here:
http://stackoverflow.com/questions/349409/why-are-tk-guis-considered-ugly
But what it really comes down to is time and effort. GUI design is hard,
and unless somebody volunteers to make IDLE look and feel better, it
isn't going to just upgrade itself.
--
Steven
> On Apr 11, 11:53�am, Steven D'Aprano <st...@REMOVE-THIS-
> cybersource.com.au> wrote:
>> On Sat, 10 Apr 2010 21:08:44 -0700, Mensanator wrote:
>> >> > 3.x won't be adopted by developers until it's fixed. As of now,
>> >> > it's seriously broken and unsuitable for production.
>>
>> >> In what ways do you consider it broken?
>>
>> > Issue 8093. Remarkably, this apparently hasn't been noticed before.
>>
>> I think that tells you that it's an unimportant bug that doesn't really
>> effect many people much,
>
> It affects me ... a LOT.
I suspect you're exaggerating, but even if you're not, you are not the
entire Python community. You stated that "3.x won't be adopted by
developers until it's fixed". It sounds like what you really mean was
"3.x won't be adopted by *me* until it's fixed".
3.x is already being adopted by developers. The two biggest factors
slowing uptake of 3.x are: (1) lack of big libraries like numpy, and (2)
that major Linux distros still ship with 2.6 or 2.5.
>> and a million miles from implying that Python 3.x is "seriously broken
>> and unsuitable for production".
>
> Maybe because I'm a user, not a developer.
You write code. You use an Integrated DEVELOPMENT Environment. That makes
you a developer.
>> > I expect 2.7 will be around for a long time.
>>
>> As reported on the bug tracker, this bug effects Python 2.7 as well.
>> It's possible this bug goes back to, what? Python 2.5? 2.4? 2.3? Older?
>> Who knows?
>
> I can't imagine my not having noticed this before. It's plausible I
> might not have noticed the runaway processes, but the fact that I can't
> eject a USB drive would have been very obvious.
Have you tried to reproduce it on 2.6 or 2.5? Unless you actively try to
reproduce it, you can't assume it doesn't occur.
>> http://bugs.python.org/issue8093#msg102818
>>
>> In any case, IDLE is one IDE out of many, and not really up to
>> professional quality -- it's clunky and ugly. It isn't Python, it is a
>> tool written in Python.
>
> You have no idea what the cause is, yet you're certain that the symptom
> is confined to IDLE.
Certain? Of course not. But given an issue that is reported with a single
application, which is more likely? That it is a bug in the language, or a
bug in the application?
Even if it is a bug in the language, some fundamental failure of the
underlying Python virtual machine or built-in objects, there are dozens
of standard library modules, and thousands of third-party modules, that
it doesn't affect.
> That's the kind of thinking that leads to such bugs in the first place.
Riiiight.
--
Steven
Did we just start playing Questions?
One way to fix it, dump tkinter and IDLE.
C/C++ is not broken since they do not ship with an ugly GUI library or
half-assed IDE called IDLE. Why should python ship with them?
On a second thought, let me think about it again.
Of course, that doesn't fix the problem, does it?
You think the right thing to do is just quietly work
around the problem and sit back and laugh knowing sooner
or later someone else will get burned by it?
And here I thought I was making a contribution by discovering
something that no one else noticed.
>
> C/C++ is not broken since they do not ship with an ugly GUI library or
> half-assed IDE called IDLE.
Why do you guys think I'm talking about the language? I'm talking
about
a particular implementation.
> Why should python ship with them?
>
> On a second thought, let me think about it again.
Yeah, you certainly don't want to get yelled at by Mr. D'Aprano.
I'm not. I often use a USB drive to store my source programs, makes it
easy to switch between computers. Not being able to eject the USB
drive
is annoying, but not a game breaker. Likewise, I usually don't shut
down
when I leave work, so I can't allow orphaned processes to accumulate
eating up CPU and memory.
> but even if you're not, you are not the entire Python community.
This is probably happening to everyone, they just haven't noticed.
> You stated that "3.x won't be adopted by developers until it's fixed".
> It sounds like what you really mean was
> "3.x won't be adopted by *me* until it's fixed"
Not at all. The only 3rd party library I use is gmpy, and that's been
updated, so I have more or less abandoned 2.x in favor of 3.x. I have
not installed the latest 2.6 version and have no intention of ever
installing 2.7
.
>
> 3.x is already being adopted by developers.
Let's hope a little thing like this won't upset them.
> The two biggest factors
> slowing uptake of 3.x are: (1) lack of big libraries like numpy, and (2)
> that major Linux distros still ship with 2.6 or 2.5.
It was even worse with Mac OSX 10.6. Luckily, there's macports, so it
all got resolved.
>
> >> and a million miles from implying that Python 3.x is "seriously broken
> >> and unsuitable for production".
>
> > Maybe because I'm a user, not a developer.
>
> You write code. You use an Integrated DEVELOPMENT Environment. That makes
> you a developer.
Being a little pedantic here, aren't we? Would it help if I said
"professional"
developer? After all, just because I dabble in Collatz Conjecture
research as
a hobby, it doesn't give me the right to go around calling myself a
mathematician.
>
> >> > I expect 2.7 will be around for a long time.
>
> >> As reported on the bug tracker, this bug effects Python 2.7 as well.
> >> It's possible this bug goes back to, what? Python 2.5? 2.4? 2.3? Older?
> >> Who knows?
>
> > I can't imagine my not having noticed this before. It's plausible I
> > might not have noticed the runaway processes, but the fact that I can't
> > eject a USB drive would have been very obvious.
>
> Have you tried to reproduce it on 2.6 or 2.5?
No, all I can say is I haven't noticed it there. And given the
symptoms,
I can't see how I could have not noticed it.
On the other hand, I can't see how it could have gone unnoticed on
3.x.
You don't suppose I'm the only one actually using 3.1?
> Unless you actively try to
> reproduce it, you can't assume it doesn't occur.
True, just as you can't assume I'm the only one it's happening to.
>
> >>http://bugs.python.org/issue8093#msg102818
>
> >> In any case, IDLE is one IDE out of many, and not really up to
> >> professional quality -- it's clunky and ugly. It isn't Python, it is a
> >> tool written in Python.
>
> > You have no idea what the cause is, yet you're certain that the symptom
> > is confined to IDLE.
>
> Certain? Of course not. But given an issue that is reported with a single
> application, which is more likely? That it is a bug in the language, or a
> bug in the application?
*I* never said the LANGUAGE was broken. I specifically made reference
to the
Windows implementation of 3.1.2.
>
> Even if it is a bug in the language, some fundamental failure of the
> underlying Python virtual machine or built-in objects, there are dozens
> of standard library modules, and thousands of third-party modules, that
> it doesn't affect.
I assume you mean when not run in IDLE. And how do you know they're
not
affected? Didn't you just get done yelling at me for not testing it in
2.5 & 2.6?
>
> > That's the kind of thinking that leads to such bugs in the first place.
>
> Riiiight.
You think these bugs are done deliberately?
>
> --
> Steven
--
mph
Haven't we covered argument from fallacy enough in this group by now?
Reporting the bug was exactly the right thing to do. Loudly
pronouncing the impending demise of 3.x because of it was not. Coming
up with exaggerated parodies of arguments that no one here is actually
making is even worse.
> Why do you guys think I'm talking about the language? I'm talking
> about a particular implementation.
Probably because _you_ made no such restriction with your blanket
statement of "3.x won't be adopted by developers until it's fixed". If
only "under Windows", "probably" and "IDLE" had been injected into it,
I don't think there would have been a word of disagreement.
> Additionally, it will give the community further incentive
> to make Python3 all that it was intended to be. Personally, the
> timing of v3 prevented me from fully participating in that effort,
> and, not ignoring the work of those who did contribute, I think many
> of us feel that it has not reached its potential.
The same problem. For me it was possible to participate in standard
library development only after Python Alphas with Windows binaries
were released. I could test both new features and old bugs. Having a
requirement that every developer should be able to compile binaries
has an adverse effect on the quality of standard library.
The absence of public Roadmap also makes it hard to judge the
aforementioned "desired potential".
It could be possible to compile a public list like
http://dungeonhack.sourceforge.net/Roadmap
I am afraid of two things with forthcoming Python releases.
1. feature creeping
2. feature missing
And an overview of Python development in the form of release timer and
roadmap will remove the remnants of fear and uncertainty and surely
attract new people for sprints.
Regardless of said above it is great to feel the hard work behind the
scenes that makes new releases popping up. Thanks.
--
anatoly t.
No, on the grounds that I have an Enterprise Probike, which being chain
driven is vastly superior to any gas guzzling petrol or diesel driven
vehicle. Ok, it's slower, but it gets me there in the end.
Mark Lawrence
So don't.
Orphaned processes only accumulate when you use Restart Shell to abandon
a process stuck in an infinite loop. I personally very seldom do that.
Otherwise, the old process dies in a few seconds and the number of
pythonw processes drops back down from 3 to the normal 2.
As I already said, either roboot or use TaskManager to kill such
zombies. When I had a unix desktop machine, I routinely used the command
line equivalents ps (process status) and kill to do the same thing.
Terry Jan Reedy
Ok. If more people are aware of the issue now, then the hyperbole
has served it's purpose.