Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74881 > unrolled thread

PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!

Back to article view | Back to comp.lang.python

Contents

  PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-20 14:14 -0700
    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-20 22:36 +0100
    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2014-07-20 23:40 +0200
      Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-20 15:44 -0700
        Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-21 11:02 +1000
          Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-20 19:06 -0700
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Tim Chase <python.list@tim.thechases.com> - 2014-07-20 21:30 -0500
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-21 12:38 +1000
              Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 14:27 +0000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Shiyao Ma <i@introo.me> - 2014-07-21 22:40 +0800
                  Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 16:51 +0000
                    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 16:57 +0000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 00:48 +1000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 00:51 +1000
                  Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 16:55 +0000
                    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 03:56 +1000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Monte Milanuk <memilanuk@invalid.com> - 2014-07-21 14:55 +0000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-21 16:19 +0100
                  Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 16:56 +0000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 01:27 +1000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Lele Gaifax <lele@metapensiero.it> - 2014-07-21 17:57 +0200
                  Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-21 17:03 +0000
                    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Lele Gaifax <lele@metapensiero.it> - 2014-07-21 19:40 +0200
                    Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-18 20:49 +0200
                      Re: Adapt bash readline operate-and-get-next Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-19 10:17 +1000
                        Re: Adapt bash readline operate-and-get-next Chris Angelico <rosuav@gmail.com> - 2014-08-19 10:32 +1000
                        Re: Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-19 10:49 +0200
                        Re: Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-19 11:51 +0200
                    Re: Adapt bash readline operate-and-get-next Skip Montanaro <skip@pobox.com> - 2014-08-18 14:06 -0500
                    Re: Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-19 10:44 +0200
                    Re: Adapt bash readline operate-and-get-next Skip Montanaro <skip@pobox.com> - 2014-08-19 07:45 -0500
                    Re: Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-19 15:10 +0200
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 02:05 +1000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Terry Reedy <tjreedy@udel.edu> - 2014-07-21 15:16 -0400
              RE: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! "Coll-Barth, Michael" <Michael.Coll-Barth@VerizonWireless.com> - 2014-07-21 10:51 -0400
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-21 03:45 +0100
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Terry Reedy <tjreedy@udel.edu> - 2014-07-20 23:05 -0400
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-21 13:09 +1000
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Martin S <shieldfire@gmail.com> - 2014-07-21 09:51 +0200
      Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!) Tim Chase <python.list@tim.thechases.com> - 2014-07-20 19:56 -0500
      Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!) Chris Angelico <rosuav@gmail.com> - 2014-07-21 11:04 +1000
      Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!) Tim Chase <tim@thechases.com> - 2014-07-20 19:55 -0500
    Idle open file dialogs (was ...) Terry Reedy <tjreedy@udel.edu> - 2014-07-20 22:59 -0400

Page 1 of 3  [1] 2 3  Next page →

#74881 — PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!

============================================================
 BUG 1: FileDialog Duplicity:
============================================================

If you open the IDLE application (either utilizing the
"shell window" or "editor window") and then go to the "File"
menu and choose the "Open" command you will see a file
dialog appear, okay, nothing wrong with that.

HOWEVER, if you go to the "File" menu *AGAIN* choose the
"Open" command, you will see *ANOTHER* file dialog open.

    Note that on windows (at least), the new file dialogs are
    stacked *perfectly* on top of old filedialogs, so you will
    need to move the top dialog before you can see any
    hiding below.

And not only can you open more than one dialog ,there seems
to be no limit on the number of dialogs you can open!

Modal dialogs *MUST* be limited to a "one dialog at a time"
policy. And even *IF* the designers of Tkinter were too
naieve to relize this, the designers of IDLE should have
been intelligent enough to ensure this cannot happen,
because, opening more than one filedialog is about has
useful as buying shoes in sets of greater than two.

    Two feet -> two shoes.

    One document -> one dialog

    or rather,

    One dialog per "active" document!

