subject:"Re\: Python 3 is killing Python"


Chris Angelico wrote:

The easier target for the mouse argument is valuable ONLY
when you use the mouse to access the menu bar. If you use the keyboard
(and take advantage of mnemonic letters), it's much more useful to
have the menu bar attached to its window.


Seems to me that if you use the keyboard for everything,
it doesn't matter where the menu bar is. Unless you're
talking about the way you can use the keyboard to make
menus drop down in Windows... but that's not the way
Mac menu shortcuts work. The menu doesn't visually drop
down when you invoke a Mac menu command with the keyboard.


In the rare case of an app
that runs without any windows, incidentally, how do you tell the
system that you want that app's menu bar instead of (say) Finder,
which comes up when you click on the desktop?


In classic MacOS, there was a menu of running applications
in the top right corner. In MacOSX, you click on the app's
icon in the dock.

Also, while completely windowless applications might be
rare, it's not rare for an app to have some commands that
pertain to the app itself, and not to any particular
window, e.g. New. It's more logical for those to appear
in a user interface element that's not tied to a window.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]


Olaf Hering wrote:

How does a package differ? Its a package here and there.
Just use the correct tools to inspect a package, like
'rpm -qliv $package' to see what a package is all about.


Splitting the package up creates a problem, which you
then need to invent a special tool to solve. Seems to
me it's simpler not to create the problem in the first
place.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-02 Thread Chris Angelico

On Sat, Aug 2, 2014 at 9:33 PM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
 Chris Angelico wrote:

 The easier target for the mouse argument is valuable ONLY
 when you use the mouse to access the menu bar. If you use the keyboard
 (and take advantage of mnemonic letters), it's much more useful to
 have the menu bar attached to its window.


 Seems to me that if you use the keyboard for everything,
 it doesn't matter where the menu bar is. Unless you're
 talking about the way you can use the keyboard to make
 menus drop down in Windows... but that's not the way
 Mac menu shortcuts work. The menu doesn't visually drop
 down when you invoke a Mac menu command with the keyboard.

There are two forms of shortcut key. One is a direct-action keystroke
that immediately does the same thing that you can do using the menus
(say, Ctrl-O is the same as File... Open). With those, the menu is
completely unnecessary, except as a list of available keystrokes; it
could just as easily be a help screen that says Press Ctrl-O to open
a file, so the menu's actual location is quite arbitrary. Downside:
There's only so many keystrokes available, and not all of them have
memorable meanings. It's usually best to keep this to the few most
common functions (opening a file, yes, but not reinterpret this file
as ISO-8859-3, unless you make that configurable per user).

But the other form, usually described as menu mnemonics, is where you
press Alt-F to bring up the _File menu, and then O to activate _Open.
(In OS/2, those would be ~File and ~Open; in GTK, the mnemonic is
preceded by an underscore. Windows 3.1 used an ampersand, and I
believe Win32 does the same thing. It's a little awkward when you have
an invoicing screen and you put something like PO Shipping as your
customer name, and suddenly Alt-O takes you someplace different. The
tilde has the advantage that it doesn't often come up accidentally;
the underscore makes sense because the mnemonic is underlined; I have
no idea why an ampersand should be used. But I digress.) When you work
this way, you aren't grabbing the mouse, so the advantage of not
needing to aim so carefully doesn't exist; but if the menu comes up
right near where your eyes are already focused, you need to move
_them_ less distance - and that means you can focus on the menu more
quickly, plus it emphasizes that the visual change (opening the menu)
occurred in your current program, not in something else.

In Xfce, I can press Alt-F1 to open up the main Applications Menu.
That's at the top of the screen (in fact, top left corner), so it gets
the throw the mouse benefit; I think I use the mouse with that a lot
more often than I use the mouse with a program's own menu, because
there's more likely to be something unusual in there. If I install a
new piece of software, I have to figure out where it's landed in the
menu; but Gypsum's four menus aren't changing unexpectedly, so I'm
happy using Alt-O, V to open up Advanced Options.

 In the rare case of an app
 that runs without any windows, incidentally, how do you tell the
 system that you want that app's menu bar instead of (say) Finder,
 which comes up when you click on the desktop?

 In classic MacOS, there was a menu of running applications
 in the top right corner. In MacOSX, you click on the app's
 icon in the dock.

Okay. So you need to first click on something in the dock - that's the
thing down the bottom of the screen, right? - and then go all the way
up to the top of the screen to use its menu bar. I think I'd much
rather have a popup menu - right-click the program's dock icon and get
the menu right there where the mouse already is. Oh wait, that
requires people to understand more than a single mouse button, so it's
contrary to Mac philosophy :)

 Also, while completely windowless applications might be
 rare, it's not rare for an app to have some commands that
 pertain to the app itself, and not to any particular
 window, e.g. New. It's more logical for those to appear
 in a user interface element that's not tied to a window.

Sure, but those elements are usually rare enough that they can be
stuck on the window anyway. Audacity has a New that opens up a new
window, and it's slightly surprising the first couple of times, but
after that you get used to it. It's not a big enough issue to warrant
a change of UI. It is an issue, yes, but I wouldn't warp anything
around it any more than I'd warp my UI around the possibility of a
user having no screen or keyboard and is using the mouse blind. Sure
it happens (I've done it, and I know what I could code to make it
easier!), but not often.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-02 Thread MRAB


On 2014-08-02 01:00, Gregory Ewing wrote:

MRAB wrote:

[snip]

And don't mention the menu bar across the top, separated from the
window to which it belonged.


That seems to be a matter of taste. There are some advantages to the
menu-bar-at-top model. It's an easier target to hit, because you can
just flick the mouse up to the top. It only takes up space once,
instead of once per window. It makes it possible for an app to be
running without having any windows, and still be able to interact
with it.


RISC OS didn't have a menu bar at the top of each window either; its
menus were all pop-up. You didn't have to keep flicking the mouse at
all!
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-02 Thread Roy Smith

In article c42o1nfbrq...@mid.individual.net,
 Gregory Ewing greg.ew...@canterbury.ac.nz wrote:

  And don't mention the menu bar across the top, separated from the
  window to which it belonged.
 
 That seems to be a matter of taste. There are some
 advantages to the menu-bar-at-top model. It's an easier
 target to hit, because you can just flick the mouse up
 to the top. It only takes up space once, instead of
 once per window. It makes it possible for an app to
 be running without having any windows, and still be
 able to interact with it.

In the old days, we had really small screens (the original Mac had a 9 
inch screen with 512 x 342 resolution).  Most application windows filled 
most of the screen, so there really wasn't much difference between 
per-desktop and per-window menu bars.

These days, I'm running multiple 24 inch monitors.  The single menu bar 
paradigm starts to break down in an environment like that.  I find I 
tend to put the few windows I'm actively using near the top of my 
primary screen (the one with the menu bar), and use the second screen to 
hold windows I'm not interacting with much.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]


MRAB wrote:

RISC OS didn't have a menu bar at the top of each window either; its
menus were all pop-up. You didn't have to keep flicking the mouse at
all!


The main reason for having a menu bar is discoverability. The
idea is that you can browse through the menus and get a feel
for what commands are potentially available to you. That's not
so easy to do when everything is hidden in contextual menus.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]


Chris Angelico wrote:

It's a little awkward when you have
an invoicing screen and you put something like PO Shipping as your
customer name, and suddenly Alt-O takes you someplace different.


An app that did that would be seriously broken, wouldn't it?
The  should only be interpreted that way in menu items, etc.,
not in user data.


but if the menu comes up
right near where your eyes are already focused, you need to move
_them_ less distance


But putting the menu bar at the top of the window doesn't
guarantee that it will be near where your eyes are. If
you have a window taking up most of the screen and you're
editing something near the bottom, a menu bar at the top
of the window is nearly as far away as one at the top of
the screen.

It would make more sense to pop the menu up near the text
cursor. There's no law that says a menu summoned by
keystroke has to appear in the same place as one summoned
by mouse.

In any case, when you use a shortcut sequence, do you
really *look* at the menu that comes up, or do you just
memorise the appropriate alt-sequence? If you use it
frequently, I suspect the latter. If you don't use it
very often, having to look away doesn't matter so much.


Okay. So you need to first click on something in the dock - that's the
thing down the bottom of the screen, right? - and then go all the way
up to the top of the screen to use its menu bar.


Because of the throw the mouse effect, going *all* the
way to the top takes a tiny fraction of a second and is
almost effortless. Going any lesser distance takes
*much* longer.


I think I'd much
rather have a popup menu - right-click the program's dock icon and get
the menu right there where the mouse already is.


Dock icons do have a contextual menu, but it's just a
menu of windows. Fitting all of the app's menus in there
would require hierarchical menus, which are an abomination
you don't want to get me started on. :-)


Oh wait, that
requires people to understand more than a single mouse button, so it's
contrary to Mac philosophy :)


The Mac philosophy on that seems to be widely misunderstood.
Having only one button on my mouse doesn't mean there's
only one thing I can do with it. I can shift-click, option-
click, command-click, and nowadays control-click, plus any
combination of those. That's enough for anyone to keep in
their head, I would have thought.

