A
Alf P. Steinbach
* Steve Holden:
No, as I stated, I'm not into politics.
Cheers & hth.,
- Alf
No, as I stated, I'm not into politics.
Cheers & hth.,
- Alf
S
Steve Holden
Agreed, I have passed that to postmaster at python.org. I am not reallyAlf said:
sure why that mail host was involved in the transaction, but then I
don't spend my days handling email servers.
That's another possibility, yes.
Thanks again for the comments. Let's hope something changes as a result!Other suggestions I have would, I think, require a lot of work. And I'm
not sure it's worth it. But my experience is that Google scores 0 on bug
reporting, not even allowing you to report anything, at all; Microsoft
scores 8 or so, up from 1 on my scale (they used to have
lead-you-around-in-circles forms leading to punch-you-in-the nose server
errors etc., like Google now, but worse because you were paying for
this!, but they totally changed their tune a few years back, now really
good, *except* for the worst most bloated MS software/malware ever, the
Microsoft installer, which unfortunately CPython uses, a light-weight
installer would be much better!); and then the GNU g++ team scores top
marks, 10+, because I've had a g++ bug reported and fixed within just
hours!
regards
Steve
T
Terry Reedy
I disagree. The point of mail confirmation is not just to assure that a
human is registering, but that we have a valid email for responses to be
sent to. Many issues are filed with inadaquate info (platform, Python
version, full traceback, adequate code snippet, or whatever). So we need
to be able to reach a person.
Besides which, automated image recognition + barely paid human captcha
farms have made letter image increasingly useless. Many are now so
obscure that *I* usually get them wrong.
If there were to be a 'human verifier' system, it might be better based
on file-in-the-blank questions about Python.
What might be changed more easily is to accept a report but impound it
until the confirmation reply. Being able to spit out what one has to say
while it is still fresh in the mind should make the email wait more
tolerable. What do you think?
Terry Jan Reedy
S
Steven D'Aprano
Before pointing out the mote in another person's eye, you should consider
the enormous beam in yours. You initially reported a completely bogus
error (NameError: name 'framerate' is not defined) and Brian responded to
that.
I don't know why you're claiming he was responding to a name that was
commented out, when you included a traceback clearly showing that the
line was executed.
If we're supposed to think Brian "is really just making a mess of
things" (your words) for responding to incorrect information, what are we
supposed to think of the person who submitted the incorrect information
in the first place?
I think you need to chill out and stop treating a simple bug report as a
personal slight on you.
S
Steven D'Aprano
So you allege, but André points out that there are existing, non-trivial
applications that work unmodified under both Python 2.x and 3.x. For
example, CherryPy:
http://www.cherrypy.org/wiki/WhatsNewIn32
You're welcome to your own opinion, of course, but not your own reality,
and the reality is that it is NOT "hopeless" to write correct Python code
that operates under both 2.6 and 3.x. It's not hopeless because it's been
done. You might even be able to target versions older than 2.6 if you
really work at it, as CherryPy does.
Continuing to assert something which is demonstrably untrue simply means
you lose credibility among those who are familiar with Python.
Right, and if your application requires PIL, then it is impossible, but
for the countless applications that *don't* require PIL, it makes no
difference at all.
[...]
from __future__ import division
from __future__ import print_function
from future_builtins import hex, map # or whatever
Not even close to hopeless.
A
Alf P. Steinbach
* Steven D'Aprano:
You're confusing the existence of special cases where something has been done,
at great cost, with a belief that it's practical to do so in general.
It's not exactly like confusing existential versus universal quantification, but
it's close.
Thus, your demonstration amounts to "it's not hopeless to walk on the moon:
look, Louis Armstrong did!" -- uh, Neil, whatever.
He he.
No, sorry, I apologize, I'm unkind now.
*Slapping my keyboard hand*
But it gets to me how often people here sort of rise to the defense of Python as
if it needed defending.
It's a great language, it needs no defense, especially not of the kind where one
tries to suppress facts and silence critique. Indeed, what it needs seems to
instead be the opposite, a good dose of reality and openness. The reality is
that the divide between 2.x and 3.x is still very wide, and utterly hopeless for
a newbie to cross (professionals can do so at great cost).
Over in C++-land it's opposite.
Even the most enhusiastic C++ programmers almost revel in finding faults with
the language and its standard library, tools etc. And I think that's because
there's no inferiority complex, or very little of it. So, repeating: Python is a
great language, it really is, but There Are Issues, of course there are issues,
and the best way or at least a good way to go about it is adopt that (great, but
of course has issues) as one's basic view, and be critical.
They require other stuff.
Plus, the basic language issues are at the core of all these problems.
But see above.
You might consider that I'm very much aware of the above facilities.
Then be a little critical and think about, what problems could it be that, in
spite of that to you apparent simplicity, hinders the widespread adoption of
Python 3.x?
Repeating, Python is a great language. I'm not about dissing the language. I
think it's rather silly when people believe that, and it's rather sad when they
then employ negative sum thinking: think positive!
Cheers & hth.,
- Alf
You're confusing the existence of special cases where something has been done,
at great cost, with a belief that it's practical to do so in general.
It's not exactly like confusing existential versus universal quantification, but
it's close.
Thus, your demonstration amounts to "it's not hopeless to walk on the moon:
look, Louis Armstrong did!" -- uh, Neil, whatever.
He he.
No, sorry, I apologize, I'm unkind now.
*Slapping my keyboard hand*
But it gets to me how often people here sort of rise to the defense of Python as
if it needed defending.
It's a great language, it needs no defense, especially not of the kind where one
tries to suppress facts and silence critique. Indeed, what it needs seems to
instead be the opposite, a good dose of reality and openness. The reality is
that the divide between 2.x and 3.x is still very wide, and utterly hopeless for
a newbie to cross (professionals can do so at great cost).
Over in C++-land it's opposite.
Even the most enhusiastic C++ programmers almost revel in finding faults with
the language and its standard library, tools etc. And I think that's because
there's no inferiority complex, or very little of it. So, repeating: Python is a
great language, it really is, but There Are Issues, of course there are issues,
and the best way or at least a good way to go about it is adopt that (great, but
of course has issues) as one's basic view, and be critical.
They require other stuff.
Plus, the basic language issues are at the core of all these problems.
But see above.
You might consider that I'm very much aware of the above facilities.
Then be a little critical and think about, what problems could it be that, in
spite of that to you apparent simplicity, hinders the widespread adoption of
Python 3.x?
Repeating, Python is a great language. I'm not about dissing the language. I
think it's rather silly when people believe that, and it's rather sad when they
then employ negative sum thinking: think positive!
Cheers & hth.,
- Alf
A
Alf P. Steinbach
* Steven D'Aprano:
No, the out-commented line was not executed and was not shown in any traceback.
Comments are not executed.
I'm sorry but you're trying to make people believe something that you know is
false, which is commonly called lying.
The error report included the line numbers of the buggy lines, plus a correction
of the output: I first pasted incorrect error message, then corrected that
*immediately*. But I just found no way to edit the original message, so both
that and the correction ended up present. The correction with "Sorry, here's the
correct message", or words to that effect. In the one and only original submission.
So it's not like the person responding should have any problem at all, and it's
not like he was presented with incorrect information. To top it off he did not
respond to the output that was corrected. He believed the problem was a name in
a comment.
I'm sorry but you're again trying to make people believe something that you know
is false, which is commonly called lying: it is not the case that I have strong
feelings or any feelings at all about that bug report or any other.
But you're starting to annoy me.
I think it's OK when you respond to technical issues where you have
misunderstood something basic, even when you do that by assertion, as you
usually do (it would be better if you just asked about things that you don't
understand). But it's not OK when you're trying to create impressions that are
false, and it's not OK when you try to demonstrate telepathic powers and discuss
others' emotions and motivations. I tell you straight.
- Alf
No, the out-commented line was not executed and was not shown in any traceback.
Comments are not executed.
I'm sorry but you're trying to make people believe something that you know is
false, which is commonly called lying.
The error report included the line numbers of the buggy lines, plus a correction
of the output: I first pasted incorrect error message, then corrected that
*immediately*. But I just found no way to edit the original message, so both
that and the correction ended up present. The correction with "Sorry, here's the
correct message", or words to that effect. In the one and only original submission.
So it's not like the person responding should have any problem at all, and it's
not like he was presented with incorrect information. To top it off he did not
respond to the output that was corrected. He believed the problem was a name in
a comment.
I'm sorry but you're again trying to make people believe something that you know
is false, which is commonly called lying: it is not the case that I have strong
feelings or any feelings at all about that bug report or any other.
But you're starting to annoy me.
I think it's OK when you respond to technical issues where you have
misunderstood something basic, even when you do that by assertion, as you
usually do (it would be better if you just asked about things that you don't
understand). But it's not OK when you're trying to create impressions that are
false, and it's not OK when you try to demonstrate telepathic powers and discuss
others' emotions and motivations. I tell you straight.
- Alf
A
Alf P. Steinbach
* Terry Reedy:
I think those are all good points.
Cheers,
- Alf
I think those are all good points.
Cheers,
- Alf
S
Stefan Behnel
Alf P. Steinbach, 13.01.2010 06:39:
Unless you can prove that it's *not* practical in general, you will have to
live with the fact that it was, and continues to be, practical for existing
code bases (and certainly for new code), so it clearly is not hopeless to
do so, not even "in general".
Stefan
Unless you can prove that it's *not* practical in general, you will have to
live with the fact that it was, and continues to be, practical for existing
code bases (and certainly for new code), so it clearly is not hopeless to
do so, not even "in general".
Stefan
S
Stefan Behnel
Alf P. Steinbach, 13.01.2010 06:55:
Then why don't you just stop blaming the world for that terrible doom that
was laid upon you by running into a bug?
Funny that it's you writing that.
Stefan
Then why don't you just stop blaming the world for that terrible doom that
was laid upon you by running into a bug?
Funny that it's you writing that.
Stefan
S
Steven D'Aprano
(1) Most Linux distributions still come standard with Python 2.5 or
older, not even 2.6. Consequently, most developers are still writing for
2.5 or even 2.4 and won't even consider 3.1 until the distros provide it
as standard. Apple also comes standard with 2.5, and I believe that when
hardware vendors supply it on Windows systems, it's typically 2.5 also.
(2) Because of the negativity of people overstating the differences
between 2.x and 3.x.
(3) And because of the slow pace at which major third-party libraries
have supported 3.x, which is mostly a matter of man-power rather than
technical difficulty.
It is difficult to support both 2.4 and 2.5, because 2.5 introduces a
whole lot of excellent features that 2.4 doesn't have. I know, because
I've tried. (After spending much effort trying to develop my own
compatibility layer, I eventually decided to just stop supporting 2.4.)
Do people go on and on and on about how it is "hopeless" to support
multiple versions of 2.x? No, of course they don't. It requires extra
work, and it's inconvenient, but it can be done and it is done.
Trying to support everything from 2.0 to 3.1 would be horrible, but not
because 3.1 is so different from 2.x. The oldest versions of the 2.x
series lack so many features that have become fundamental to modern
Python: no generators, no decorators, no iterators, and others. But
supporting 2.6 and 3.0/3.1 is nothing as so hard. I would argue that,
fundamentally, there are fewer differences between 2.6 and 3.1 than
between 2.1 and 2.5.
Upgrading a major application or library to support 3.x is a big job,
simply because *any* re-factorising of a major application is a big job.
But writing a new application supporting 2.6 and 3.x from scratch is a
much simpler process. Likewise writing small scripts.
To say as you do that the change in the semantics of the division
operator makes the task "hopeless" is simply ridiculous. It's a one-line
fix: "from __future__ import division" at the top of each module, and you
now have identical semantics in both 2.6 and 3.x.
Nobody is trying to understate the complexity of writing a large
application that supports both 2.6 and 3.x, or of taking an existing
library written for 2.5 and upgrading it to support 3.1. But the
magnitude of these tasks is no greater (and potentially smaller) than
supporting (say) 2.3 through 2.5. To describe it as "hopeless" is simply
mistaken and weakens your credibility.
S
Stefan Behnel
Terry Reedy, 13.01.2010 04:40:
Sounds like a very good idea to me. It could still send out a notification
to the relevant component maintainers, so that they can deal with the bug
(e.g. open it up manually or drop it as spam) even if the reporter takes a
day or two to respond to the confirmation e-mail.
Stefan
Sounds like a very good idea to me. It could still send out a notification
to the relevant component maintainers, so that they can deal with the bug
(e.g. open it up manually or drop it as spam) even if the reporter takes a
day or two to respond to the confirmation e-mail.
Stefan
A
Alf P. Steinbach
* Stefan Behnel:
Simple proof: Python 3.x still lacks widespread usage.
Cheers & hth.,
- Alf
Simple proof: Python 3.x still lacks widespread usage.
Cheers & hth.,
- Alf
A
Alf P. Steinbach
* Stefan Behnel:
I'm sorry but as Steven did in the quoted material above you're trying to make
people believe something that you know is false: I haven't blamed the world, nor
described the bug as terrible or a doom, and you know that.
On the other hand, I did let out some steam here, at the start of thread.
While making sure that nobody else would have to waste time on that bug.
It shouldn't be anything to get upset by.
However, that happens. In Norway in the week that was a woman died because the
emergency services got upset about the nephew's strong language. They decided
that instead of an ambulance let's send the police, so the poor woman died while
the police where shackling all the relatives (with force) outside the house...
Yeah, it's understandable if you harbor Negative Feelings about me. I have the
annoying habit of seeing that something's wrong and saying it, and as I recall
there was a very poular movie about such a guy once, where many of the laughs
came from just how incredibly annoying it was that he was right all the time in
spite of his social position at the bottom of the ladder, sort of exremely
incongruous. Happily *I* am often wrong, perhaps 40% of the contested issues, so
if you focus on that then perhaps all may still be well.
Cheers & hth.,
- Alf
I'm sorry but as Steven did in the quoted material above you're trying to make
people believe something that you know is false: I haven't blamed the world, nor
described the bug as terrible or a doom, and you know that.
On the other hand, I did let out some steam here, at the start of thread.
While making sure that nobody else would have to waste time on that bug.
It shouldn't be anything to get upset by.
However, that happens. In Norway in the week that was a woman died because the
emergency services got upset about the nephew's strong language. They decided
that instead of an ambulance let's send the police, so the poor woman died while
the police where shackling all the relatives (with force) outside the house...
Yeah, it's understandable if you harbor Negative Feelings about me. I have the
annoying habit of seeing that something's wrong and saying it, and as I recall
there was a very poular movie about such a guy once, where many of the laughs
came from just how incredibly annoying it was that he was right all the time in
spite of his social position at the bottom of the ladder, sort of exremely
incongruous. Happily *I* am often wrong, perhaps 40% of the contested issues, so
if you focus on that then perhaps all may still be well.
Cheers & hth.,
- Alf
S
Stefan Behnel
Alf P. Steinbach, 13.01.2010 09:00:
I admit that I took the freedom to rephrase your original wording.
So, if I understand your anecdote right, who is it you are trying to kill here?
Sorry to disappoint you - I don't.
Stefan
I admit that I took the freedom to rephrase your original wording.
So, if I understand your anecdote right, who is it you are trying to kill here?
Sorry to disappoint you - I don't.
Stefan
S
Steven D'Aprano
I have no idea what commented lines NOT shown you are talking about, but
you attacked Brian for referring to the NameError relating to framerate.
You claimed that he was:
thinking instead that maybe a "wrong" name in *a comment*
might be the culprit
But in fact your initial error report included this traceback, which
displays a very much uncommented line of code:
Traceback (most recent call last):
File "C:\Documents and Settings\Alf\sound\error.py", line 6, in <module>
writer.setframerate( framerate )
NameError: name 'framerate' is not defined
Alf, I know you are able to read tracebacks, because you've demonstrated
the ability in the past. And I'm pretty sure that you're aware that can
too, because you're not an idiot.
So what puzzles me is, given that you can read the traceback you posted,
and we can too, why on earth do you claim that the reference to framerate
was commented out? The line that was executed is right there.
Really? Well, that explains why none of my programs do anything!
*wink*
Right. A simple, silly error that anyone could have made. We've all made
similarly embarrassing mistakes.
But you then responded with a public put-down on Brian all out of
proportion for his sin of *answering your initial post*. And that just
makes you look obnoxious.
It must be nice to know what other people are thinking.
What am I thinking now?
Reading back over this thread, it's obvious how cool, calm and collected
you are. I can't imagine what I was thinking, that somebody who would say
"Well how f*****g darn patient do they expect me to be?"
has strong feelings over the issue?
(For the sarcasm impaired, that's sarcasm.)
I'm truly sorry to hear that.
A
Alf P. Steinbach
* Steven D'Aprano:
It seems that people here put a lot of meaning into "hopeless"...
Would it be better to say that it's "hard" or "very hard" or "impractical for
the novice"?
After all, the bug that this thread is about demonstrated that unit tests
designed for 2.x do not necessarily uncover 3.x incompatibilities.
Even at the level of Python's own standard library.
But, regarding reformulations that don't imply untrue things to anyone (or
nearly), I'd like the text on that page to still fit on one page.
Cheers,
- Alf
It seems that people here put a lot of meaning into "hopeless"...
Would it be better to say that it's "hard" or "very hard" or "impractical for
the novice"?
After all, the bug that this thread is about demonstrated that unit tests
designed for 2.x do not necessarily uncover 3.x incompatibilities.
Even at the level of Python's own standard library.
But, regarding reformulations that don't imply untrue things to anyone (or
nearly), I'd like the text on that page to still fit on one page.
Cheers,
- Alf
S
Steven D'Aprano
Only the dictionary meaning.
I don't even know why you feel the need to discuss 2.x in a book that's
about 3.x.
But given that you feel the need to, all I can ask is that you don't
overstate the difficulty. For a new project that doesn't rely on third-
party libraries that don't support 3.x, supporting 2.6 - 3.x shouldn't be
much harder than (say) supporting 2.3 through 2.5. That is to say, of
course it's hard, but it's always hard to support a range of versions
with different capabilities. The transition to 3.x is no different in
that regard.
A
Alf P. Steinbach
* Steven D'Aprano:
Well, first, let me state that this is debating details of something irrelevant
to anything.
Now, that said, Brian responded (first response, Brian subsequently made a patch
which fixed not just the bugs but also the unit test, so very good everything!),
<quote>
In your example, the "n_frames" name does not exist, which is causing the
problem. In your first comment, "framerate" also did not exist.
I don't know what a proper frame rate value is, but I just put 10 in there
and it worked fine. Can you confirm?
</quote>
Note that the "n_frames" that Brian here thinks "is causing the problem" is a
name only used in a comment in the demo code.
Note (1) that "n_frames" does *not* occur here -- or anywhere.
And that (2) the error report included this correction:
<quote>
Sorry, here's correct error message:
Traceback (most recent call last):
File "C:\Documents and Settings\Alf\sound\error.py", line 8, in <module>
writer.writeframes( b"\0"*2*4 )
File "C:\Program Files\cpython\python31\lib\wave.py", line 432, in writeframes
self.writeframesraw(data)
File "C:\Program Files\cpython\python31\lib\wave.py", line 416, in writeframesraw
self._ensure_header_written(len(data))
File "C:\Program Files\cpython\python31\lib\wave.py", line 459, in
_ensure_header_written
self._write_header(datasize)
File "C:\Program Files\cpython\python31\lib\wave.py", line 472, in _write_header
self._sampwidth * 8, 'data'))
struct.error: required argument is not an integer
Exception struct.error: 'required argument is not an integer' in <bound method
Wave_write.__del__ of <wave.Wave_write ob
ject at 0x00FE87F0>> ignored
</quote>
Which you can see that Brian was very well aware of, since he referred to <q>In
your first comment, "framerate" also did not exist.</q>, as opposed to this
corrected output.
But again, even though he did get off on the wrong foot, probably assuming that
it was a novice posting (and regarding Python I'm still a novice!), after that
he did superb job. So very much thanks to him, people will not have to struggle
with this bug. And perhaps the [wave] module will start getting more used!
I don't claim and haven't claimed that framerate was commented out.
I referred to the fact that Brian (at first) thought that "n_frames" was, quote,
"causing the problem", and that that name only occurred in a comment.
Nah, I didn't mention his name nor link to the error report.
Because I've made similar mistakes based on too low intake of coffee.
And after that, as mentioned, he did a superb job!
Of course I had strong feelings about the time wasted on the bug, and I'm not
one to hold my tongue, in general...
But no strong feelings about the bug report or handling of it.
I'm sure that you can understand that distinction, the two very different issues
(time wasted versus a puzzling Thorbjørning) now that I point it out, yes?
Just for good measure, let me once again point out that Brian, whom I didn't
name or refer to then, turned out to then do a superb job.
And in about no time at all.
Cheers,
- Alf
Well, first, let me state that this is debating details of something irrelevant
to anything.
Now, that said, Brian responded (first response, Brian subsequently made a patch
which fixed not just the bugs but also the unit test, so very good everything!),
<quote>
In your example, the "n_frames" name does not exist, which is causing the
problem. In your first comment, "framerate" also did not exist.
I don't know what a proper frame rate value is, but I just put 10 in there
and it worked fine. Can you confirm?
</quote>
Note that the "n_frames" that Brian here thinks "is causing the problem" is a
name only used in a comment in the demo code.
Note (1) that "n_frames" does *not* occur here -- or anywhere.
And that (2) the error report included this correction:
<quote>
Sorry, here's correct error message:
Traceback (most recent call last):
File "C:\Documents and Settings\Alf\sound\error.py", line 8, in <module>
writer.writeframes( b"\0"*2*4 )
File "C:\Program Files\cpython\python31\lib\wave.py", line 432, in writeframes
self.writeframesraw(data)
File "C:\Program Files\cpython\python31\lib\wave.py", line 416, in writeframesraw
self._ensure_header_written(len(data))
File "C:\Program Files\cpython\python31\lib\wave.py", line 459, in
_ensure_header_written
self._write_header(datasize)
File "C:\Program Files\cpython\python31\lib\wave.py", line 472, in _write_header
self._sampwidth * 8, 'data'))
struct.error: required argument is not an integer
Exception struct.error: 'required argument is not an integer' in <bound method
Wave_write.__del__ of <wave.Wave_write ob
ject at 0x00FE87F0>> ignored
</quote>
Which you can see that Brian was very well aware of, since he referred to <q>In
your first comment, "framerate" also did not exist.</q>, as opposed to this
corrected output.
But again, even though he did get off on the wrong foot, probably assuming that
it was a novice posting (and regarding Python I'm still a novice!), after that
he did superb job. So very much thanks to him, people will not have to struggle
with this bug. And perhaps the [wave] module will start getting more used!
I don't claim and haven't claimed that framerate was commented out.
I referred to the fact that Brian (at first) thought that "n_frames" was, quote,
"causing the problem", and that that name only occurred in a comment.
Nah, I didn't mention his name nor link to the error report.
Because I've made similar mistakes based on too low intake of coffee.
And after that, as mentioned, he did a superb job!
Of course I had strong feelings about the time wasted on the bug, and I'm not
one to hold my tongue, in general...
But no strong feelings about the bug report or handling of it.
I'm sure that you can understand that distinction, the two very different issues
(time wasted versus a puzzling Thorbjørning) now that I point it out, yes?
Just for good measure, let me once again point out that Brian, whom I didn't
name or refer to then, turned out to then do a superb job.
And in about no time at all.
Cheers,
- Alf
L
Lie Ryan
Alf said:* Stefan Behnel:
Simple proof: Python 3.x still lacks widespread usage.
That's not a really sound proof, there was a after the release of 2.6
that people start migrating their code from 2.5; migration to 3.x is not
going to be different. Even nowadays, there are still a lot of codes
targeted for python 2.5 or 2.4 that will never have a chance to be
ported to 2.6.
It is valid to argue that the time gap is a bit longer in python 3.x;
but don't forget that 3.0 is intended to be a "preview" version, 3.1 a
beta and 3.2 a more stable production release. The recommended migration
path is to port to 2.x code to 2.6 then to 2.7 and then to 3.x. So to
establish a fairer comparison of the migration gap, you would have to
measure the adoption time between 2.7 to 3.2 (or 2.6 to 3.1, but not to
3.0).
We have yet releases 2.7 and 3.2, so it is still not possible to tell
how hard it is people think porting to 3.x is.
if what you said is true, that will be a proof that python programmer's
PHI (programmer's happiness index) is higher than C++'s