And since IDLE is not a "tabbed editor", only *1* document
is going to be displayed at a time. The troubling issue is,
Tkinter filedialogs are working fine (see my code at the end
of this message which proves my statement!), whereas the
IDLE dialogs which utilize Tkinter code are not!

    ============================================================
     POSSIBLE FIX FOR "BUG 1":
    ============================================================

    If for some reason IDLE is not using the tkFileDialogs, a
    simple "request contract" can solve the issue by setting a
    "counter variable" like "activeFileDialogs = 0", then
    incrementing the counter by 1 each time a filedialog is
    displayed, and then decrementing the value by one each time
    a filedialog is closed. Furturemore, each time a filedialog
    is "requested", the logic will deny the request *IF* the
    value of "activeFileDialogs" is greater than one. However,
    this all seems rediculous since Tkinter filedialogs are
    working as expected! (see code at end of this message)

============================================================
 BUG 2: FileDialog "Hide and go seek":
============================================================

When you have a filedialog displayed *AND* the "parent
window" from which you spawned the filedialog is in "full
screen" mode, if you (or your OS) decides to "unfocus" the
"parent window" window, when you return you will *NOT* see
the open dialog, because the filedialog will be hidden
*BEHIND* the full screen "parent window".

Again, this only happens in IDLE, but in my example code at
the end of this message you will find that the dialog
behaves as expected.

============================================================
 BUG 3: FileDialog not using "native" dialogs anymore.
============================================================

Currently, when opening a filedialog in IDLE, i don't get
the "shortcut pane" that is visible in my Windows Explorer
application, *HOWEVER*, before i updated to version 2.7.8 i
swear it was there!

    WHAT THE HECK HAPPNED?

============================================================
 REFERENCES:
============================================================

############################################################
# BEGIN CODE
############################################################
# The following code proves that Tkinter filedialogs are
# behaving in expected manners (properly placed as children
# of the windows which "own" them, and following normal
# focus patterns of "child windows" -- therfore, the problem
# *MUST* be an IDLE problem.
#
# Tested on Python 2.7.8
#
import Tkinter as tk
from tkFileDialog import askopenfilename, asksaveasfilename

class App(tk.Tk):
    def __init__(self):
        tk.Tk.__init__(self)
        self._createMenus()

    def _createMenus(self):
        menubar = tk.Menu(self)
        self.config(menu=menubar)
        filemenu = tk.Menu(menubar)
        menubar.add_cascade(label='File', menu=filemenu)
        filemenu.add_command(label='Open', command=self.requestOpenDialog)
        filemenu.add_command(label='Save As', command=self.requestSaveAsDialog)

    def _requestFileDialog(self, func, **kw):
        path = func(**kw)
        return path

    def requestOpenDialog(self, **kw):
        return self._requestFileDialog(askopenfilename, **kw)

    def requestSaveAsDialog(self, **kw):
        return self._requestFileDialog(asksaveasfilename, **kw)

if __name__ == '__main__':
    app = App()
    app.mainloop()
#
############################################################
# END CODE
############################################################

[toc] | [next] | [standalone]

#74882

On 20/07/2014 22:14, Rick Johnson wrote:
>

[loads of stuff snipped]

Why bother writing all that here, why not put it all on the bug tracker, 
or has that already been done, either by you or someone else?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#74883

On 20-7-2014 23:14, Rick Johnson wrote:

> And since IDLE is not a "tabbed editor", only *1* document
> is going to be displayed at a time.

False. Idle opens any number of documents at the same time just fine (in different
windows - rather than tabs).
While I don't see the use case for the possibility of having multiple file dialogs open
at the same time, it doesn't really hurt either does it?


> ============================================================
>  BUG 3: FileDialog not using "native" dialogs anymore.
> ============================================================
> 
> Currently, when opening a filedialog in IDLE, i don't get
> the "shortcut pane" that is visible in my Windows Explorer
> application, *HOWEVER*, before i updated to version 2.7.8 i
> swear it was there!