There's also one concrete advantage to using modifiers
instead of extra mouse buttons: you can provide feedback
by changing the cursor when a modifier is held down.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]


Roy Smith wrote:
These days, I'm running multiple 24 inch monitors.  The single menu bar 
paradigm starts to break down in an environment like that.


Yes, that's an issue. However, even on a large screen, most of
my windows are at least half a screen high, putting their tops
a considerable distance from where I'm working. And the targeting
effect means that a target at the top of the screen is still
easier to hit than one half way up.

Multiple screens are a problem. Probably what should happen is
for the menu bar to move to the screen holding the currently
active window, instead of being tied to one primary screen.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-02 Thread Chris Angelico

On Sun, Aug 3, 2014 at 10:01 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
 Chris Angelico wrote:

 It's a little awkward when you have
 an invoicing screen and you put something like PO Shipping as your
 customer name, and suddenly Alt-O takes you someplace different.


 An app that did that would be seriously broken, wouldn't it?
 The  should only be interpreted that way in menu items, etc.,
 not in user data.

Mnemonics can also be used on text labels, and then they apply to the
adjacent field - for instance, you could have _Name followed by an
entry field for the Name, and hitting Alt-N will take you to that
field. The app I'm talking about used a label to show the customer's
name, and we had exactly that issue (although more often with couples'
names - for instance, if we had an order from John and Mary Smith, but
didn't know their full names, we'd identify them as JM Smith, and
voila, Alt-M would take us to... whatever field came after the display
of the name (which was the address).

To be quite honest, that particular program was a lot more broken than
that. But still, it did drive home the value of using ~ instead of 
for that job. And of course, _ makes enough sense that we can accept
its potential for collisions. (Plus it's usually possible to disable
underscore interpretation. Or, more properly, you have to explicitly
enable their interpretation; in GTK, I have to call
set_use_underline(1) before it'll create a mnemonic.)

 but if the menu comes up
 right near where your eyes are already focused, you need to move
 _them_ less distance


 But putting the menu bar at the top of the window doesn't
 guarantee that it will be near where your eyes are. If
 you have a window taking up most of the screen and you're
 editing something near the bottom, a menu bar at the top
 of the window is nearly as far away as one at the top of
 the screen.

Putting it at the top of the window cannot possibly make it further
away than putting it at the top of the screen. It's potentially going
to be a lot closer, but at its worst, it'll be just as bad (modulo the
title bar's height).

 It would make more sense to pop the menu up near the text
 cursor. There's no law that says a menu summoned by
 keystroke has to appear in the same place as one summoned
 by mouse.

Sure. And I know of plenty of applications where that's possible. The
standard used to be Shift-F10 to bring up a context menu, identical to
right-clicking the mouse except that the menu appears at the object
you're working on rather than at the mouse's location. These days, you
often get something like that on the Menu key (aka the other Windows
key, on some keyboards); same result. But that's a context menu, not
the pull-down menu; although it's common to have the same menu items
on them.

 In any case, when you use a shortcut sequence, do you
 really *look* at the menu that comes up, or do you just
 memorise the appropriate alt-sequence? If you use it
 frequently, I suspect the latter. If you don't use it
 very often, having to look away doesn't matter so much.

If I'm using Alt-F, O as a command keystroke, then sure, it doesn't
make any difference where the menu is. But often I'll pull down a
menu, then look at it to figure out what I want to hit. Once my eye
has found it, I'll press its underlined letter, so I still don't use
the mouse; but I do need it to have a mnemonic, and I need the entire
menu to be near my eye.

 Okay. So you need to first click on something in the dock - that's the
 thing down the bottom of the screen, right? - and then go all the way
 up to the top of the screen to use its menu bar.

 Because of the throw the mouse effect, going *all* the
 way to the top takes a tiny fraction of a second and is
 almost effortless. Going any lesser distance takes
 *much* longer.

Right, but it still takes time. Also, if your mouse is set fast enough
to go all the way from the bottom to the top of the screen in less
than 0.1s, then either your screen is fairly small (may have been true
in the past, but is getting pretty rare now), or you seriously
penalize any going-less-distance operations. In fact, it becomes
self-perpetuating: if you set the mouse fast, it becomes really
important to use the edges and avoid the middle, and if applications
always use the edges and never the middle, it's really important to
set your mouse faster. Conversely, slower mouse settings mean it's
easier to be precise with interior movements, while reducing the
advantage of the borders.

But no matter how fast you set the mouse, it still takes a nonzero
time to move it to a specific position. The absolute easiest place to
reach is... where you already are. Put the menu there! That's what
popup menus are for.

 I think I'd much
 rather have a popup menu - right-click the program's dock icon and get
 the menu right there where the mouse already is.

 Dock icons do have a contextual menu, but it's just a
 menu of windows. Fitting all of the app's menus in there

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-01 Thread Wolfgang Keller

 Windows and OS X users, sadly, miss out on the power of an integrated 
 package manager.

Thankfully, all actually user-friendly operating systems (MacOS,
TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the
bottomless cesspit of package management and/or installers.

Because on such operating systems, each and every application is an
entirely self-contained package that doesn't need any packages or
installers to use it.
 
Sincerely,

Wolfgang
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

On Fri, Aug 1, 2014 at 9:10 PM, Wolfgang Keller felip...@gmx.net wrote:
 Thankfully, all actually user-friendly operating systems (MacOS,
 TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the
 bottomless cesspit of package management and/or installers.

 Because on such operating systems, each and every application is an
 entirely self-contained package that doesn't need any packages or
 installers to use it.

You mean everyone has to reinvent the proverbial wheel AND worry about
dependency collisions? Yeah, that's a heavenly thought.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-01 Thread Nicholas Cole

On Fri, Aug 1, 2014 at 12:22 PM, Chris Angelico ros...@gmail.com wrote:
 On Fri, Aug 1, 2014 at 9:10 PM, Wolfgang Keller felip...@gmx.net wrote:
 Thankfully, all actually user-friendly operating systems (MacOS,
 TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the
 bottomless cesspit of package management and/or installers.

 Because on such operating systems, each and every application is an
 entirely self-contained package that doesn't need any packages or
 installers to use it.

 You mean everyone has to reinvent the proverbial wheel AND worry about
 dependency collisions? Yeah, that's a heavenly thought.

Actually, that's not right.  RiscOS had and OS X has (I'm sure the
others do as well) a concept that is similar to a shared library.  But
the joy of an application bundle is that installing an application
does not scatter its own files all over the file-system, putting
configuration files here, binary resources there, library files
somewhere else, executable files somewhere else again.  The result on
one of these other systems is that uninstalling an application is a
simple matter of deleting the relevant bundle, which contains all of
the resources necessary for that application.  All that remains are
whatever files exist within user directories.

I've worked with both.  Quite honestly, I really wish that other
operating systems had gone down this route. MS didn't possibly to make
it harder to steal software, and Unix...well, *nix has the concept of
the distribution that will manage all of this for you.  We all know
the problems that this causes.

N.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

On Sat, Aug 2, 2014 at 12:28 AM, Nicholas Cole nicholas.c...@gmail.com wrote:
 Actually, that's not right.  RiscOS had and OS X has (I'm sure the
 others do as well) a concept that is similar to a shared library.  But
 the joy of an application bundle is that installing an application
 does not scatter its own files all over the file-system, putting
 configuration files here, binary resources there, library files
 somewhere else, executable files somewhere else again.

Shared libraries are a code execution model. The question is, how do
you locate them? Let's suppose I write a program that requires the
Nettle cryptography library. I can't depend on you already having that
on your system; you might, but I can't depend on it. What do I do? Do
I include it in my application bundle, or do I have some small record
that says and by the way, I need libnettle? Including it in the
application bundle means there'll be duplicates everywhere, possibly
of slightly different versions. Not including it means there needs to
be some kind of system for resolving dependencies, which is exactly
what apt-get, yum, pacman, and so on are for.

The installer has basically three choices.
1) Install libnettle inside the application directory
2) Install libnettle to some system library directory
3) Don't install libnettle, and demand that someone else (perhaps the
user, or the system package manager) install it.

Option 1 results in duplications. (Unless one application is allowed
to access a library in another application's directory, which is a
HORRIBLE mess.) Option 2 is exactly what you're complaining about,
scattering files all over the FS. And option 3 is what package
managers are for. What are you advocating?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-01 Thread Dietmar Schwertberger


Am 01.08.2014 13:10, schrieb Wolfgang Keller:

Because on such operating systems, each and every application is an
entirely self-contained package that doesn't need any packages or
installers to use it.

For people who have never used such a system it's probably difficult to see
the  advantages.

Besides the easy installation, backup and replication of software the 
RISC OS

way also had the advantage that you were able to organize your
applications in folders just like other folders and files.
There was no need for separate File and Program managers.
MS never got this right. Instead, they tried to fix things later with the
start menu and finally the box to type the software name to start it ...

One effect was that under DOS/Windows people usually saved their
documents in folders per application whereas under RISC OS they
were usually grouped by content/project.


When it came to usability, RISC OS had many advantages over the
other systems, e.g.
 - real drag'n'drop for loading *and* saving of files/selections
 - drag'n'drop also for transfer between applications
 - a standard vector graphics format that all applications supported
   (and for which an application was provided by default with the OS)
 - good font display (still better than e.g. MS Windows today)
 - three mouse buttons for select/menu/adjust
 - no menu bars
 - the icon bar for running applications, drives, shares and other 
resources

 - consistent, orthogonal  logical user interfaces instead of assistants
   and wizards for each and every task
 - complete programmers reference manual



Regards,

Dietmar

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-01 Thread Michael Torrie

On 08/01/2014 08:39 AM, Chris Angelico wrote:
 The installer has basically three choices.
 1) Install libnettle inside the application directory
 2) Install libnettle to some system library directory
 3) Don't install libnettle, and demand that someone else (perhaps the
 user, or the system package manager) install it.
 
 Option 1 results in duplications. (Unless one application is allowed
 to access a library in another application's directory, which is a
 HORRIBLE mess.) Option 2 is exactly what you're complaining about,
 scattering files all over the FS. And option 3 is what package
 managers are for. What are you advocating?

Option 1 also is a huge security hole.  A prime example of this was the
so-called heartbleed bug.  In such a model, each app that distributes
openssl in the app bundle has to be updated or it is at risk.  This
turns out to be a huge vulnerability.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-01 Thread MRAB


On 2014-08-01 18:16, Dietmar Schwertberger wrote:

Am 01.08.2014 13:10, schrieb Wolfgang Keller:

Because on such operating systems, each and every application is an
entirely self-contained package that doesn't need any packages or
installers to use it.

For people who have never used such a system it's probably difficult to see
the  advantages.

Besides the easy installation, backup and replication of software the
RISC OS
way also had the advantage that you were able to organize your
applications in folders just like other folders and files.
There was no need for separate File and Program managers.
MS never got this right. Instead, they tried to fix things later with the
start menu and finally the box to type the software name to start it ...

One effect was that under DOS/Windows people usually saved their
documents in folders per application whereas under RISC OS they
were usually grouped by content/project.


When it came to usability, RISC OS had many advantages over the
other systems, e.g.
   - real drag'n'drop for loading *and* saving of files/selections
   - drag'n'drop also for transfer between applications
   - a standard vector graphics format that all applications supported
 (and for which an application was provided by default with the OS)
   - good font display (still better than e.g. MS Windows today)
   - three mouse buttons for select/menu/adjust
   - no menu bars
   - the icon bar for running applications, drives, shares and other
resources
   - consistent, orthogonal  logical user interfaces instead of assistants
 and wizards for each and every task
   - complete programmers reference manual


I'd heard people say how user-friendly Apple Macs were, but when I got
to use one I was somewhat disappointed.

When opening files, it used old-fashioned dialog boxes like RISC OS's
precursor from several years earlier. In RISC OS, if I had a directory
window open, I could save to it with a simple drag-and-drop, but in
MacOS, even if I had a directory window open, I had to navigate to the
directory in the Save dialog. (OK, not quite true, because of a
3rd-party extension called Click There It Is.)

And don't mention the menu bar across the top, separated from the
window to which it belonged.

Or the way that clicking on any window of an application or the Finder
brought not only it but also all of the its siblings to the front. On
RISC OS, windows came to the front only when *I* wanted them to.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-01 Thread Gregory Ewing


Chris Angelico wrote:

The installer has basically three choices.
1) Install libnettle inside the application directory
2) Install libnettle to some system library directory
3) Don't install libnettle, and demand that someone else (perhaps the
user, or the system package manager) install it.

Option 2 is exactly what you're complaining about,
scattering files all over the FS.


Not really. On MacOSX, if you installed a shared library
called libnettle, *all* the files relating to it
would be kept in one directory called Nettle.framework
(either in /Library/Frameworks or ~/Library/Frameworks
depending on whether it's system-wide or for a single user).

MacOSX doesn't currently have an automatic dependency
manager, but if it did, things would still be a lot neater
and tidier than they are in Linux or Windows, where what
is conceptually a single object (a package) gets split up
and its parts scattered around several obscure locations.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

On Sat, Aug 2, 2014 at 6:22 AM, Michael Torrie torr...@gmail.com wrote:
 On 08/01/2014 08:39 AM, Chris Angelico wrote:
 The installer has basically three choices.
 1) Install libnettle inside the application directory
 2) Install libnettle to some system library directory
 3) Don't install libnettle, and demand that someone else (perhaps the
 user, or the system package manager) install it.

 Option 1 results in duplications. (Unless one application is allowed
 to access a library in another application's directory, which is a
 HORRIBLE mess.) Option 2 is exactly what you're complaining about,
 scattering files all over the FS. And option 3 is what package
 managers are for. What are you advocating?

 Option 1 also is a huge security hole.  A prime example of this was the
 so-called heartbleed bug.  In such a model, each app that distributes
 openssl in the app bundle has to be updated or it is at risk.  This
 turns out to be a huge vulnerability.

More generally, that's exactly what Steven said about needing every
package to update before you can confidently say it's updated. But
that's also the greatest feature of the first option: you can't break
this application by upgrading that library, because only upgrading the
application (which hopefully will have been tested by the author) will
upgrade the library it uses.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

On Sat, Aug 2, 2014 at 9:14 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
 Chris Angelico wrote:

 The installer has basically three choices.
 1) Install libnettle inside the application directory
 2) Install libnettle to some system library directory
 3) Don't install libnettle, and demand that someone else (perhaps the
 user, or the system package manager) install it.

 Option 2 is exactly what you're complaining about,
 scattering files all over the FS.


 Not really. On MacOSX, if you installed a shared library
 called libnettle, *all* the files relating to it
 would be kept in one directory called Nettle.framework
 (either in /Library/Frameworks or ~/Library/Frameworks
 depending on whether it's system-wide or for a single user).

 MacOSX doesn't currently have an automatic dependency
 manager, but if it did, things would still be a lot neater
 and tidier than they are in Linux or Windows, where what
 is conceptually a single object (a package) gets split up
 and its parts scattered around several obscure locations.

That's fine if I explicitly install libnettle - that's the third
option. What happens if I install Foo's Cool Chat App, and FCCA uses
libnettle to encrypt conversations? Is FCCA allowed to install
libnettle into /Library/Frameworks? If so, its files will be split
between there and its own app directory.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-08-01 Thread Gregory Ewing


MRAB wrote:

I'd heard people say how user-friendly Apple Macs were, but when I got
to use one I was somewhat disappointed.


Well, they were compared to MS-DOS and the like, which was
all that was within reach of the general public when the
first Mac appeared. RISCOS came along somewhat later.


in MacOS, even if I had a directory window open, I had to navigate to the
directory in the Save dialog.


Yes, that was annoying. It wasn't a problem to begin with,
because the original Mac was strictly single-tasking --
you couldn't *have* a directory window and an application
open at the same time. And all your files were on floppies
in a flat file system -- folders only existed in the
Finder's imagination -- so the only real choice to be
made when saving a file was which disk do I put it on.

When multitasking, hard disks and hierarchical file
systems came along, there was an opportunity for a
rethink, but it never really happened.

Things are somewhat better in MacOSX, where you can drag
a folder from a Finder window onto a file dialog to take
you there, but there is still more of a distinction between
Finder windows and save dialogs than there needs to be.


And don't mention the menu bar across the top, separated from the
window to which it belonged.


That seems to be a matter of taste. There are some
advantages to the menu-bar-at-top model. It's an easier
target to hit, because you can just flick the mouse up
to the top. It only takes up space once, instead of
once per window. It makes it possible for an app to
be running without having any windows, and still be
able to interact with it.


Or the way that clicking on any window of an application or the Finder
brought not only it but also all of the its siblings to the front.


MacOSX has fixed that one, thankfully. Only the window
you click comes to the front, now.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

On Sat, Aug 2, 2014 at 10:00 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
 MRAB wrote:
 in MacOS, even if I had a directory window open, I had to navigate to the
 directory in the Save dialog.

 Yes, that was annoying. It wasn't a problem to begin with,
 because the original Mac was strictly single-tasking --
 you couldn't *have* a directory window and an application
 open at the same time. And all your files were on floppies
 in a flat file system -- folders only existed in the
 Finder's imagination -- so the only real choice to be
 made when saving a file was which disk do I put it on.

Okay, so it was like DOS 1.0...

 When multitasking, hard disks and hierarchical file
 systems came along, there was an opportunity for a
 rethink, but it never really happened.

... and it didn't get improved when it grew directories like DOS 2.0
did. It's like how the default DOS prompt is actually $N$G when $P$G
is a lot more useful, except that changing the default prompt is
pretty easy and applies globally (not to mention that you might well
want to enhance the prompt beyond just $P$G).

 And don't mention the menu bar across the top, separated from the
 window to which it belonged.

 That seems to be a matter of taste. There are some
 advantages to the menu-bar-at-top model. It's an easier
 target to hit, because you can just flick the mouse up
 to the top. It only takes up space once, instead of
 once per window. It makes it possible for an app to
 be running without having any windows, and still be
 able to interact with it.

Downside: It separates (graphically and logically) a window from its
menu bar. The easier target for the mouse argument is valuable ONLY
when you use the mouse to access the menu bar. If you use the keyboard
(and take advantage of mnemonic letters), it's much more useful to
have the menu bar attached to its window. In the rare case of an app
that runs without any windows, incidentally, how do you tell the
system that you want that app's menu bar instead of (say) Finder,
which comes up when you click on the desktop?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-30 Thread Rustom Mody

On Wednesday, July 16, 2014 4:16:45 PM UTC+5:30, Marko Rauhamaa wrote:

 In unix and linux, there never was a separate text mode for files. When
 you open a file, you open a file -- and stuff bytes in it. There is no
 commonly accepted text file encoding. UTF-8 comes close to being a
 standard, but I know somebody who sticks to an ISO-8859-1 locale.

Here's the Solaris docs:

| The C locale, also known as the POSIX locale, is the POSIX system
| default locale for all POSIX-compliant systems. The Oracle Solaris
| operating system is a POSIX system. The Single UNIX Specification,
| Version 3, defines the C locale. You can register at
| http://www.unix.org/version3/online.html to read and download the
| specification.
|
| http://docs.oracle.com/cd/E23824_01/html/E26033/glmbx.html#glmar

Layman version:

ASCII - also known as the Unix locale - is the default for all *nix
compliant systems.

expanded further at 
http://blog.languager.org/2014/04/unicode-and-unix-assumption.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-07-21 Thread CHIN Dihedral

On Sunday, July 20, 2014 9:53:02 AM UTC+8, C.D. Reimer wrote:
On 7/19/2014 6:23 PM, Steven D'Aprano wrote:

I haven't used Python on Windows much, but when I did use it, I found

the standard Python interactive interpreter running under cmd.exe to

be bare- bones but usable for testing short snippets. If I recall

correctly, it is missing any sort of command history or line editing

other than backspace, which I guess it would have been painful to use

for extensive interactive work, but when I started using Python on

Linux the interactive interpreter had no readline support either so it

was just like old times :-)