Not sure what you mean. What's the "shortcut pane"?
I do notice that my Idle from Python 3.4.1 does indeed not use a native file dialog, it
has a weird icon bar at the left side (win xp era layout?) My idle from 2.7.6 (haven't
upgraded yet) uses the native explorer dialog. That is odd indeed. Maybe there's a
reason for it, maybe it's a bug, I don't know.


Irmen

[toc] | [prev] | [next] | [standalone]

#74885

On Sunday, July 20, 2014 4:40:59 PM UTC-5, Irmen de Jong wrote:
> On 20-7-2014 23:14, Rick Johnson wrote:
> > And since IDLE is not a "tabbed editor", only *1*
> > document is going to be displayed at a time.
> False. Idle opens any number of documents at the same time
> just fine (in different windows - rather than tabs).

Yes, your statement is true, and here are a few facts about
the IDLE interface that support your statement:

  1. IDLE allows the "spawning" of an unlimited number of
  "IDLE editor windows", which each "editor window" acting
  as a (potential) container for a document -- which
  "loosely" emulates (albeit in a discombobulated manner) a
  "tabbed editor".

  2. IDLE also allows one *OPTIONAL* instance of the "IDLE
  shell window" to exist.

> While I don't see the use case for the possibility of
> having multiple file dialogs open at the same time, it
> doesn't really hurt either does it?

Actually yes, it does, for the reasons i explained in my OP:

Filedialogs should be "truly modal", and like any modal
dialog, should present themselves to the user utilizing
blocking -- that is the whole point of "modal dialogs", to
*BLOCK* further execution of the application *UNTIL* the
user provides (generally speaking) an "answer" to a
"question".

In order to facilitate *SMOOTH* interfacing between the user
and the modal dialog, the "contract of modal dialogs" must
be strictly obeyed:

  When presented with a modal dialog, a user is given only
  two choices -- he must *interact* with the dialog, or he
  must cancel the dialog. During the time which the dialog
  is displayed, all attempts by the user to unfocus,
  minimize, or otherwise exit the dialog will not be allowed
  -- except via the *explicitly* defined interaction
  mechanisms of the dialog itself, for instance, via "okay"
  and "cancel" buttons.

So, even if IDLE does allow multiple "editor windows" to
exists concurrently, allowing multiple filedialogs to exist
concurrently is not only un-useful, it is downright
confusing. GUI programming has been around for decades, so
there is no excuse for us not creating smooth interactions
between a user and his modal dialogs.

> Not sure what you mean. What's the "shortcut pane"? I do
> notice that my Idle from Python 3.4.1 does indeed not use
> a native file dialog, it has a weird icon bar at the left
> side (win xp era layout?)

Yes, that is the legacy "shortcut bar" i'm referring to!
Before upgrading, IDLE was utilizing the more updated
version of windows explorer that includes quite a few
personalized shortcuts.

[toc] | [prev] | [next] | [standalone]

#74888

On Mon, Jul 21, 2014 at 8:44 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Filedialogs should be "truly modal", and like any modal
> dialog, should present themselves to the user utilizing
> blocking -- that is the whole point of "modal dialogs", to
> *BLOCK* further execution of the application *UNTIL* the
> user provides (generally speaking) an "answer" to a
> "question".
>
> In order to facilitate *SMOOTH* interfacing between the user
> and the modal dialog, the "contract of modal dialogs" must
> be strictly obeyed:

File dialogs can be modal or modeless. That's been true since the very
first time I met them (which, admittedly, wasn't until the early 90s;
maybe someone remembers earlier and can tell me if they were
inherently modal 25+ years ago?), and there are good reasons for both
operation styles. Even if your dialog is modal, it's extremely common
to NOT block the application, but merely prevent interaction;
otherwise, your main window won't repaint, which is generally
considered to be a flaw. Rick, have you ever done any serious GUI
programming in anything other than Tkinter? Are you seriously unaware
of standard GUI widget functionality?

ChrisA

[toc] | [prev] | [next] | [standalone]

#74893