Windows PowerShell supports very basic Linux commands and has a command

history. I'm always typing ls for a directory listing when I'm on a

Windows machine. The regular command line would throw a DOS fit.

PowerShell lets me get away with it.

http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands

I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is

dying and MacBook shuts down after 15 minutes. I'm surprised at how well

I was able to set up a equivalent programming environment on Windows.

Chris Reimer

Well, Python could be used as a
scripting language for routine jobs
in various Oses.

But Python has been designed to be
a cross-platform high-level general
purpose programming language from
the birth.

One can be sure that the investing in most of the programming concepts and
skills in Python 2.XX is still valid in Python 3.XX.

Forget those non-investing imitators' flase spamming claims.

--
https://mail.python.org/mailman/listinfo/python-list

Python and IDEs [was Re: Python 3 is killing Python]

2014-07-19 Thread Steven D'Aprano

Earlier, I mentioned a considerable number of IDEs which are available 
for Python, including:

PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE, Geany, IEP,
Spyder, Boa Constructor, PyScripter, NetBeans, Emacs, KDevelop, and
BlackAdder.

https://wiki.python.org/moin/IntegratedDevelopmentEnvironments

There is also IDLE, which is part of the standard Python installation, as 
well as my preference: Unix/Linux as an IDE.

http://blog.sanctum.geek.nz/series/unix-as-ide/
http://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-unix-philosophy/


Some people ask:

How many of those quality IDEs ship with Python?

Most don't, of course, since they are third-party tools. Not that it 
matters: it's 2014, not 1974, and anyone in the developed world 
interested in computer programming has easy access to the information 
superhighway sometimes know as the Internet. (Many people in developing 
nations also have access to the Internet, and those who don't probably 
have bigger problems to worry about.) With the Internet, most of these 
IDEs are normally just a few clicks away.

People using Linux will generally find that they can install some of 
these IDEs using their package manager. For example, Red Hat Linux based 
systems such on Centos or Fedora can use the yum package manager, e.g.:

yum install geany geany-plugins

while Debian and Ubuntu based systems (such as Mint) can use apt-get or 
aptitude, e.g.:

aptitude install eric
apt-get install spe

Of course, most Linux distros include a GUI front-end to their package 
manager, but frankly if you're programming on Linux and you're unwilling 
to use the command line, you're making life harder for yourself than it 
need be.

Windows and OS X users, sadly, miss out on the power of an integrated 
package manager. OS X have a couple of third-party packaging systems, 
MacPorts and Homebrew:

http://www.macports.org/
http://brew.sh/

Unfortunately, software development on Windows is something of a ghetto, 
compared to the wide range of free tools available for Linux. Outside of 
a few oases like Microsoft's own commercial development tools, it's hard 
to do development on Windows. Hard, but not impossible, of course, and 
there are quite a few resources available for the Windows user willing to 
download installers from the Internet. For Python users, the IDEs from 
Wingware and Activestate are notable:

https://wingware.com/
http://komodoide.com/


Some people are under the impression that IDEs are mostly or even solely 
for the benefit of newbies or n00bs. That's a gross misunderstanding 
of the situation: the average newbie is likely to be happy writing code 
using Notepad, or whatever bare-bones text editor they're used to, and 
may not even know what an IDE is. It's those with some experience in 
programming (particularly in the Java and Visual Basic worlds) who are 
more likely to expect an IDE.

Another patronising view is that those who are new to programming are 
automatically too incompetent or ignorant to download or install an IDE 
without hand-holding. Even if that were the case, there is no shortage of 
hand-holding available on the Internet, with dozens or hundreds of 
forums, mailing lists, tutorial, videos and blogs offering to help. (It 
is undeniable that the quality of these is *extremely* variable, but 
that's another story.) This is the Internet generation, if software has a 
downloadable installer, or can be installed using a package manager, most 
people can deal with it, and those who can't have many opportunities to 
learn. (It's probably a bit much to expect the average newbie to install 
software from source, especially on Windows which doesn't come with much 
in the way of compilers and other development tools, but still, it has to 
be said that if you're hoping to become a programmer, installing software 
from source is one of the skills you should learn.)

So why does Python ship with IDLE? It's not because Python requires an 
IDE, or that newbies need one, or that there aren't alternatives. The 
biggest reason for Python shipping with an IDE is not that people are 
unable to install alternatives, but that a lot of people are *prohibited* 
from doing so. For those of us who have control over our computing 
environment, it's all too easy to forget that a lot of people (e.g. 
students using school computers, or people in corporate environments 
where the desktops are locked down to a standard operating environment) 
aren't able to install the IDE of their choice. It's relatively easy to 
get Python itself approved -- on many systems, Python comes pre-installed 
-- but trying to get approval to also install third-party software is 
difficult or impossible. It is for the sake of those people, people who 
prefer or require an IDE but don't have the choice to install third-party 
software, that Python ships with a minimal but usable IDE.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-19 Thread Rick Johnson

On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote:

 What ancient version, or oddball system are you using? For
 me, Win 7, both 2.7.8 and 3.4.1 CONTROL+LEFT_ARROW and
 the cursor is before the 'a' of [ abc]. The HOME key
 goes to the same place first, and they before  on the
 second press (and before 'a' on the third).

On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing
*properly* in front of the prompt, so apparently that bug was
fixed since last i checked, my apologies for being ignorant
of the situation, but you should understand that i had given
up after years of no improvements.

However, a *bare* HOME_KEY press is placing the insertion
cursor *BEHIND* the prompt of the current line. In a shell
environment, you never want to be *BEHIND* the command
prompt.

Now, in the case of CONTROL+HOME (which places the insertion
cursor at the very *first* position of the entire text
buffer) and CONTROL+END (which places the insertion cursor
at the very *last* position of the text buffer), we should
leave the default behaviors alone. I don't see any benefit
of changing them.

 IDLE shell shouldn't use TABs is a high-priority for me.
 The problem is agreeing on an *exact* specification for
 new behavior, that takes into account both the limitations
 and flexibility of tk. Maybe I should start a thread here
 or python-ideas, where people are willing to discuss
 details.

First, i need to admit that i was wrong when i said: eight
space indention, since the IDLE shell is using *tabs* for
indention, not spaces! However, a single tab is just as
annoying as 8 spaces

Now, even as much as i dislike tabs, i must admit there is a
benefit to using tabs over spaces, since tabs require only
*ONE* backspace key-press per pseudo 4 spaces as compared
to spaces which require a 1:1 ratio of key-presses. Of
course, even this problem can be abstracted away by
backspace automation code, which the IDLE editor window
already employs!

But my point is: We *MUST* remove this *excessive*
indentation width from the IDLE shell!

 I cannot connect [your complaint about IDLE hanging] to
 behavior I have seen.

IDLE will hang when editing Tkinter code. It seems to happen
most often in two cases:

  1. When running code that results in a Tkinter error.
  
  This can happen when mixing the grid and pack geometry
  managers within the same container widget, which is a
  Tkinter NO-NO, but it can also happen during other Tkinter
  errors!
  
  2. During quickly successive back-to-back run sessions
  of Tkinter GUI apps.
  
  It seems that sometimes, if you don't give IDLE enough
  time to release resources from the *LAST* run session, it
  will freeze and then throw a sub-process connection
  failure message, which, sometimes you can remedy by just
  trying again, but all to often you are forced to kill
  the entire IDLE (and related sub-) processes.
  
  THIS IS EXTREMELY ANNOYING!

However, *EVEN* in the instances where a problem is a direct
result of a Tkinter NO-NO (being witting or unwitting),
the user of IDLE should *NEVER* be forced to kill processes
because:

THERE MUST BE A BETTER SOLUTION!   

And this bug is making the whole Python community look like
a bunch of amateurs!

 I believe there is a proposal to be able to clear the
 shell window. We just need to add Clear and restart
 shell. There is also an idea to put help output in an
 output window. Undo-ing the result of hitting enter
 seems like a sensible extension of undoing the

 So sign the contributor agreement and volunteer to write
 and review patches.

I would be willing to help *IF* i received more thoughtful and
engaging replies like the type you always provide. Thank you
Terry for continuing to be a valuable and welcoming resource
for this community! If not for you and a handful of others,
i would have given up on this community a long time ago.

NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE!

I will visit the bug tracker again and see if i can provide
some assistance there. Although, the last time i visited, i
remember being annoyed by the tracker interface -- which i
feel is overly noisy and far too complicated. All we need is
a flat list of issues. Is there some method to export
something more readable? Or, some sort of documentation?

I must admit, my excitement to help is usually depleted by
the tracker interface before i even have a chance to offer
anything substantial.

If this bug tracker does not improve, i will be forced to
continue posting my grievances here.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

On Sun, Jul 20, 2014 at 2:29 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
 On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing
 *properly* in front of the prompt, so apparently that bug was
 fixed since last i checked, my apologies for being ignorant
 of the situation, but you should understand that i had given
 up after years of no improvements.

Standard rule: Before complaining about something, upgrade to the
latest version - at least the latest bugfix version of that branch.
That would be 2.7.8 and either 3.2.5 or 3.4.1. Complaining about a bug
in an old release is quite pointless if that bug has already been
fixed.

 However, a *bare* HOME_KEY press is placing the insertion
 cursor *BEHIND* the prompt of the current line. In a shell
 environment, you never want to be *BEHIND* the command
 prompt.

I don't know about the old versions, but in 3.4, it seems to be set so
the Home key toggles between the beginning of the code and the
beginning of the line. Seems a useful feature, although I can
understand if you'd want to disable it and set the Home key to only
ever go to the beginning of code. But that's a configuration question;
this does not appear to be a bug.

 But my point is: We *MUST* remove this *excessive*
 indentation width from the IDLE shell!

Why *must*? Is it really that big a problem?

 THERE MUST BE A BETTER SOLUTION!

 And this bug is making the whole Python community look like
 a bunch of amateurs!

Frankly, I doubt it. It's pretty obscure. Yes, all bugs should be
fixed where possible, but something of the nature you're describing
does NOT make Python look bad. (Side point: There's nothing bad about
being an amateur. I don't know why so many people think it's an
insulting term.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-19 Thread Ian Kelly

On Sat, Jul 19, 2014 at 10:41 AM, Chris Angelico ros...@gmail.com wrote:
 However, a *bare* HOME_KEY press is placing the insertion
 cursor *BEHIND* the prompt of the current line. In a shell
 environment, you never want to be *BEHIND* the command
 prompt.

 I don't know about the old versions, but in 3.4, it seems to be set so
 the Home key toggles between the beginning of the code and the
 beginning of the line. Seems a useful feature, although I can
 understand if you'd want to disable it and set the Home key to only
 ever go to the beginning of code. But that's a configuration question;
 this does not appear to be a bug.

I'd say that moving the cursor to a position where you can't type is a
bug. In that case, beginning of the line should be understood to be
after the prompt.

I see the use for it in an editing environment (I have an Emacs macro
that does the same thing), but I don't really see the point of having
the same feature in the shell other than for harmless consistency.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]


On 7/19/2014 12:28 AM, Steven D'Aprano wrote:

Earlier, I mentioned a considerable number of IDEs which are available
for Python, including:


I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors 
with code highlighting can get the job done as well, especially if the 
project is modest and doesn't require version control.


Chris Reimer
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-07-19 Thread Terry Reedy


On 7/19/2014 3:28 AM, Steven D'Aprano wrote:


So why does Python ship with IDLE?


On Windows the Idle shell is needed for sensible interactive use. For 
simply editing a Python file, running it, and fixing it, the Idle editor 
seems *about* as good as anything.



It's not because Python requires an
IDE, or that newbies need one, or that there aren't alternatives. The
biggest reason for Python shipping with an IDE is not that people are
unable to install alternatives, but that a lot of people are *prohibited*
from doing so.


This is true, but I think it understates the case.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-19 Thread Rick Johnson


[A missed point from my last reply...]

Terry Reedy said:
 I believe there is a proposal to be able to clear the
 shell window. We just need to add Clear and restart
 shell.

A command that allows clearing the *entire* shell display
and also resets the global and local symbol tables,
*WITHOUT* requiring a re- start of the entire IDLE
application, would be a great addition!

However, sometimes you just want to remove the displayed
result of the *LAST* command executed --for instance, in
the case of accidentally printing a *very large* data
structure-- and i believe this output undo action should
be clearly *DISTINCT* from your normal edit undo actions
via: CONTROL+Z

To solve this dilemma in *MY* command shell, i use the
ALT+UP_ARROW to delete everything from the last command
prompt to the end of the text buffer. I think IDLE needs
both functionality!

 There is also an idea to put help output in an
 output window.

I believe more windows just creates more confusion for the
user. Sometimes you have no choice but add additional
views, however, in this case at least, i believe a menu
command (coupled with a keyboard event) is the only
solution that can keep the interface manageable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-07-19 Thread Tim Delaney

On 20 July 2014 04:08, C.D. Reimer ch...@cdreimer.com wrote:

 On 7/19/2014 12:28 AM, Steven D'Aprano wrote:

 Earlier, I mentioned a considerable number of IDEs which are available
 for Python, including:


 I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors
 with code highlighting can get the job done as well, especially if the
 project is modest and doesn't require version control.


IMO there is no project so modest that it doesn't require version control.
Especially since version control is as simple as:

cd project
hg init
hg add
hg commit

FWIW I also don't find a need for an IDE for Python - I'm quite happy using
EditPlus (which I preferred enough to other alternatives on Windows to pay
for many years ago).

Tim Delaney
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-19 Thread Rick Johnson


[A missed point from my last reply...]

Terry Reedy said:
 I believe there is a proposal to be able to clear the
 shell window. We just need to add Clear and restart
 shell.

A command that allows a user to clear the *ENTIRE* shell
IO and *ALSO* resets the global and local symbol tables
*WITHOUT* requiring a re-start of the IDLE application,
would be a great addition indeed!

Currently IDLE shell has *ONLY* the Restart Shell
command, which simply resets the symbol table whilst leaving
all previous shell IO untouched. Which is useful in some
situations, but not all...

CONSIDER,

Sometimes you just want to remove the displayed result of
the *LAST* command executed *WHILST* maintaining any
previous displayed shell IO -- for instance, in the case
of accidentally printing a *very large* data structure, or a
horrendously untrimmed dir() requests.


#DISAMBIGUATION: EditUndo vs OutputUndo#

# In order to prevent confusion with the typical edit-#
# undo of CONTROL+Z, we should refer to the action of   #
# remove the last output displayed as an output-undo.  #


To solve this dilemma in *MY* command shell, i use the
ALT+UP_ARROW to delete everything from the last command
prompt up to the end of the text buffer, in effect,
creating an output-undo command without *DEFILING* the
standard semantics of ubiquitous CONTROL+Z.

I think IDLE needs all three functionality of:

  1. Reset symbol tables *WHILST* retaining previous shell
  IO (Already exists via Shell-Restart Shell)

  2. Reset symbol tables *AND* clear all shell IO (Maybe:
  Shell-Reset Shell)

  3. Remove the displayed result of the *LAST* command
  processed. (Maybe: Shell-Remove Last Output)

Hotkeys for all three are a must and should be configurable
by the user.

 There is also an idea to put help output in an
 output window.

I believe more windows just creates more confusion for the
user. Sometimes you have no choice but to add additional
views to a GUI interface, however, in this case at least,
i believe a menu command (coupled with a keyboard event) is
a best solution to maintain the highest level of interface
manageability -- IMHO.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