On Sunday, July 20, 2014 8:02:11 PM UTC-5, Chris Angelico wrote:
> File dialogs can be modal or modeless. [...] and there are
> good reasons for both operation styles [...] Are you
> seriously unaware of standard GUI widget functionality?

Chris i get so tired of your trolling, you cannot just post
chastisements of me without proving your side beyond a shadow
of a doubt, which you have failed (yet again) to do.

Since most people in this community are not experienced with
the bugs of IDLE, i will now present you with the steps
required to reproduce the two filedialog bugs i mentioned in
my first post of this thread.

Chris, i challenge you to follow these direction and then
report back on this thread your opinion on what "benefits"
these buggy filedialog displays are offering to IDLE. Myself
and others would just *love* to hear your opinions.

============================================================
 STEPS TO REPRODUCE BUG 1: "Attack of the clones!"
============================================================

1. Open the IDLE application
2. Maximize the window that appears
3. Go to the "File Menu" and choose the "Open" command

Now repeat step 3 at least one more time, but feel free to
keep opening new dialogs until your fingers bleed and/or
eyes pop out.

Okay, now tell us, in what manner can an "interface bug"
like this be "beneficial"?

============================================================
 STEPS TO REPRODUCE BUG 2: "Hide and go seek!"
============================================================

1. Open the IDLE application
2. Maximize the window that appears
3. Go to the "File Menu" and choose the "Open" command
4. Without disturbing the dialog, minimize the main window 
5. Using the taskbar icon, maximize the window 

Where is the dialog? How will you retrieve it *WITHOUT*
reducing the size of the window? And even if you are smart
enough to "intuit" what happened to the dialog, and how to
retrieve it, how will a noobie "intuit" such a disappearing
act? And how in the hell can this be beneficial?

[toc] | [prev] | [next] | [standalone]

#74895

On 2014-07-20 19:06, Rick Johnson wrote:
> ============================================================
>  STEPS TO REPRODUCE BUG 1: "Attack of the clones!"
> ============================================================
> 
> 1. Open the IDLE application
> 2. Maximize the window that appears
> 3. Go to the "File Menu" and choose the "Open" command
> 
> Now repeat step 3 at least one more time, but feel free to
> keep opening new dialogs until your fingers bleed and/or
> eyes pop out.

In the versions of IDLE that I have here (2.7.3 and 3.2.3), both
prevent me from repeating step #3 multiple times.

> ============================================================
>  STEPS TO REPRODUCE BUG 2: "Hide and go seek!"
> ============================================================
> 
> 1. Open the IDLE application
> 2. Maximize the window that appears
> 3. Go to the "File Menu" and choose the "Open" command
> 4. Without disturbing the dialog, minimize the main window 
> 5. Using the taskbar icon, maximize the window 
> 
> Where is the dialog?

Right where I left it?  Are you running with a broken window manager
that prevents you from seeing the dialog?  Sure, because I activated
the main IDLE window, it covers the dialog, but I can just select the
Open dialog in my task-bar and it pops to the top (alternatively, I
could have it display at a higher layer to prevent it from getting
covered by the main IDLE window). This is the behavior I want and
expect (I often want to refer to text in one window to inform my
decisions in a modal window).

I've got it running under Fluxbox on Debian Stable and it does exactly
what I want/expect.

-tkc

[toc] | [prev] | [next] | [standalone]

#74896

On Mon, Jul 21, 2014 at 12:06 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
>  STEPS TO REPRODUCE BUG 1: "Attack of the clones!"
>
> 1. Open the IDLE application
> 2. Maximize the window that appears
> 3. Go to the "File Menu" and choose the "Open" command
>
> Now repeat step 3 at least one more time, but feel free to
> keep opening new dialogs until your fingers bleed and/or
> eyes pop out.
>
> Okay, now tell us, in what manner can an "interface bug"
> like this be "beneficial"?

You call it a bug because you can't think of any way it could be
beneficial. That's the wrong way of looking at it. Something isn't a
bug because you find it annoying; it's a bug because it fails to
implement the programmer's intentions and/or the docs/specification.