On Sun, Jul 20, 2014 at 4:00 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Sat, Jul 19, 2014 at 10:41 AM, Chris Angelico ros...@gmail.com wrote:
 However, a *bare* HOME_KEY press is placing the insertion
 cursor *BEHIND* the prompt of the current line. In a shell
 environment, you never want to be *BEHIND* the command
 prompt.

 I don't know about the old versions, but in 3.4, it seems to be set so
 the Home key toggles between the beginning of the code and the
 beginning of the line. Seems a useful feature, although I can
 understand if you'd want to disable it and set the Home key to only
 ever go to the beginning of code. But that's a configuration question;
 this does not appear to be a bug.

 I'd say that moving the cursor to a position where you can't type is a
 bug. In that case, beginning of the line should be understood to be
 after the prompt.

You can copy and paste from there. It's functionally equivalent to
being able to press Up arrow and move above the currently-editable
line. But even if it weren't for that, my statement would still be
correct: It's not a bug, and therefore not embarrassment, because it's
a feature that you may or may not like.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

On Sun, Jul 20, 2014 at 6:39 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
 To solve this dilemma in *MY* command shell, i use the
 ALT+UP_ARROW to delete everything from the last command
 prompt to the end of the text buffer. I think IDLE needs
 both functionality!

Okay, now I understand Rick's attitude. So long as Idle has one single
bug of which he is aware, or lacks one single feature which he can
think of, it is an utter and total embarrassment to the entire Python
community - not just those who work to make Idle what it is, but also
everyone who uses Idle... and everyone who doesn't use Idle, too.

Rick, start writing patches, and stop moaning like this just because
someone hasn't thought of something you've thought of. It may or may
not even be worth implementing this, but definitely you have the wrong
attitude toward feature requests.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney
timothy.c.dela...@gmail.com wrote:
 IMO there is no project so modest that it doesn't require version control.
 Especially since version control is as simple as:

 cd project
 hg init
 hg add
 hg commit

That said, though, there are some projects so modest they don't
require dedicated repositories. I have a repo called shed - it's a
collection of random tools that I've put together, no more logical
grouping exists. Generally each one is a single file, although I have
a couple of related ones in there. (Code at
https://github.com/Rosuav/shed if anyone's curious.) If I have an idea
for a program that doesn't really merit a full repo, I'll just save it
into shed. Keeps the where did I put that, what did I call that to a
minimum :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-19 Thread Terry Reedy


On 7/19/2014 6:50 PM, Rick Johnson wrote:


[A missed point from my last reply...]

Terry Reedy said:

I believe there is a proposal to be able to clear the
shell window. We just need to add Clear and restart
shell.



 # In order to prevent confusion with the typical edit-#
 # undo of CONTROL+Z, we should refer to the action of   #
 # remove the last output displayed as an output-undo.  #


That would make implementation easier.


I think IDLE needs all three functionality of:

   1. Reset symbol tables *WHILST* retaining previous shell
   IO (Already exists via Shell-Restart Shell)

   2. Reset symbol tables *AND* clear all shell IO (Maybe:
   Shell-Reset Shell)

   3. Remove the displayed result of the *LAST* command
   processed. (Maybe: Shell-Remove Last Output)

Hotkeys for all three are a must


I consider them a nicety. We will eventually run out of simple hot keys.


and should be configurable by the user.


I believe anything Idle controls is.


There is also an idea to put help output in an
output window.


In the new issue, I said 'move the last output' from the shell to a 
window, so it would be entirely optional.



I believe more windows just creates more confusion for the
user.


I expect to eventually look at G.Polo's patch for using tabbed 
notebooks, which will help with this.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-07-19 Thread Tim Delaney

On 20 July 2014 09:19, Chris Angelico ros...@gmail.com wrote:

 On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney
 timothy.c.dela...@gmail.com wrote:
  IMO there is no project so modest that it doesn't require version
 control.
  Especially since version control is as simple as:
 
  cd project
  hg init
  hg add
  hg commit

 That said, though, there are some projects so modest they don't
 require dedicated repositories. I have a repo called shed - it's a
 collection of random tools that I've put together, no more logical
 grouping exists.


Agreed. I have a utils one - but I do like shed and think I'm going to
rename :)

The main thing is that versioning should be automatic now - it's almost
free, and the benefits are huge because even trivial scripts end up
evolving.

Tim Delaney
-- 
https://mail.python.org/mailman/listinfo/python-list

Repo/directory names (was Re: Python and IDEs [was Re: Python 3 is killing Python])

On Sun, Jul 20, 2014 at 10:41 AM, Tim Delaney
timothy.c.dela...@gmail.com wrote:
 On 20 July 2014 09:19, Chris Angelico ros...@gmail.com wrote:

 That said, though, there are some projects so modest they don't
 require dedicated repositories. I have a repo called shed - it's a
 collection of random tools that I've put together, no more logical
 grouping exists.

 Agreed. I have a utils one - but I do like shed and think I'm going to
 rename :)

I first met that name on our old DOS and OS/2 systems, set up by my
Dad. It was a directory on whichever drive was appropriate (exactly
one per installation - we wouldn't risk a network dependency here),
and had programs that would probably go in /usr/bin or /usr/local/bin
on a Unix system. Part of setting up a new OS/2 installation was
always copying E:\SHED (the network drive) to D:\SHED, and putting
D:\SHED\NPSWPS\NPSWPS.EXE into Startup. (NPS WPS Enhancer, awesome
program. If you have OS/2, get it. What, you don't have OS/2 anywhere?
What a surprise.)

Other people had, for instance, a C:\BELFRY (best place to have BATs,
you know), or other such names. What's your favorite
directory/repository name for a concretion of ... random stuff?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]


On 7/19/2014 5:41 PM, Tim Delaney wrote:
The main thing is that versioning should be automatic now - it's 
almost free, and the benefits are huge because even trivial scripts 
end up evolving.


I keep my modest Python scripts in a Dropbox directory and run a weekly 
Python script to zip up the Dropbox directory for safekeeping on the 
home file server and Microsoft OneDrive. If I really need a recent copy 
of a script, Time Machine on the Mac should have a copy from the Drop 
Box folder.


The only time I use version control is when I have a big project with 
many moving parts and/or I'm publishing software for other people to use.


Chris Reimer
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-07-19 Thread Steven D'Aprano

On Sat, 19 Jul 2014 14:31:10 -0400, Terry Reedy wrote:

 On 7/19/2014 3:28 AM, Steven D'Aprano wrote:
 
 So why does Python ship with IDLE?
 
 On Windows the Idle shell is needed for sensible interactive use.

One might say that *some* IDE is needed, but Idle itself isn't 
compulsory :-)

It also depends on what you consider sensible.

I haven't used Python on Windows much, but when I did use it, I found the 
standard Python interactive interpreter running under cmd.exe to be bare-
bones but usable for testing short snippets. If I recall correctly, it is 
missing any sort of command history or line editing other than backspace, 
which I guess it would have been painful to use for extensive interactive 
work, but when I started using Python on Linux the interactive 
interpreter had no readline support either so it was just like old 
times :-)


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

On Sun, Jul 20, 2014 at 11:23 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 If I recall correctly, it [Python under cmd.exe] is
 missing any sort of command history or line editing other than backspace,

Not quite, but it has some extreme oddities. I'd have to call them
features because I can't imagine them to be bugs, but they're very
surprising... like how you can recall something, but if you enter it
without any editing, your current recall position is retained. This
means you can re-enter a series of lines by recalling the first and
then pressing Down, Enter for each subsequent line (it's a feature!),
but it means that any usage where the lines are truly independent will
start getting very awkward.

In contrast, Idle recalls entire suites, rather than individual lines,
which (IMO) makes it superior to a readline-based interface.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]



On 7/19/2014 6:23 PM, Steven D'Aprano wrote:
I haven't used Python on Windows much, but when I did use it, I found 
the standard Python interactive interpreter running under cmd.exe to 
be bare- bones but usable for testing short snippets. If I recall 
correctly, it is missing any sort of command history or line editing 
other than backspace, which I guess it would have been painful to use 
for extensive interactive work, but when I started using Python on 
Linux the interactive interpreter had no readline support either so it 
was just like old times :-)


Windows PowerShell supports very basic Linux commands and has a command 
history. I'm always typing ls for a directory listing when I'm on a 
Windows machine. The regular command line would throw a DOS fit. 
PowerShell lets me get away with it.


http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands

I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is 
dying and MacBook shuts down after 15 minutes. I'm surprised at how well 
I was able to set up a equivalent programming environment on Windows.


Chris Reimer
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-07-19 Thread TP

On Sat, Jul 19, 2014 at 12:28 AM, Steven D'Aprano 
steve+comp.lang.pyt...@pearwood.info wrote:

 For Python users, the IDEs from
 Wingware and Activestate are notable:

 https://wingware.com/
 http://komodoide.com/