Opening multiple dialogs is *often* useful. The extras don't conflict,
and you can open multiple files, so why should it be prevented?

>  STEPS TO REPRODUCE BUG 2: "Hide and go seek!"
>
> 1. Open the IDLE application
> 2. Maximize the window that appears
> 3. Go to the "File Menu" and choose the "Open" command
> 4. Without disturbing the dialog, minimize the main window
> 5. Using the taskbar icon, maximize the window
>
> Where is the dialog? How will you retrieve it *WITHOUT*
> reducing the size of the window? And even if you are smart
> enough to "intuit" what happened to the dialog, and how to
> retrieve it, how will a noobie "intuit" such a disappearing
> act? And how in the hell can this be beneficial?

I'm not sure what platform you're on, and this depends a lot on your
window manager. I'm guessing you may be on Windows, as Linux people
are more likely to be aware of what DE/WM they use, so I tried it out
on Windows. The file dialog appears in the alt-tab list, which seems
perfectly sane and sensible, and in fact alt-tab is the most logical
way to move between maximized windows anyway.

This is not an Idle bug at all. It's a window manager issue.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74916

On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:

> You call it a bug because you can't think of any way it could be
> beneficial. That's the wrong way of looking at it. Something isn't a
> bug because you find it annoying; it's a bug because it fails to
> implement the programmer's intentions and/or the docs/specification.

I was always taught that it's a "bug" is when a program doesn't do
what a reasonable user expects -- that it's got nothing to do with the
programmer's intent.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm RELIGIOUS!!
                                  at               I love a man with
                              gmail.com            a HAIRPIECE!!  Equip me
                                                   with MISSILES!!

[toc] | [prev] | [next] | [standalone]

#74917

No intent to pollute this thread.

But really interested in the invalid@invalid.invalid mailing address.
And,,, obviously, I cannot send to invalid@invalid.invalid, so

How does you(he) make this?

2014-07-21 22:27 GMT+08:00 Grant Edwards <invalid@invalid.invalid>:

> I was always taught that it's a "bug" is when a program doesn't do
> what a reasonable user expects -- that it's got nothing to do with the
> programmer's intent.
>
> --
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 

吾輩は猫である。ホームーページはhttp://introo.me。

[toc] | [prev] | [next] | [standalone]

#74929

On 2014-07-21, Shiyao Ma <i@introo.me> wrote:
> No intent to pollute this thread.
>
> But really interested in the invalid@invalid.invalid mailing address.
> And,,, obviously, I cannot send to invalid@invalid.invalid, so

FWIW, my real e-mail address is at the bottom of every post.

> How does you(he) make this?

I execute the following slang code via my slrn startup file:

      username = "grant.b.edwards";
      host = "gmail.com";

-- 
Grant Edwards               grant.b.edwards        Yow! Does someone from
                                  at               PEORIA have a SHORTER
                              gmail.com            ATTENTION span than me?

[toc] | [prev] | [next] | [standalone]

#74934

On 2014-07-21, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2014-07-21, Shiyao Ma <i@introo.me> wrote:
>> No intent to pollute this thread.
>>
>> But really interested in the invalid@invalid.invalid mailing address.
>> And,,, obviously, I cannot send to invalid@invalid.invalid, so
>
> FWIW, my real e-mail address is at the bottom of every post.
>
>> How does you(he) make this?
>
> I execute the following slang code via my slrn startup file:
>
>       username = "grant.b.edwards";
>       host = "gmail.com";

Oops, I cut and pasted the wrong code:

  variable username = "invalid";
  variable host="invalid.invalid";
  set_string_variable("hostname", host);
  set_string_variable("username", username);

-- 
Grant Edwards               grant.b.edwards        Yow! Was my SOY LOAF left
                                  at               out in th'RAIN?  It tastes
                              gmail.com            REAL GOOD!!

[toc] | [prev] | [next] | [standalone]

#74918

On Tue, Jul 22, 2014 at 12:27 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:
>
>> You call it a bug because you can't think of any way it could be
>> beneficial. That's the wrong way of looking at it. Something isn't a
>> bug because you find it annoying; it's a bug because it fails to
>> implement the programmer's intentions and/or the docs/specification.
>
> I was always taught that it's a "bug" is when a program doesn't do
> what a reasonable user expects -- that it's got nothing to do with the
> programmer's intent.

There are many definitions of the word, and sometimes they disagree.
(That's why it's common to have an "issue tracker" rather than a "bug
tracker"; often the "is this a bug report or a feature request"
question doesn't even matter. In theory, version x.y.? releases should
have bug fixes but not feature additions, but sometimes some bug fix
might potentially break code, so it's deferred till the next x.?
release. Or a feature addition is allowed to be backported, because
it's Idle, not the core language.)

But even using that definition, I would not say that one single person
saying "this can't possibly be useful" is enough to define something
as a bug. Take, for instance, the behaviour of Windows's cmd.exe
editing keys: enter three commands, then up-arrow three times and hit
enter, then press down, enter, down, enter. You'll repeat the three
commands. In other interfaces (eg GNU readline), you'd do the same job
by pressing up, up, up, enter each time. Personally, I find the
cmd.exe behaviour extremely surprising, especially when I've been
working with some very similar commands (imagine: ./configure
some_bunch_of_args; make; some_command_to_test; rm -rf *; git checkout
HEAD - then repeat with a different set of configure arguments), and I
end up "stuck half way up command history", wondering why I'm not
seeing what I wanted. Can be extremely awkward. But even so, I don't
call this a bug. It's entirely possible that it is one - some internal
state that isn't being reset correctly - as I don't have docs or the
programmer's intention to compare against. However, I can't honestly
call it a bug based on just my own use-cases. I personally find it
useless and unhelpful, but that doesn't make it a bug any more than a
colourblind person would find a colour-based UI phenomenon a bug.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74919

On Tue, Jul 22, 2014 at 12:40 AM, Shiyao Ma <i@introo.me> wrote:
> No intent to pollute this thread.
>
> But really interested in the invalid@invalid.invalid mailing address.
> And,,, obviously, I cannot send to invalid@invalid.invalid, so
>
> How does you(he) make this?

When you send email, you have to have a valid envelope-from address,
which can be found in the headers. But the From: address doesn't
technically have to be valid. And if the email you received actually
came from the news<->mail gateway, then it's even less significant;
the address used is simply whatever Grant chose to key into his
newsreader, which in this case is a marker saying "Please don't email
me, just follow-up to the group" :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#74932

On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Jul 22, 2014 at 12:40 AM, Shiyao Ma <i@introo.me> wrote:
>> No intent to pollute this thread.
>>
>> But really interested in the invalid@invalid.invalid mailing address.
>> And,,, obviously, I cannot send to invalid@invalid.invalid, so
>>
>> How does you(he) make this?
>
> When you send email, you have to have a valid envelope-from address,
> which can be found in the headers. But the From: address doesn't
> technically have to be valid.

Note that a lot of mail servers and/or spam filters will think it's
spam if it isn't.

> And if the email you received actually came from the news<->mail
> gateway,

It did.

> then it's even less significant; the address used is simply whatever
> Grant chose to key into his newsreader, which in this case is a
> marker saying "Please don't email me, just follow-up to the group" :)

If people really do want to e-mail me, that's fine.  What I'm trying
to avoid is people who e-mail my without knowing they're doing so
because that's the default setting for whatever broken-by-design email
client, web-UI, or newsreading they happen to be using.  If people
conciously want to e-mail me, all they can by using the address in my
sig.

-- 
Grant Edwards               grant.b.edwards        Yow! Wait ... is this a FUN
                                  at               THING or the END of LIFE in
                              gmail.com            Petticoat Junction??

[toc] | [prev] | [next] | [standalone]

#74937