I would say that since PyCharm (https://www.jetbrains.com/pycharm/) now has
a free Community Edition it is an even more notable IDE as the above two
programs cost $.

And as a Windows user, for version control I really like TortoiseHg (
http://tortoisehg.bitbucket.org/) for Mercurial. Likewise I tend to use
TortoiseSVN and TortoiseGit rather than the command line. PyCharm even has
support for those but I still like right-clicking on folders in Windows
Explorer and activating various hg commands from the popup menu. Especially
since not every program I write is written in Python :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]



On 7/19/2014 7:03 PM, TP wrote:
I would say that since PyCharm (https://www.jetbrains.com/pycharm/) 
now has a free Community Edition it is an even more notable IDE as the 
above two programs cost $.


PyCharm look really nice as an IDE. Thanks for the heads up.

Chris Reimer
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

2014-07-19 Thread Tim Delaney

On 20 July 2014 11:53, C.D. Reimer ch...@cdreimer.com wrote:


 On 7/19/2014 6:23 PM, Steven D'Aprano wrote:

 I haven't used Python on Windows much, but when I did use it, I found the
 standard Python interactive interpreter running under cmd.exe to be bare-
 bones but usable for testing short snippets. If I recall correctly, it is
 missing any sort of command history or line editing other than backspace,
 which I guess it would have been painful to use for extensive interactive
 work, but when I started using Python on Linux the interactive interpreter
 had no readline support either so it was just like old times :-)


 Windows PowerShell supports very basic Linux commands and has a command
 history. I'm always typing ls for a directory listing when I'm on a
 Windows machine. The regular command line would throw a DOS fit. PowerShell
 lets me get away with it.

 http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_
 of_cmdlets_with_similar_commands

 I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is
 dying and MacBook shuts down after 15 minutes. I'm surprised at how well I
 was able to set up a equivalent programming environment on Windows.


I advise anyone who works cross-platform to install MSYS on their Windows
boxes (for the simplest, most consistent behaviour ignore rxvt and just
launch bash -l - i directly). Or use cygwin if you prefer.

Tim Delaney
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Repo/directory names (was Re: Python and IDEs [was Re: Python 3 is killing Python])

2014-07-19 Thread Gregory Ewing


Chris Angelico wrote:

Other people had, for instance, a C:\BELFRY (best place to have BATs,
you know), or other such names. What's your favorite
directory/repository name for a concretion of ... random stuff?


My project directories typically contain a directory
called Attic for putting stuff in that I probably
won't use any more, but want to keep just in case.

Fortunately, it doesn't have the same space restrictions
as its physical namesake. :-)

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python


On 18/07/2014 01:45, Andrew Berg wrote:

On 2014.07.17 19:26, Mark Lawrence wrote:

I'm looking forward to see the massive number of fixes that come from
rr, assuming of course that he signs the CLA to make this possible.  Or
has he already done so?


Maybe he's too busy working on RickPy 4000 (or whatever it was called).



I believe that rick would be a very apt word in this case.

--
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


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python


On 18/07/2014 03:24, Rick Johnson wrote:

On Thursday, July 17, 2014 1:44:20 PM UTC-5, Marko Rauhamaa wrote:

Rick Johnson :

Sure, IDLE is not *useless*, however, it is in fact
woefully inadequate and should be embarrassing to the
whole community, both in it's buggy-ness and it's poorly
written source code.

This is beneath trolling. Redeem yourself by apologizing.


Apologize for what?

For telling the truth?

I have been using IDLE since around 2006, well at least,
that is as far back as i remember. When i first learned
Python, IDLE was my editor of choice, and i *STILL* use IDLE
to this very day! -- although not as much as i have written
my own IDE.

I have logged thousands upon thousands of hours with IDLE,
how many hours have *YOU* logged?

I would even venture to say, and the comments on this list
have supported my evidence for years, that i may be the
*SOLE* heavy user of IDLE in the *ENTIRE* community.
Although, i need to compare my stats with Terry because he
claims to use the software quite often also.

If *ANYBODY* in this damn community has a *RIGHT* to
complain about IDLE, then *I* am that person. HOW DARE YOU
chastise me for voicing my grievances regarding a
software that *YOU* most likely have *NEVER*, or only
*SLIGHTLY*, used!



Please list for everybody to see the issue numbers that you've worked 
on, on IDLE, on the bug tracker.  Thank you.


I now routinely use IDLE as it has been so much improved due to the 
efforts of Terry  Co.  You are conspicious by your absence.


--
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


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-18 Thread Ian Kelly

On Thu, Jul 17, 2014 at 9:37 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
 On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:
 For myself, though, I completely do not use the editor half of [IDLE]; but
 it's spectacularly useful (with limitations) as my primary interactive
 interpreter.

 Yes Chris, i also think that the IDLE shell is spectacular
 when i'm using it, especially when i press
 CONTROL+LEFT_ARROW and the insertion cursor lands *BEHIND*
 the start of the interactive command marker  , an
 area where key presses are not allowed, so *NOW* I must press
 CONTROL+RIGHT_ARROW three times to get to my destination!

I just tried to reproduce this using IDLE 3.4 on Windows and was not able to.

 I'm also just gushing with exuberance when i open a new
 block and i get *EIGHT SPACE INDENTION*!

In the file editor when I press Tab I get four spaces as I would
expect, using the default configuration. In the interactive
interpreter I get an actual tab character again as I would expect.
That's probably as it should be since I wouldn't want to not be able
to type a tab character there.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-18 Thread Chris Angelico

On Fri, Jul 18, 2014 at 6:21 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
 Yes Chris, i also think that the IDLE shell is spectacular
 when i'm using it, especially when i press
 CONTROL+LEFT_ARROW and the insertion cursor lands *BEHIND*
 the start of the interactive command marker  , an
 area where key presses are not allowed, so *NOW* I must press
 CONTROL+RIGHT_ARROW three times to get to my destination!

 I just tried to reproduce this using IDLE 3.4 on Windows and was not able to.

Actually, now you mention it, I do recall experiencing a bug like this
in previous versions. It's not the case in either my 2.7 (point
something, but I don't remember what) nor 3.4, so I'm guessing it's
been fixed.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-18 Thread Grant Edwards

On 2014-07-18, alex23 wuwe...@gmail.com wrote:
 On 17/07/2014 1:14 PM, Steven D'Aprano wrote:
 There will never be a Python 2.8. When push comes to shove, the people
 bitching about Python 3 will not do the work necessary to fork Python 2.7
 and make a version 2.8.

 +1

 The idea that forking and maintaining Python 2.8 is somehow _less 
 effort_ than porting code to Python 3.x is batshit crazy. The Py2.8 
 claims seem to me to be nothing more than a shallow attempt to blackmail 
 the core devs.

IMO, it's not even a credible threat.  It's more like idle whinging
from people whom if given a brand new free BMW with lifetime
maintenance, gasoline, insurance, taxes and registration paid (and a
garage to keep it in) would bitch about the color of the interior.

-- 
Grant Edwards   grant.b.edwardsYow! I'm pretending that
  at   we're all watching PHIL
  gmail.comSILVERS instead of RICARDO
   MONTALBAN!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-18 Thread Grant Edwards

On 2014-07-18, Rick Johnson rantingrickjohn...@gmail.com wrote:
 On Thursday, July 17, 2014 1:44:20 PM UTC-5, Marko Rauhamaa wrote:
 Rick Johnson :

 Sure, IDLE is not *useless*, however, it is in fact woefully
 inadequate and should be embarrassing to the whole community, both in
 it's buggy-ness and it's poorly written source code.

 This is beneath trolling. Redeem yourself by apologizing.

 Apologize for what? 

Oh dear.  Where should we start...

 For telling the truth? 

Possibly, yes.  Truth is no excuse for being rude and insulting.  I've
never used IDLE, so don't know much about it. But, I do know that a
decent, civilized person just doesn't make insulting comments like
that about somebody else's work even if it is true (which I very much
doubt).

-- 
Grant Edwards   grant.b.edwardsYow! If I am elected no one
  at   will ever have to do their
  gmail.comlaundry again!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-18 Thread Larry Martell

On Fri, Jul 18, 2014 at 8:19 AM, Grant Edwards invalid@invalid.invalid wrote:
 But, I do know that a
 decent, civilized person just doesn't make insulting comments like
 that about somebody else's work even if it is true (which I very much
 doubt).

Now, _that's_ funny. This is the internet. If you can't stand the heat
get out of the kitchen.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-18 Thread Torsten Bronger

Hallöchen!

Larry Martell writes:

 On Fri, Jul 18, 2014 at 8:19 AM, Grant Edwards invalid@invalid.invalid 
 wrote:

 But, I do know that a decent, civilized person just doesn't make
 insulting comments like that about somebody else's work even if
 it is true (which I very much doubt).

 Now, _that's_ funny. This is the internet. If you can't stand the
 heat get out of the kitchen.

Now, _that's_ funny. This is the internet. If you can't stand people
who can't stand the heat get out of the kitchen.

Tschö,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python


On 18/07/2014 04:01, alex23 wrote:

On 18/07/2014 10:45 AM, Andrew Berg wrote:

Maybe he's too busy working on RickPy 4000 (or whatever it was called).


I believe the new working name is PypeDream.



For me a very good day just got better with that one, thanks :)

--
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


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-18 Thread MRAB


On 2014-07-18 04:37, Rick Johnson wrote:

On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:

For myself, though, I completely do not use the editor half of [IDLE]; but
it's spectacularly useful (with limitations) as my primary interactive
interpreter.