On Tue, Jul 22, 2014 at 2:55 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> When you send email, you have to have a valid envelope-from address,
>> which can be found in the headers. But the From: address doesn't
>> technically have to be valid.
>
> Note that a lot of mail servers and/or spam filters will think it's
> spam if it isn't.

Yes, which is why I said "technically". Most often, a difference
between envelope-from and From: header is because of a resending, like
when Mailman sends mail on behalf of someone else; the From is still a
valid address, but it's not the same one as the envelope-from (which
will be the list-bounces address).

That said, though, I've often telnetted to a mail server and done
something like this:

"""
helo
mail from:<some real address>
rcpt to:<another real address>
data
From: me
To: me
Subject: Test

Test!
.
quit
"""

Generally that sort of thing gets through. Sometimes it lands in a
spam box, but more often it doesn't. I don't remember it ever getting
rejected, other than for issues of relaying (which usually come from
typoing the recipient domain).

ChrisA

[toc] | [prev] | [next] | [standalone]

#74920

On 2014-07-21, Shiyao Ma <i@introo.me> wrote:
> But really interested in the invalid@invalid.invalid mailing address.
> And,,, obviously, I cannot send to invalid@invalid.invalid, so
>
> How does you(he) make this?

Some usenet clients, such as slrn which it looks like Grant is using
according to the message header, support using different addresses for
'From:' and 'Reply-To:', and the comments in the default .slrnrc config
file recommend using some form of 'invalid' in your 'From:' address to
cut down on spam.  Looks like Grant took that quite literally ;)

Not sure if it really matters... probably can't hurt...

Monte

[toc] | [prev] | [next] | [standalone]

#74921

On 21/07/2014 15:27, Grant Edwards wrote:
> On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:
>
>> You call it a bug because you can't think of any way it could be
>> beneficial. That's the wrong way of looking at it. Something isn't a
>> bug because you find it annoying; it's a bug because it fails to
>> implement the programmer's intentions and/or the docs/specification.
>
> I was always taught that it's a "bug" is when a program doesn't do
> what a reasonable user expects -- that it's got nothing to do with the
> programmer's intent.
>

As in my entire career I've never come across a "reasonable user" then 
by that definition there are no bugs.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#74933

On 2014-07-21, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 21/07/2014 15:27, Grant Edwards wrote:
>> On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:
>>
>>> You call it a bug because you can't think of any way it could be
>>> beneficial. That's the wrong way of looking at it. Something isn't a
>>> bug because you find it annoying; it's a bug because it fails to
>>> implement the programmer's intentions and/or the docs/specification.
>>
>> I was always taught that it's a "bug" is when a program doesn't do
>> what a reasonable user expects -- that it's got nothing to do with the
>> programmer's intent.
>
> As in my entire career I've never come across a "reasonable user" then 
> by that definition there are no bugs.

Well done!

-- 
Grant Edwards               grant.b.edwards        Yow! Hello.  Just walk
                                  at               along and try NOT to think
                              gmail.com            about your INTESTINES being
                                                   almost FORTY YARDS LONG!!

[toc] | [prev] | [next] | [standalone]

#74922

On Tue, Jul 22, 2014 at 1:19 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 21/07/2014 15:27, Grant Edwards wrote:
>>
>> On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:
>>
>>> You call it a bug because you can't think of any way it could be
>>> beneficial. That's the wrong way of looking at it. Something isn't a
>>> bug because you find it annoying; it's a bug because it fails to
>>> implement the programmer's intentions and/or the docs/specification.
>>
>>
>> I was always taught that it's a "bug" is when a program doesn't do
>> what a reasonable user expects -- that it's got nothing to do with the
>> programmer's intent.
>>
>
> As in my entire career I've never come across a "reasonable user" then by
> that definition there are no bugs.

Absence of evidence is not the same as evidence of absence. It may be
that there is a single platinum "reasonable user", kept at the
International Bureau of Bugs, that we may all look on it and know what
the SI Standard User is.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web