Yes Chris, i also think that the IDLE shell is spectacular
when i'm using it, especially when i press
CONTROL+LEFT_ARROW and the insertion cursor lands *BEHIND*
the start of the interactive command marker  , an
area where key presses are not allowed, so *NOW* I must press
CONTROL+RIGHT_ARROW three times to get to my destination!

I'm also just gushing with exuberance when i open a new
block and i get *EIGHT SPACE INDENTION*!

And I get a raging semi each time IDLE hangs between run
sessions when i'm editing Tkinter code, yes Chris,  I GET A
BIG FAT ERECTION! Sometimes, when it does not go away
after four hours, i have to visit the local emergency room
and take some pills.

  THAT'S HOW MUCH I JUST *LOVE* THIS CRAPPY SOFTWARE CHRIS!

  I'M SO GLAD WE CAN SHARE THESE WONDERFUL EXPERIENCES TOGETHER!

  MAYBE NEXT WE CAN RE-INACT THE LAST SCENE OF ROMEO AND JULIETTE?


[...] The only problem I have with it is that blatting
ridiculous amounts of text to the console can take a very
long time, esp on Windows. If I accidentally display a
large object when I thought I was displaying a small one,
it'll hang for quite a while, churning through something,
and it's not easy to see why or to halt it. But I suspect
that's more of a Windows and/or Tk issue than an Idle one.


The *PROBLEM* is that user has no method of undo-ing an
accidental display of huge amounts of data , forcing the
user to close and then re-open the entire software -- can
you understand now *WHY* i complain about this software?

This is *EMBARRASSING*, and you should *ALL* be ashamed
that, not only does Python include such an amateurish piece
of crap software, but it has been there for years!

 UNCHANGED FOR YEARS!!!


I'm sorry to hear that you've been suffering all these years. If only
there were a way to fix it.

Here's a suggestion for the Python community: how about opening up the
source code and letting people contribute fixes? We could call this
open source.

We could even open the source for CPython itself! Could that work?

What do you think?

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python


On 18/07/2014 04:37, Rick Johnson wrote:

On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:

For myself, though, I completely do not use the editor half of [IDLE]; but
it's spectacularly useful (with limitations) as my primary interactive
interpreter.


Yes Chris, i also think that the IDLE shell is spectacular
when i'm using it, especially when i press
CONTROL+LEFT_ARROW and the insertion cursor lands *BEHIND*
the start of the interactive command marker  , an
area where key presses are not allowed, so *NOW* I must press
CONTROL+RIGHT_ARROW three times to get to my destination!

I'm also just gushing with exuberance when i open a new
block and i get *EIGHT SPACE INDENTION*!

And I get a raging semi each time IDLE hangs between run
sessions when i'm editing Tkinter code, yes Chris,  I GET A
BIG FAT ERECTION! Sometimes, when it does not go away
after four hours, i have to visit the local emergency room
and take some pills.

  THAT'S HOW MUCH I JUST *LOVE* THIS CRAPPY SOFTWARE CHRIS!

  I'M SO GLAD WE CAN SHARE THESE WONDERFUL EXPERIENCES TOGETHER!

  MAYBE NEXT WE CAN RE-INACT THE LAST SCENE OF ROMEO AND JULIETTE?


[...] The only problem I have with it is that blatting
ridiculous amounts of text to the console can take a very
long time, esp on Windows. If I accidentally display a
large object when I thought I was displaying a small one,
it'll hang for quite a while, churning through something,
and it's not easy to see why or to halt it. But I suspect
that's more of a Windows and/or Tk issue than an Idle one.


The *PROBLEM* is that user has no method of undo-ing an
accidental display of huge amounts of data , forcing the
user to close and then re-open the entire software -- can
you understand now *WHY* i complain about this software?

This is *EMBARRASSING*, and you should *ALL* be ashamed
that, not only does Python include such an amateurish piece
of crap software, but it has been there for years!

 UNCHANGED FOR YEARS!!!



This is patently wrong, IDLE is constantly being improved.  I also don't 
recall ever seeing a bug report from yourself about IDLE.  Your gretest 
strength seems to be complaining, your biggest weakness doing anything 
about whatever it is that you're complaining about.


--
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


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python


On 18/07/2014 09:27, Chris Angelico wrote:

On Fri, Jul 18, 2014 at 6:21 PM, Ian Kelly ian.g.ke...@gmail.com wrote:

Yes Chris, i also think that the IDLE shell is spectacular
when i'm using it, especially when i press
CONTROL+LEFT_ARROW and the insertion cursor lands *BEHIND*
the start of the interactive command marker  , an
area where key presses are not allowed, so *NOW* I must press
CONTROL+RIGHT_ARROW three times to get to my destination!


I just tried to reproduce this using IDLE 3.4 on Windows and was not able to.


Actually, now you mention it, I do recall experiencing a bug like this
in previous versions. It's not the case in either my 2.7 (point
something, but I don't remember what) nor 3.4, so I'm guessing it's
been fixed.

ChrisA



Fixed by whom, Terry Reedy  Co or rr?

--
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


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python


On 18/07/2014 16:46, MRAB wrote:

On 2014-07-18 04:37, Rick Johnson wrote:

On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote:

For myself, though, I completely do not use the editor half of
[IDLE]; but
it's spectacularly useful (with limitations) as my primary interactive
interpreter.


Yes Chris, i also think that the IDLE shell is spectacular
when i'm using it, especially when i press
CONTROL+LEFT_ARROW and the insertion cursor lands *BEHIND*
the start of the interactive command marker  , an
area where key presses are not allowed, so *NOW* I must press
CONTROL+RIGHT_ARROW three times to get to my destination!

I'm also just gushing with exuberance when i open a new
block and i get *EIGHT SPACE INDENTION*!

And I get a raging semi each time IDLE hangs between run
sessions when i'm editing Tkinter code, yes Chris,  I GET A
BIG FAT ERECTION! Sometimes, when it does not go away
after four hours, i have to visit the local emergency room
and take some pills.

  THAT'S HOW MUCH I JUST *LOVE* THIS CRAPPY SOFTWARE CHRIS!

  I'M SO GLAD WE CAN SHARE THESE WONDERFUL EXPERIENCES TOGETHER!

  MAYBE NEXT WE CAN RE-INACT THE LAST SCENE OF ROMEO AND JULIETTE?


[...] The only problem I have with it is that blatting
ridiculous amounts of text to the console can take a very
long time, esp on Windows. If I accidentally display a
large object when I thought I was displaying a small one,
it'll hang for quite a while, churning through something,
and it's not easy to see why or to halt it. But I suspect
that's more of a Windows and/or Tk issue than an Idle one.


The *PROBLEM* is that user has no method of undo-ing an
accidental display of huge amounts of data , forcing the
user to close and then re-open the entire software -- can
you understand now *WHY* i complain about this software?

This is *EMBARRASSING*, and you should *ALL* be ashamed
that, not only does Python include such an amateurish piece
of crap software, but it has been there for years!

 UNCHANGED FOR YEARS!!!


I'm sorry to hear that you've been suffering all these years. If only
there were a way to fix it.

Here's a suggestion for the Python community: how about opening up the
source code and letting people contribute fixes? We could call this
open source.

We could even open the source for CPython itself! Could that work?

What do you think?



That plan is so cunning it makes Baldrick's cunning plans look good :)

http://en.wikipedia.org/wiki/Baldrick

Actually I believe we should just leave things alone, if it ain't broke, 
don't fix it.


--
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


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-18 Thread Steven D'Aprano

On Thu, 17 Jul 2014 10:36:43 -0700, Rick Johnson wrote:

 On Thursday, July 17, 2014 12:48:38 AM UTC-5, alex23 wrote:
 PHP regularly breaks compatibility between _minor_ version releases:
 [...] more so with major releases: [...] yet I never see anywhere near
 as much angst and agony as Python 3.x has caused.
 
 Because you *IGNORE* the fact that people *ACTIVELY* choose to use
 languages like Python, however, people *MOSTLY* use languages like PHP
 and Javascript because they are *FORCED*

That explains all those concentration camps in North Korea, filled with 
political prisoners sentenced to 30 years of PHP programming.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

2014-07-18 Thread Steven D'Aprano

On Thu, 17 Jul 2014 11:15:59 -0700, Rick Johnson wrote:

 On Thursday, July 17, 2014 5:12:23 AM UTC-5, Fabien wrote:
 For non-informatic students [...] I don't think that's true. Less
 general languages like Matlab appear much easier to me: unified doc,
 unified IDE, unified debugger
 
 I'll agree that the lack of a quality IDE in Python is a point of
 inadequacy. 

https://wiki.python.org/moin/IntegratedDevelopmentEnvironments

PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE, Geany, IEP, 
Spyder, Boa Constructor, PyScripter, NetBeans, Emacs, KDevelop, 
BlackAdder, ...



[...]
 Sadly, all of my calls to improve IDLE have been meet with rebukes about
 me whining. 

Why don't you go volunteer to fix a few IDLE bugs, instead of just 
demanding that others do it?

http://bugs.python.org/issue17620



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python