Re: [Python-Dev] [Python-checkins] cpython (2.7): - Issue #13150: sysconfig no longer parses the Makefile and config.h files

[Andrew Svetlov]

Great!

On Thu, Mar 21, 2013 at 3:02 PM, matthias.klose
 wrote:
> http://hg.python.org/cpython/rev/66e30c4870bb
> changeset:   82872:66e30c4870bb
> branch:  2.7
> parent:  82843:71adf21421d9
> user:d...@ubuntu.com
> date:Thu Mar 21 15:02:16 2013 -0700
> summary:
>   - Issue #13150: sysconfig no longer parses the Makefile and config.h files
>   when imported, instead doing it at build time.  This makes importing
>   sysconfig faster and reduces Python startup time by 20%.
>
> files:
>   Lib/distutils/sysconfig.py |  63 +
>   Lib/pprint.py  |   5 +-
>   Lib/sysconfig.py   |  75 -
>   Makefile.pre.in|  12 +++-
>   Misc/NEWS  |   4 +
>   5 files changed, 93 insertions(+), 66 deletions(-)
>
>
> diff --git a/Lib/distutils/sysconfig.py b/Lib/distutils/sysconfig.py
> --- a/Lib/distutils/sysconfig.py
> +++ b/Lib/distutils/sysconfig.py
> @@ -387,66 +387,11 @@
>
>  def _init_posix():
>  """Initialize the module as appropriate for POSIX systems."""
> -g = {}
> -# load the installed Makefile:
> -try:
> -filename = get_makefile_filename()
> -parse_makefile(filename, g)
> -except IOError, msg:
> -my_msg = "invalid Python installation: unable to open %s" % filename
> -if hasattr(msg, "strerror"):
> -my_msg = my_msg + " (%s)" % msg.strerror
> -
> -raise DistutilsPlatformError(my_msg)
> -
> -# load the installed pyconfig.h:
> -try:
> -filename = get_config_h_filename()
> -parse_config_h(file(filename), g)
> -except IOError, msg:
> -my_msg = "invalid Python installation: unable to open %s" % filename
> -if hasattr(msg, "strerror"):
> -my_msg = my_msg + " (%s)" % msg.strerror
> -
> -raise DistutilsPlatformError(my_msg)
> -
> -# On AIX, there are wrong paths to the linker scripts in the Makefile
> -# -- these paths are relative to the Python source, but when installed
> -# the scripts are in another directory.
> -if python_build:
> -g['LDSHARED'] = g['BLDSHARED']
> -
> -elif get_python_version() < '2.1':
> -# The following two branches are for 1.5.2 compatibility.
> -if sys.platform == 'aix4':  # what about AIX 3.x ?
> -# Linker script is in the config directory, not in Modules as the
> -# Makefile says.
> -python_lib = get_python_lib(standard_lib=1)
> -ld_so_aix = os.path.join(python_lib, 'config', 'ld_so_aix')
> -python_exp = os.path.join(python_lib, 'config', 'python.exp')
> -
> -g['LDSHARED'] = "%s %s -bI:%s" % (ld_so_aix, g['CC'], python_exp)
> -
> -elif sys.platform == 'beos':
> -# Linker script is in the config directory.  In the Makefile it 
> is
> -# relative to the srcdir, which after installation no longer 
> makes
> -# sense.
> -python_lib = get_python_lib(standard_lib=1)
> -linkerscript_path = string.split(g['LDSHARED'])[0]
> -linkerscript_name = os.path.basename(linkerscript_path)
> -linkerscript = os.path.join(python_lib, 'config',
> -linkerscript_name)
> -
> -# XXX this isn't the right place to do this: adding the Python
> -# library to the link, if needed, should be in the "build_ext"
> -# command.  (It's also needed for non-MS compilers on Windows, 
> and
> -# it's taken care of for them by the 'build_ext.get_libraries()'
> -# method.)
> -g['LDSHARED'] = ("%s -L%s/lib -lpython%s" %
> - (linkerscript, PREFIX, get_python_version()))
> -
> +# _sysconfigdata is generated at build time, see the sysconfig module
> +from _sysconfigdata import build_time_vars
>  global _config_vars
> -_config_vars = g
> +_config_vars = {}
> +_config_vars.update(build_time_vars)
>
>
>  def _init_nt():
> diff --git a/Lib/pprint.py b/Lib/pprint.py
> --- a/Lib/pprint.py
> +++ b/Lib/pprint.py
> @@ -37,7 +37,10 @@
>  import sys as _sys
>  import warnings
>
> -from cStringIO import StringIO as _StringIO
> +try:
> +from cStringIO import StringIO as _StringIO
> +except ImportError:
> +from StringIO import StringIO as _StringIO
>
>  __all__ = ["pprint","pformat","isreadable","isrecursive","saferepr",
> "PrettyPrinter"]
> diff --git a/Lib/sysconfig.py b/Lib/sysconfig.py
> --- a/Lib/sysconfig.py
> +++ b/Lib/sysconfig.py
> @@ -278,9 +278,10 @@
>  return os.path.join(_PROJECT_BASE, "Makefile")
>  return os.path.join(get_path('platstdlib'), "config", "Makefile")
>
> -
> -def _init_posix(vars):
> -"""Initialize the module as appropriate for POSIX systems."""
> +def _generate_posix_vars():
> +"""Generate the Python module containing build-time variables."""
> +import pprint
> +vars =

Re: [Python-Dev] IDLE in the stdlib

[Todd Rovito]

On Thu, Mar 21, 2013 at 11:21 AM, Nick Coghlan  wrote:
> We can refactor IDLE to make aspects of it easier to test with the
> buildbots, especially now that we have unittest.mock in the standard
> library to mock out some of the UI interaction in the test suite. (I'm
> happy to help coach the IDLE devs on that if they want to start
> improving the test suite coverage for the IDLE code)
Count me in where/when do we start?  Can we perhaps setup a IRC chat with you?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slides from today's parallel/async Python talk

[Trent Nelson]

http://c2.com/cgi/wiki?BlubParadox

;-)

Sent from my iPhone

On 21 Mar 2013, at 06:18, "Antoine Pitrou"  wrote:

> Le Thu, 14 Mar 2013 15:23:37 -0700,
> Trent Nelson  a écrit :
>> 
>>Don't get me wrong, I grew up with UNIX and love it as much as the
>>next guy, but you can't deny the usefulness of Windows' facilities
>>for writing high-performance, multi-threaded IO code.  It's
>> decades ahead of POSIX.
> 
> I suppose that's why all high-performance servers run under Windows.
> 
> Regards
> 
> Antoine.
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/trent%40snakebite.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slides from today's parallel/async Python talk

[Trent Nelson]

No, I haven't.  I'd lose the excellent Windows pairing of thread pool IO and 
overlapped IO facilities if I did that.

Not saying it isn't an option down the track for the generic "submit work" API 
though; that stuff will work against any thread pool without too much effort.

But for now, the fact that all I need to call is TrySubmitThreadpoolCallback 
and Windows does *everything* else is pretty handy.  Lets me concentrate on the 
problem instead of getting distracted by scaffolding.

This e-mail was sent from a wireless device. 

On 21 Mar 2013, at 05:53, "Sturla Molden"  wrote:

> Den 14. mars 2013 kl. 23:23 skrev Trent Nelson :
> 
>> 
>>   For the record, here are all the Windows calls I'm using that have
>>   no *direct* POSIX equivalent:
>> 
>>   Interlocked singly-linked lists:
>>   - InitializeSListHead()
>>   - InterlockedFlushSList()
>>   - QueryDepthSList()
>>   - InterlockedPushEntrySList()
>>   - InterlockedPushListSList()
>>   - InterlockedPopEntrySlist()
>> 
>>   Synchronisation and concurrency primitives:
>>   - Critical sections
>>   - InitializeCriticalSectionAndSpinCount()
>>   - EnterCriticalSection()
>>   - LeaveCriticalSection()
>>   - TryEnterCriticalSection()
>>   - Slim read/writer locks (some pthread implements have
>> rwlocks)*:
>>   - InitializeSRWLock()
>>   - AcquireSRWLockShared()
>>   - AcquireSRWLockExclusive()
>>   - ReleaseSRWLockShared()
>>   - ReleaseSRWLockExclusive()
>>   - TryAcquireSRWLockExclusive()
>>   - TryAcquireSRWLockShared()
>>   - One-time initialization:
>>   - InitOnceBeginInitialize()
>>   - InitOnceComplete()
>>   - Generic event, signalling and wait facilities:
>>   - CreateEvent()
>>   - SetEvent()
>>   - WaitForSingleObject()
>>   - WaitForMultipleObjects()
>>   - SignalObjectAndWait()
>> 
>>   Native thread pool facilities:
>>   - TrySubmitThreadpoolCallback()
>>   - StartThreadpoolIo()
>>   - CloseThreadpoolIo()
>>   - CancelThreadpoolIo()
>>   - DisassociateCurrentThreadFromCallback()
>>   - CallbackMayRunLong()
>>   - CreateThreadpoolWait()
>>   - SetThreadpoolWait()
>> 
>>   Memory management:
>>   - HeapCreate()
>>   - HeapAlloc()
>>   - HeapDestroy()
>> 
>>   Structured Exception Handling (#ifdef Py_DEBUG):
>>   - __try/__except
>> 
>>   Sockets:
>>   - ConnectEx()
>>   - AcceptEx()
>>   - WSAEventSelect(FD_ACCEPT)
>>   - DisconnectEx(TF_REUSE_SOCKET)
>>   - Overlapped WSASend()
>>   - Overlapped WSARecv()
>> 
>> 
>>   Don't get me wrong, I grew up with UNIX and love it as much as the
>>   next guy, but you can't deny the usefulness of Windows' facilities
>>   for writing high-performance, multi-threaded IO code.  It's decades
>>   ahead of POSIX.  (Which is also why it bugs me when I see select()
>>   being used on Windows, or IOCP being used as if it were a poll-type
>>   "generic IO multiplexor" -- that's like having a Ferrari and speed
>>   limiting it to 5mph!)
>> 
>>   So, before any of this has a chance of working on Linux/BSD, a lot
>>   more scaffolding will need to be written to provide the things we
>>   get for free on Windows (threadpools being the biggest freebie).
>> 
>> 
>> 
> 
> 
> Have you considered using OpenMP instead of Windows API or POSIX threads 
> directly? OpenMP gives you a thread pool and synchronization primitives for 
> free as well, with no special code needed for Windows or POSIX. 
> 
> OpenBLAS (and GotoBLAS2) uses OpenMP to produce a thread pool on POSIX 
> systems (and actually Windows API on Windows). The OpenMP portion of the C 
> code is wrapped so it looks like sending an asynch task to a thread pool; the 
> C code is not littered with OpenMP pragmas. If you need something like 
> Windows threadpools on POSIX, just look at the BSD licensed OpenBLAS code. It 
> is written to be scalable for the world's largest supercomputers (but also 
> beautifully written and very easy to read).
> 
> Cython has code to register OpenMP threads as Python threads, in case that is 
> needed. So that problem is also solved.
> 
> 
> Sturla
> 
> 
> 
> 
> 
> 
> 
> 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/21/2013 7:17 PM, Thomas Wouters wrote:


although I do think we should move 'idlelib' out of the standard library :)


Currently, 'python -m idlelib' start idle from the command line. If 
idlelib/ were moved out of /Lib, idle.py should be added so 'python -m 
idle' would work. I may suggest that anyway.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/21/2013 11:21 AM, Nick Coghlan wrote:

On Thu, Mar 21, 2013 at 5:26 AM, Daniel Holth  wrote:

I showed IDLE to my 6-year-old on the Raspberry Pi and I'm convinced
it is cool. Gave up on trying to (slowly) install bpython. We were
multiplying large numbers and counting to 325,000 in no time. It might
not be for *me* but I'm not going to teach my daughter a large IDE any
time soon.


This, 1000x this.

It was helping out at the Young Coders tutorials that convinced me we
need to continue shipping IDLE, or something like it, for use by
*people learning to use computers as more than just passive consumers
for the first time*. This means running well on Windows and the
Raspberry Pi at this point.

Keeping IDLE in the core represents a commitment to the use of Python
as a teaching language both inside and outside of formal educational
settings.

We can refactor IDLE to make aspects of it easier to test with the
buildbots, especially now that we have unittest.mock in the standard
library to mock out some of the UI interaction in the test suite. (I'm
happy to help coach the IDLE devs on that if they want to start
improving the test suite coverage for the IDLE code)


Thank for for the offer to help. I added you to the IDLE test issue.
http://bugs.python.org/issue15392
Improving tests is one of the main things I personally want to do. Roger 
is expert at tkinter code, so I will focus on other things. I want to 
work toward IDLE patches following the standard rule of adding at least 
one test with every patch. A permanent exemption from that rule is *not* 
part of the PEP.



I think we should commit to making "start with IDLE" the recommended
teaching experience, and then focus on *making that experience
awesome*. Once people are already familiar with the language and what
it can do for them, they may choose to move on to other tools, or they
may decide to stick with IDLE. But deciding on "What is IDLE?" and
"Why is it part of the CPython development repo?" is a necessary step
to revitalising it and stopping the recurring discussions about taking
it out.



If Terry is willing to recast his PEP in that light, I think that
would be a wonderful thing to do.


I completely agree ;-). I asked Todd to help with this, and perhaps you 
can give me some more concrete hints as to what you would like to see where.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/21/2013 5:19 PM, Mark Janssen wrote:

On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote:



I might be jumping in late here, but...


Not at all. Thank you for the enlightening post.


The *only* thing I find "ugly" about it is that it doesn't have a
white-on-black color scheme.


Oh.

The wonderful thing about computers is the possibility of customizing to 
taste. The think I do not like about .pdf is the motivation to 'control 
the user experience'.



Look at any hacker console and you won't
find a white screen.  Otherwise its fine.  Fixing that issue is simple,
I can upload my color scheme if anyone wants.


If you want, open an IDLE enhancement issue "IDLE: add alternate 
high-light schemes", select Componemts: IDLE, and attach your 'Console' 
scheme. Many skinnable apps either have a place for users to share their 
custom skins or come with alternatives builtin. There might be other 
emulation schemes worth adding.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #13248: removed deprecated and undocumented difflib.isbjunk, isbpopular.

[Terry Reedy]

On 3/21/2013 2:23 PM, R. David Murray wrote:

On Thu, 21 Mar 2013 01:19:42 -0400, Terry Reedy  wrote:



How does this look? Is ``replacement`` right? Should the subsequent sm
by itself be marked? If so, how?

* :meth:`difflib.SequenceMatcher.isbjunk` and
:meth:`difflib.SequenceMatcher.isbpopular`: use ``x in sm.bjunk`` and
``x in sm.bpopular``, where sm is a SequenceMatcher object.


Looks fine to me.  A link on SequenceMatcher probably isn't necessary,
but might be handy.  If you want to add it it would be
:class:`~difflib.SequenceMatcher`.


Committed and pushed.

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Thomas Wouters]

I expressed this opinion at the sprints (right before I left) in the group
discussion with Guido and Nick, but I'm not sure if it's been represented
in this thread yet (I'm jetlagged and talk about Windows command prompts
depresses me) -- so I'll just rehash it: distributing IDLE in the binary
packages people download from python.org means *python-dev is still
responsible IDLE*. We can't distribute something that we don't support.
Even for the third-party libraries we're wrapping we're taking
responsibility for updating them, fixing specific bugs or working around
the bugs in the wrappers. Removing IDLE from the source tarballs isn't a
way to disown it, or shed responsibility. The benefits of having IDLE in a
separate repository, as I see it, would be that we can have separate access
control for the repositories, and possibly make it more approachable for
new developers, and easier to re-use by other Python implementations. We
couldn't even sensibly stop accepting bugs for it on bugs.python.org.

It may well be that moving IDLE to a separate repository is the right
thing, but only if there's an active team of people working on it that
would prefer it that way. And only if we realize that if IDLE languishes
again, python-dev is *still* on the hook for it, even in the separate
repository. I don't know if excluding it from the source tarball gains us
anything on top of that -- although I do think we should move 'idlelib' out
of the standard library :)

-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] backporting the _sysconfigdata.py module to 2.7

[Thomas Wouters]

On Thu, Mar 21, 2013 at 10:48 PM, Benjamin Peterson wrote:

> 2013/3/21 Matthias Klose :
> > I'd like to backport issue13150, the _sysconfigdata.py module to 2.7. My
> > motivation is not the improved startup time, but the ability to
> cross-build
> > extension modules using distutils/setuptools.  The basic idea is to use
> the
> > python interpreter of the build machine (the machine you build on), and
> the
> > _sysconfigdata.py for the host machine (the machine you build for).
>  This kind
> > of setup works fine as long as the setup.py for a third party package
> gets all
> > build related information from the sysconfig.py module, and not directly
> from os
> > or sys (e.g. sys.platform).
> >
> > The patch for issue13150 doesn't change any API's, but only moves the
> > computation of the config vars from runtime to build time.  I'd like to
> avoid
> > backporting this to 3.2 as well, because the cross-build support is
> currently
> > only found in 2.7, 3.3 and the trunk.
>
> This is a fairly small non-userfacing change, so okay.
>

FWIW, we do the exact same thing in our (internal) Google Python 2.7 builds
(because we're forbidden from having files named 'Makefile' and '*.h' in
our production environment -- and also because of the startup time) and
while we've seen the most obscure, internal changes cause failures in the
most unexpected ways, we haven't seen anything broken or failing in any way
by that change. (Not that I was expecting it, I'm just saying even I think
this is a good idea ;)

-- 
Thomas Wouters 

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Mark Janssen]

On Thu, Mar 21, 2013 at 2:31 PM, Oleg Broytman  wrote:

> On Thu, Mar 21, 2013 at 02:19:33PM -0700, Mark Janssen <
> dreamingforw...@gmail.com> wrote:
> > The *only* thing I find "ugly" about it is that it doesn't have a
> > white-on-black color scheme.  Look at any hacker console and you won't
> find
> > a white screen.
>
>Call me a bad hacker or not hacker at all -- I hate black
> backgrounds. My windows are always black-on-lightgrey, sometimes on dark
> grey, never black. I have been spending 16 hours a day at the screen for
> last 25 years -- and never understood black background.


Lol, funny.  It takes energy to display a phosphor, but none for black.  So
I don't know how it could be harder for the eyes.  Plus, it's "hacker
nostalgia" for me, going back to assembler and BASIC on an Apple II.  But I
think this thread discussion happened decades ago.

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] backporting the _sysconfigdata.py module to 2.7

[Benjamin Peterson]

2013/3/21 Matthias Klose :
> I'd like to backport issue13150, the _sysconfigdata.py module to 2.7. My
> motivation is not the improved startup time, but the ability to cross-build
> extension modules using distutils/setuptools.  The basic idea is to use the
> python interpreter of the build machine (the machine you build on), and the
> _sysconfigdata.py for the host machine (the machine you build for).  This kind
> of setup works fine as long as the setup.py for a third party package gets all
> build related information from the sysconfig.py module, and not directly from 
> os
> or sys (e.g. sys.platform).
>
> The patch for issue13150 doesn't change any API's, but only moves the
> computation of the config vars from runtime to build time.  I'd like to avoid
> backporting this to 3.2 as well, because the cross-build support is currently
> only found in 2.7, 3.3 and the trunk.

This is a fairly small non-userfacing change, so okay.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Oleg Broytman]

On Thu, Mar 21, 2013 at 02:19:33PM -0700, Mark Janssen 
 wrote:
> The *only* thing I find "ugly" about it is that it doesn't have a
> white-on-black color scheme.  Look at any hacker console and you won't find
> a white screen.

   Call me a bad hacker or not hacker at all -- I hate black
backgrounds. My windows are always black-on-lightgrey, sometimes on dark
grey, never black. I have been spending 16 hours a day at the screen for
last 25 years -- and never understood black background.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Mark Janssen]

On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy  wrote:

> On 3/20/2013 12:41 PM, Eli Bendersky wrote:
>
>  Personally, I think that IDLE reflects badly on Python in more ways than
>> one. It's badly maintained, quirky and ugly.
>>
>
> Ugly is subjective: by what standard and compared to what?
>

I might be jumping in late here, but...

The *only* thing I find "ugly" about it is that it doesn't have a
white-on-black color scheme.  Look at any hacker console and you won't find
a white screen.  Otherwise its fine.  Fixing that issue is simple, I can
upload my color scheme if anyone wants.

> It serves a very narrow set of uses,
>
> IDLE serves a very important "narrow use" purpose -- helping the plethora
of beginning programmers.  Anyone who wants to criticize it can slap
themselves.  Python attracts many beginners, and if you don't remember,
installing a separate "fancy" editor was never on the priority list until
several years later.  Give me a break.


> > and does it badly.
>
> Come on.  It gets even a strong programmer 80% of the way to what he/she
needs.

And in any case, I think the interpreter environment is the place to keep
the programmer's focus.  That is the arena where the community has been and
it's what has kept programming in Python fun.  And although this goes
against decades(?) of programming history, the future of programming, is
not in the editor.  The "editor-centric paradigm" has not created a
community of re-usable code, despite all the promises.

I'll argue that the *interpreter environment* will be the future and the
editor will be relegated to a simple memory-saving device.

Mark
Tacoma, Washington
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Georg Brandl]

Am 21.03.2013 19:13, schrieb Antoine Pitrou:
> On Wed, 20 Mar 2013 19:57:54 -0700
> Raymond Hettinger  wrote:
>> 
>> On Mar 20, 2013, at 12:38 PM, Barry Warsaw  wrote:
>> 
>> > Right.  Ultimately, I think IDLE should be a separate project entirely, 
>> > but I
>> > guess there's push back against that too.
>> 
>> The most important feature of IDLE is that it ships with the standard 
>> library.
>> Everyone who clicks on the Windows MSI on the python.org webpage
>> automatically has IDLE.   That is why I frequently teach Python with IDLE.
>> 
>> If this thread results in IDLE being ripped out of the standard distribution,
>> then I would likely never use it again.
> 
> Which says a lot about its usefulness, if the only reason you use it is
> that it's bundled with the standard distribution.

Just like a lot of the stdlib, it *gets* a lot of usefulness from being a
battery.  But just because there are better/more comprehensive/prettier
replacements out there is not reason enough to remove standard libraries.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] backporting the _sysconfigdata.py module to 2.7

[Matthias Klose]

I'd like to backport issue13150, the _sysconfigdata.py module to 2.7. My
motivation is not the improved startup time, but the ability to cross-build
extension modules using distutils/setuptools.  The basic idea is to use the
python interpreter of the build machine (the machine you build on), and the
_sysconfigdata.py for the host machine (the machine you build for).  This kind
of setup works fine as long as the setup.py for a third party package gets all
build related information from the sysconfig.py module, and not directly from os
or sys (e.g. sys.platform).

The patch for issue13150 doesn't change any API's, but only moves the
computation of the config vars from runtime to build time.  I'd like to avoid
backporting this to 3.2 as well, because the cross-build support is currently
only found in 2.7, 3.3 and the trunk.

  Matthias
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #13248: removed deprecated and undocumented difflib.isbjunk, isbpopular.

[R. David Murray]

On Thu, 21 Mar 2013 01:19:42 -0400, Terry Reedy  wrote:
> On 3/20/2013 2:13 PM, R. David Murray wrote:
> > On Wed, 20 Mar 2013 05:23:43 -0700, Eli Bendersky  wrote:
> >> A mention in Misc/NEWS can't hurt here, Terry. Even though it's
> >> undocumented, some old code could rely on it being there and this code will
> >> break with the transition to 3.4
> 
> Will do.
> 
> > Note that we also have a list of deprecated things that were removed in
> > What's New.
> >
> > Aside: given the 3.3 experience, I think people should be thinking in
> > terms of always updating What's New when appropriate, at the time a
> > commit is made.
> 
> How does this look? Is ``replacement`` right? Should the subsequent sm 
> by itself be marked? If so, how?
> 
> * :meth:`difflib.SequenceMatcher.isbjunk` and
>:meth:`difflib.SequenceMatcher.isbpopular`: use ``x in sm.bjunk`` and
>``x in sm.bpopular``, where sm is a SequenceMatcher object.

Looks fine to me.  A link on SequenceMatcher probably isn't necessary,
but might be handy.  If you want to add it it would be
:class:`~difflib.SequenceMatcher`.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Antoine Pitrou]

On Wed, 20 Mar 2013 19:57:54 -0700
Raymond Hettinger  wrote:
> 
> On Mar 20, 2013, at 12:38 PM, Barry Warsaw  wrote:
> 
> > Right.  Ultimately, I think IDLE should be a separate project entirely, but 
> > I
> > guess there's push back against that too.
> 
> The most important feature of IDLE is that it ships with the standard library.
> Everyone who clicks on the Windows MSI on the python.org webpage
> automatically has IDLE.   That is why I frequently teach Python with IDLE.
> 
> If this thread results in IDLE being ripped out of the standard distribution,
> then I would likely never use it again.

Which says a lot about its usefulness, if the only reason you use it is
that it's bundled with the standard distribution.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Federated repo model [was: IDLE in the stdlib]

[fwierzbi...@gmail.com]

On Thu, Mar 21, 2013 at 8:23 AM, Nick Coghlan  wrote:
> I think a federated repo model in general is something we need to
> consider, it's not something we should consider IDLE specific.
I would love to have a federated repo model. I have recently made the
attempt to port the devguide for CPython to Jython with some
reasonable success. Part of that success has come because the devguide
is in its own repo and so forking it and continuing to merge
improvements from the original has been very easy.

I'd love to be able to do the same for the Doc/ directory at the root
of the CPython repo, but currently would have to fork the entire code
and doc repository etc. This would mean that merging the Doc/
improvements would be a big pain, with lots and lots of useless merges
where it would be hard to pick out the Doc changes.

To a lesser extent the same would hold for the Lib/ area - though in
that case I don't mind just pushing our changes to the CPython Lib/
(through the tracker and with code reviews of course) in the medium
term. Still, a separate repo for Lib would definitely be nice down the
road.

-Frank
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Georg Brandl]

Am 21.03.2013 16:23, schrieb Nick Coghlan:
> On Thu, Mar 21, 2013 at 6:22 AM, Barry Warsaw  wrote:
>> On Mar 21, 2013, at 05:25 AM, Eli Bendersky wrote:
>>
>>>1. Whether IDLE should be developed separately from the core Python
>>>repository (while still being shipped).
>>>
>>>I really want to constructively focus on (1).
>>
>> In fact, solving (1) should help move along the discussions about separating
>> the stdlib into a separate repo, for the benefit of alternative
>> implementations.  Agreed that there are many other issues to resolve in that
>> latter discussion.
>>
>> But I think Eli is right that we should be thinking about how to develop code
>> in separate repos and still ship a combined release.
> 
> I think a federated repo model in general is something we need to
> consider, it's not something we should consider IDLE specific.

Right.  Without a coordinated plan this will go the road of elementtree or
simplejson.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How to fix the incorrect shared library extension on linux for 3.2 and newer?

[Georg Brandl]

Am 20.03.2013 22:36, schrieb Barry Warsaw:
> On Mar 20, 2013, at 01:18 PM, Matthias Klose wrote:
> 
>>The patch in the issue now makes a distinction between EXT_SUFFIX and
>>SHLIB_SUFFIX, and restores the value of SO to SHLIB_SUFFIX.  Now this could
>>break users of sysconfig.get_config_var('SO'), however I don't see a better
>>way than to restore the original behaviour and advise people to use the new
>>config variables.

I agree. This looks like a seriously broken behavior to me.

> It should probably be considered a bug that we changed the meaning of SO in
> PEP 3149, but I don't think anybody realized it was being used for both
> purposes (otherwise I'm sure we wouldn't have done it that way).  I suppose
> Georg should make the final determination for 3.2 and 3.3, but the solution
> you propose seems about the best you can do.
>
> As we discussed at Pycon, you'll post a diff to the PEP in the tracker issue
> and I'll commit that when I figure out the best way to indicate that a PEP has
> been updated post-Final status.

Sounds good.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slides from today's parallel/async Python talk

[Trent Nelson]

That's good to hear :-)

(It's a fantastic facility, I couldn't imagine having to go back to manual TLS 
API stuff after using __thread/__declspec(thread).)

This e-mail was sent from a wireless device.

On 21 Mar 2013, at 09:30, "Baptiste Lepilleur" 
mailto:baptiste.lepill...@gmail.com>> wrote:



2013/3/15 Trent Nelson mailto:tr...@snakebite.org>>
On Thu, Mar 14, 2013 at 03:50:27PM -0700, "Martin v. Löwis" wrote:
> Am 14.03.13 12:59, schrieb Stefan Ring:
> > I think you should be able to just take the address of a static
> > __thread variable to achieve the same thing in a more portable way.
>
> That assumes that the compiler supports __thread variables, which
> isn't that portable in the first place.

FWIW, I make extensive use of __declspec(thread).  I'm aware of GCC
and Clang's __thread alternative.  No idea what IBM xlC, Sun Studio
and others offer, if anything.

IBM xlC and Sun Studio also support this feature. From memory, it's also 
__thread keyword. This features is also supported by the new C11/C++11 
standards.

Baptiste.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 405 (venv) - why does it copy the DLLs on Windows

[Paul Moore]

PEP 405 has this note:

"""
On Windows, it is necessary to also copy or symlink DLLs and pyd files
from compiled stdlib modules into the env, because if the venv is
created from a non-system-wide Python installation, Windows won't be
able to find the Python installation's copies of those files when
Python is run from the venv.
"""

I don't understand what this is saying - can someone clarify the
reason behind this statement? What is different about a
"non-system-wide installation" that causes this issue (I assume
"non-system-wide" means "not All Users")? The reason I ask is that
virtualenv doesn't do this, and I'm not clear if this is because of a
potential bug lurking in virtualenv (in which case, I'd like to find
out how to reproduce it) or because virtualenv takes a different
approach which avoids this issue somehow.

Thanks,
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slides from today's parallel/async Python talk

[Baptiste Lepilleur]

2013/3/15 Trent Nelson 

> On Thu, Mar 14, 2013 at 03:50:27PM -0700, "Martin v. Löwis" wrote:
> > Am 14.03.13 12:59, schrieb Stefan Ring:
> > > I think you should be able to just take the address of a static
> > > __thread variable to achieve the same thing in a more portable way.
> >
> > That assumes that the compiler supports __thread variables, which
> > isn't that portable in the first place.
>
> FWIW, I make extensive use of __declspec(thread).  I'm aware of GCC
> and Clang's __thread alternative.  No idea what IBM xlC, Sun Studio
> and others offer, if anything.
>

IBM xlC and Sun Studio also support this feature. From memory, it's also
__thread keyword. This features is also supported by the new C11/C++11
standards.

Baptiste.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Nick Coghlan]

On Thu, Mar 21, 2013 at 6:22 AM, Barry Warsaw  wrote:
> On Mar 21, 2013, at 05:25 AM, Eli Bendersky wrote:
>
>>1. Whether IDLE should be developed separately from the core Python
>>repository (while still being shipped).
>>
>>I really want to constructively focus on (1).
>
> In fact, solving (1) should help move along the discussions about separating
> the stdlib into a separate repo, for the benefit of alternative
> implementations.  Agreed that there are many other issues to resolve in that
> latter discussion.
>
> But I think Eli is right that we should be thinking about how to develop code
> in separate repos and still ship a combined release.

I think a federated repo model in general is something we need to
consider, it's not something we should consider IDLE specific.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Nick Coghlan]

On Thu, Mar 21, 2013 at 5:26 AM, Daniel Holth  wrote:
> I showed IDLE to my 6-year-old on the Raspberry Pi and I'm convinced
> it is cool. Gave up on trying to (slowly) install bpython. We were
> multiplying large numbers and counting to 325,000 in no time. It might
> not be for *me* but I'm not going to teach my daughter a large IDE any
> time soon.

This, 1000x this.

It was helping out at the Young Coders tutorials that convinced me we
need to continue shipping IDLE, or something like it, for use by
*people learning to use computers as more than just passive consumers
for the first time*. This means running well on Windows and the
Raspberry Pi at this point.

Keeping IDLE in the core represents a commitment to the use of Python
as a teaching language both inside and outside of formal educational
settings.

We can refactor IDLE to make aspects of it easier to test with the
buildbots, especially now that we have unittest.mock in the standard
library to mock out some of the UI interaction in the test suite. (I'm
happy to help coach the IDLE devs on that if they want to start
improving the test suite coverage for the IDLE code)

I think we should commit to making "start with IDLE" the recommended
teaching experience, and then focus on *making that experience
awesome*. Once people are already familiar with the language and what
it can do for them, they may choose to move on to other tools, or they
may decide to stick with IDLE. But deciding on "What is IDLE?" and
"Why is it part of the CPython development repo?" is a necessary step
to revitalising it and stopping the recurring discussions about taking
it out.

If Terry is willing to recast his PEP in that light, I think that
would be a wonderful thing to do.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Barry Warsaw]

On Mar 21, 2013, at 05:25 AM, Eli Bendersky wrote:

>1. Whether IDLE should be developed separately from the core Python
>repository (while still being shipped).
>
>I really want to constructively focus on (1).

In fact, solving (1) should help move along the discussions about separating
the stdlib into a separate repo, for the benefit of alternative
implementations.  Agreed that there are many other issues to resolve in that
latter discussion.

But I think Eli is right that we should be thinking about how to develop code
in separate repos and still ship a combined release.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Chris Angelico]

On Fri, Mar 22, 2013 at 12:18 AM, Stephen J. Turnbull
 wrote:
> Paul Moore writes:
>
>  > I have no figures one way or the other on that. You may well be
>  > right.  Are we aiming at "all Windows users" here?
>
> We need to be careful about this.  ISTM that IDLE is aiming at the
> subset of users on any platform who for some reason need/want a simple
> development environment that is consistent across Python versions and
> platforms and immediately available when they install Python, but
> don't have one yet.

When I'm on Windows, I use IDLE as my interactive interpreter, but
SciTE for actual development. Even on Linux, there's one feature that
CLI interactive mode lacks: multi-line command recall. To tinker with
a function definition in IDLE, just recall it and edit it. To tinker
with it in command-line Python, fetch back each of its lines, or edit
it elsewhere and paste it. IDLE isn't a program editor for me, it's
the face of Python.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Stephen J. Turnbull]

Paul Moore writes:

 > I have no figures one way or the other on that. You may well be
 > right.  Are we aiming at "all Windows users" here?

We need to be careful about this.  ISTM that IDLE is aiming at the
subset of users on any platform who for some reason need/want a simple
development environment that is consistent across Python versions and
platforms and immediately available when they install Python, but
don't have one yet.

I think that there's been sufficient testimony to demonstrate that
there are a fair number of folks in that boat.  Educators (acting as
proxies for a couple of orders of magnitude more students) are one
identifiable group.  Beginning Python users on Windows who don't use
English in their daily lives and therefore need an environment that
deals with the nightmare of "code pages" and "POSIX locales" are
another.

 > My experience may well be atypical, I can't say.

I suppose it is reasonably typical.  I'm sure everybody (by now,
including Guido!)  have many parts of the stdlib they just never need
to use, nor does anybody around them.  Most of us rarely to never want
IDLE.  That's not the point.

The "batteries included" slogan is inaccurate in the sense that
everybody needs batteries or their toys won't run.  The batteries that
slogan refers to aren't for everyone, rather the hope is that there
are enough different batteries in the kit that everyone can get
started.  They can always get Twisted later.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slides from today's parallel/async Python talk

[Antoine Pitrou]

Le Thu, 14 Mar 2013 15:23:37 -0700,
Trent Nelson  a écrit :
> 
> Don't get me wrong, I grew up with UNIX and love it as much as the
> next guy, but you can't deny the usefulness of Windows' facilities
> for writing high-performance, multi-threaded IO code.  It's
> decades ahead of POSIX.

I suppose that's why all high-performance servers run under Windows.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slides from today's parallel/async Python talk

[Sturla Molden]

Den 14. mars 2013 kl. 23:23 skrev Trent Nelson :

> 
>For the record, here are all the Windows calls I'm using that have
>no *direct* POSIX equivalent:
> 
>Interlocked singly-linked lists:
>- InitializeSListHead()
>- InterlockedFlushSList()
>- QueryDepthSList()
>- InterlockedPushEntrySList()
>- InterlockedPushListSList()
>- InterlockedPopEntrySlist()
> 
>Synchronisation and concurrency primitives:
>- Critical sections
>- InitializeCriticalSectionAndSpinCount()
>- EnterCriticalSection()
>- LeaveCriticalSection()
>- TryEnterCriticalSection()
>- Slim read/writer locks (some pthread implements have
>  rwlocks)*:
>- InitializeSRWLock()
>- AcquireSRWLockShared()
>- AcquireSRWLockExclusive()
>- ReleaseSRWLockShared()
>- ReleaseSRWLockExclusive()
>- TryAcquireSRWLockExclusive()
>- TryAcquireSRWLockShared()
>- One-time initialization:
>- InitOnceBeginInitialize()
>- InitOnceComplete()
>- Generic event, signalling and wait facilities:
>- CreateEvent()
>- SetEvent()
>- WaitForSingleObject()
>- WaitForMultipleObjects()
>- SignalObjectAndWait()
> 
>Native thread pool facilities:
>- TrySubmitThreadpoolCallback()
>- StartThreadpoolIo()
>- CloseThreadpoolIo()
>- CancelThreadpoolIo()
>- DisassociateCurrentThreadFromCallback()
>- CallbackMayRunLong()
>- CreateThreadpoolWait()
>- SetThreadpoolWait()
> 
>Memory management:
>- HeapCreate()
>- HeapAlloc()
>- HeapDestroy()
> 
>Structured Exception Handling (#ifdef Py_DEBUG):
>- __try/__except
> 
>Sockets:
>- ConnectEx()
>- AcceptEx()
>- WSAEventSelect(FD_ACCEPT)
>- DisconnectEx(TF_REUSE_SOCKET)
>- Overlapped WSASend()
>- Overlapped WSARecv()
> 
> 
>Don't get me wrong, I grew up with UNIX and love it as much as the
>next guy, but you can't deny the usefulness of Windows' facilities
>for writing high-performance, multi-threaded IO code.  It's decades
>ahead of POSIX.  (Which is also why it bugs me when I see select()
>being used on Windows, or IOCP being used as if it were a poll-type
>"generic IO multiplexor" -- that's like having a Ferrari and speed
>limiting it to 5mph!)
> 
>So, before any of this has a chance of working on Linux/BSD, a lot
>more scaffolding will need to be written to provide the things we
>get for free on Windows (threadpools being the biggest freebie).
> 
> 
> 


Have you considered using OpenMP instead of Windows API or POSIX threads 
directly? OpenMP gives you a thread pool and synchronization primitives for 
free as well, with no special code needed for Windows or POSIX. 

OpenBLAS (and GotoBLAS2) uses OpenMP to produce a thread pool on POSIX systems 
(and actually Windows API on Windows). The OpenMP portion of the C code is 
wrapped so it looks like sending an asynch task to a thread pool; the C code is 
not littered with OpenMP pragmas. If you need something like Windows 
threadpools on POSIX, just look at the BSD licensed OpenBLAS code. It is 
written to be scalable for the world's largest supercomputers (but also 
beautifully written and very easy to read).

Cython has code to register OpenMP threads as Python threads, in case that is 
needed. So that problem is also solved.


Sturla








___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/20/2013 12:41 PM, Eli Bendersky wrote:

Interesting writeup about PyCon 2013 young coder
education:http://therealkatie.net/blog/2013/mar/19/pycon-2013-young-coders/

Quote:

"We used IDLE because it's already on Raspian's desktop. Personally, I
like IDLE as a teaching tool. It's included in the standard library, it
does tab completion and color coding, and it even has a text editor
included so you don't have to start your class off by teaching everyone
about paths.

Too bad it's broke as hell."


A typical blog exaggeration, which is not a good basis for serious 
decision making. He continued "I believe my first contribution to the 
Python Standard Library will be fixes to IDLE. I really do like it that 
much. "


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Daniel Holth]

I showed IDLE to my 6-year-old on the Raspberry Pi and I'm convinced
it is cool. Gave up on trying to (slowly) install bpython. We were
multiplying large numbers and counting to 325,000 in no time. It might
not be for *me* but I'm not going to teach my daughter a large IDE any
time soon.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Eli Bendersky]

On Wed, Mar 20, 2013 at 11:42 PM, Terry Reedy  wrote:

> On 3/20/2013 11:54 PM, Eli Bendersky wrote:
>
>> On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy >
>
>  Ugly is subjective: by what standard and compared to what?
>>
>> Compared to other existing Python IDEs and shells which are layered on
>> top of modern GUI toolkits that are actively developed to keep with
>> modern standards, unlike Tk which is frozen in the 1990s.
>>
>
> I think being frozen in the late 1990s is better than being frozen in the
> early 1980s, like Command Prompt is. In fact, I think we should 'deprecate'
> the Command Prompt interpreter as the standard interactive interpreter and
> finish polishing and de-glitching IDLE's Python Shell, which runs on top of
> the windowless version of CP with a true GUI. Then we can promote and
> present the latter as the preferred interface, which for many people, it
> already is.


There are two discussions being held in parallel here:

1. Whether IDLE should be developed separately from the core Python
repository (while still being shipped).
2. Whether IDLE is bad in a general sense and should die.

I've stated several times now that it's (1) that I'm interested in. (2) is
too subjective, and frankly I'm not in a good position to argue from an
objective point of view. As Antoine mentioned, "feeling" should not be
dismissed (especially if it resonates from a number of developers). That
said, I'm not going to continue to talk about (2). I really want to
constructively focus on (1).

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Eli Bendersky]

> > On Mar 20, 2013, at 12:38 PM, Barry Warsaw  > > wrote:
> >
> >> Right.  Ultimately, I think IDLE should be a separate project
> entirely, but I
> >> guess there's push back against that too.
> >
> > The most important feature of IDLE is that it ships with the
> standard library.
> > Everyone who clicks on the Windows MSI on the python.org <
> http://python.org>
> > webpage
> > automatically has IDLE.   That is why I frequently teach Python with
> IDLE.
> >
> > If this thread results in IDLE being ripped out of the standard
> distribution,
> > then I would likely never use it again.
> >
> >
> > Why is it necessary to conflate distribution and development. "standard
> library"
> > != "Python distribution".
>
> Because that's how CPython defines its distribution.  We distribute things
> that
> are in the CPython/standard library repo, and nothing else.
>

Yes, I realize this is the case. I was wondering whether it's hard to
change.


>
> > Take the ActivePython distribution for example. They ship with extra
> packages
> > for Windows (pywin32, etc) and our Python installer doesn't. This is a
> reason
> > many Windows people prefer ActivePython. That's their right, but this
> preference
> > is not the point. The point is that it's perfectly conceivable to ship
> IDLE with
> > Python releases on Windows, while managing it as a separate project
> outside the
> > CPython core Mercurial repository.
>
> And what's the benefit?  I just don't see it.  It just makes it harder to
> create
> a Python release.
>
>
This is the feedback I was looking for. If this will make Python
distribution non-trivially harder, then it's a point against the proposal.


> > This seems to me to combine benefits from both worlds:
> >
> > 1. IDLE keeps being shipped to end users. I have to admit the reasons
> made in
> > favor of this in the thread so far are convincing.
> > 2. IDLE is developed as a standalone project. As such, it's much easier
> to
> > contribute to, which will hopefully result in a quicker pace of
> improvement.
>
> Why?  You won't magically gather more people that are interested in IDLE
> development.
>

But that's the point - If there are not enough people interested in it, it
should then die. Right now it's a burden of Python core developers to keep
it functional even if no one else cares (and if anything, the low amount of
open issues Terry quoted elsewhere may be a sign that indeed not many care).


>
> > The
> > only demand is that it keeps working with a release version of Python,
> and this
> > is pretty easy. It's even possible and easy to have a single IDLE
> version for
> > Python 3.x instead of contributors having to propose patches for 3.2,
> 3.3 and
> > 3.4 simultaneously.
>
> They don't anyway.
>


But we know perfectly well that a core dev is expected to backport
reasonably. In an outside repo, it can have a single-code base. It's not
hard to avoid the new features of 3.3 and 3.4 and be compatible with all
active Python 3 versions. Note that even if the same is done in our
Mercurial repo, each commit still needs to be triplicated in the push dance.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/21/2013 5:20 AM, Antoine Pitrou wrote:

Le Thu, 21 Mar 2013 02:42:33 -0400,
Terry Reedy  a écrit :

On 3/20/2013 11:54 PM, Eli Bendersky wrote:

On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy 


 Ugly is subjective: by what standard and compared to what?

Compared to other existing Python IDEs and shells which are layered
on top of modern GUI toolkits that are actively developed to keep
with modern standards, unlike Tk which is frozen in the 1990s.


I think being frozen in the late 1990s is better than being frozen in
the early 1980s, like Command Prompt is.  In fact, I think we should
'deprecate' the Command Prompt interpreter as the standard
interactive interpreter and finish polishing and de-glitching IDLE's
Python Shell, which runs on top of the windowless version of CP with
a true GUI.


And this may indeed be reasonable under Windows, where the command-line
is a PITA!


Which is the only context I was talking about.


But the Linux command-line is actually quite very usable
these days, especially if you configure your Python interpreter to use
readline for tab-completion of identifiers (which should be done by
default, see http://bugs.python.org/issue5845).


IDLE has tab-completion for both identifiers and attributes, in both 
shell and editor windows. It is probably under-documented; I am still 
learning to use it effectively. I am curious if the readline version 
works better in any way that IDLE could imitate.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/21/2013 5:41 AM, Paul Moore wrote:

On 21 March 2013 06:54, Devin Jeanpierre  wrote:

On Thu, Mar 21, 2013 at 2:42 AM, Terry Reedy  wrote:

I think being frozen in the late 1990s is better than being frozen in the
early 1980s, like Command Prompt is. In fact, I think we should 'deprecate'
the Command Prompt interpreter as the standard interactive interpreter and
finish polishing and de-glitching IDLE's Python Shell, which runs on top of
the windowless version of CP with a true GUI. Then we can promote and
present the latter as the preferred interface, which for many people, it
already is.


I should have prefaced that with 'on Windows'. I presume the command 
line on *nix is better with most of the issues I discussed than on Windows.



Please don't cease supporting the command line interface.


My one person opinion and counter-proposal is not going to change 
anything. Anyway, my two points were this: if late 1990s is bad, isn't 
early 1980s worse? And *if* we are going to one downplay/demote of the 
two interactive shells, should not it be the worse one?


>> I use the

command line interactive interpreter plenty. That way I can use git,
grep, the unit test suite, etc. ... and the interactive interpreter,
all from one place: the console.

That can't happen with IDLE, by design.


It is Microsoft, not me, that is a threat to Command Prompt. I have the 
impression that it is not part of the Win 8 not-Metro tablet interface 
that they would like everyone to use even on the desktop. To push 
beginners away from the desktop to the pane interface, they were 
initially going to limit the free Visual Express IDE and compilers to 
the new interface.


You can use idle from the command line almost as easily as the CP 
interpreter: 'python -m idlelib' instead of just 'python' (I just tried 
it to verify). Unlike bare 'python', IDLE includes a grep. Right click 
on any 'hit' and it opens the file at the specified line. Unlike bare 
'python', you can run tests and collect the all the output, from as many 
tests as you want, in a dynamically right-sized buffer.



Agreed. Command line Python is 100% of my usage, and removing it would
make Python unusable for me.


Whereas others would say the same about removing IDLE.


If what is being suggested is removing the "Python Command Line"
*shortcuts*


I did not suggest that.


those shortcuts (and if I did, I could set them up myself). But before
removing them, why not consider setting the defaults to be more
helpful (larger scrollback buffer, things like quick edit set on, etc)
if that's the real issue here? I'm not saying it is, but some of the
complaints about "the default experience" *can* be fixed simply by
changing the defaults.


If that is so easily possible, then it should have been done already.

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Paul Moore]

On 21 March 2013 10:32, Terry Reedy  wrote:
> On 3/21/2013 5:27 AM, Paul Moore wrote:
>
>> Can I suggest that debates about the capability of Windows command
>> line programming are off-topic here?
>
>
> I respectfully disagree, unless you say that the whole thread is off topic.
> If it is okay for people to say that IDLE, including the IDLE interactive
> interpreter shell is ugly, quirky, broken, badly maintained, and
> disfunctional, without giving hardly any facts or details to back up or
> explain the claims, and then claim it is so bad that it should be banished,
> then to me it is perfectly on topic for me to point out that the
> alternative, the CP shell, is objectively far worse in multiple respects.
> Yes, I gave some facts for the benefit of those who were willing to consider
> my claim that IDLE is better.

I agree entirely that unsubstantiated claims of "it's dreadful" are
just as unacceptable when referring to IDLE. And I'm happy to accept
that you find IDLE better - although I'd take issue with a claim that
it's objectively better for everyone. I'd rather that we focus on
dealing with genuine issues as reported by users (e.g., the comments
from people working with IDLE in training courses).

One difference, though, is that the quality of IDLE is within our
control, so comments about how it can be improved are valid - whereas
comments about the Windows console are simply statements of a reality
we have no means of addressing.

>> it is what Windows users who use the command line are used to.
>
> I bet that 'Windows users who use the command line' are less than 10% of
> Windows users.

I have no figures one way or the other on that. You may well be right.
Are we aiming at "all Windows users" here? All I can say is that my
experience (in a corporate Windows-based environment) is that people
who have any interest in learning or using Python are nearly always
*also* command line users, and comfortable with it. They are often
looking at Python as a step up from Windows batch files - and that is
such a huge improvement that trivia like the way you select text in
the console are completely irrelevant by comparison. My experience may
well be atypical, I can't say.

> I am willing to accept that you find it adequate. Why can't you accept that
> I find it wretched, especially when I explained some of why rather than just
> throwing it out as an opinion, and consider IDLE to be wonderfully better?

I'm happy to accept that. What I don't know (no criticism here, but
it's something I mentioned at the start of my post) is whether you use
Windows as your main platform, and so what you're implying in terms of
how to generalise the fact that you prefer IDLE (I assume you want me
to generalise, and not just take your comments as a statement of your
personal preference). Much of the comments about the Windows
experience *seem to me* to come from Unix users who only occasionally
use Windows and find the experience unpleasant. A bit more clarity as
to where the people advocating particular actions are coming from
would help (because I, and possibly others, may be wrong in that
impression).

Anyway, I was the one who claimed things were getting off-topic, so
I'll stop at this point. I hope I haven't offended anyone - I didn't
mean to.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/21/2013 5:27 AM, Paul Moore wrote:


Can I suggest that debates about the capability of Windows command
line programming are off-topic here?


I respectfully disagree, unless you say that the whole thread is off 
topic. If it is okay for people to say that IDLE, including the IDLE 
interactive interpreter shell is ugly, quirky, broken, badly maintained, 
and disfunctional, without giving hardly any facts or details to back up 
or explain the claims, and then claim it is so bad that it should be 
banished, then to me it is perfectly on topic for me to point out that 
the alternative, the CP shell, is objectively far worse in multiple 
respects. Yes, I gave some facts for the benefit of those who were 
willing to consider my claim that IDLE is better.



it is what Windows users who use the command line are used to.


I bet that 'Windows users who use the command line' are less than 10% of 
Windows users.


I am willing to accept that you find it adequate. Why can't you accept 
that I find it wretched, especially when I explained some of why rather 
than just throwing it out as an opinion, and consider IDLE to be 
wonderfully better?


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Joao S. O. Bueno]

On 20 March 2013 23:53, Steven D'Aprano  wrote:
> I also note that in the last few weeks, I've seen at least two instances
> that I recall of a beginner on the tu...@python.org mailing list being
> utterly confused by Python's Unicode handling because the Windows command
> prompt is unable to print Unicode strings.

It can be worst than that - in i18nes Windows installs, the DOS Prompt sometimes
have a different encoding than the Windows running -  for example, for
pt_BR Windows, all UI apps run using latin1, but the CP uses a CP850 encoding
which generates _different_ characters for the same codes.

As someone who form times to times lecture a introductory workshop of
Python to people running Windows, I second Terry's long message - and
I highlight
Raymond's """ Without IDLE, a shocking number of people would
create Python files using notepad. """


   js
  -><-
>
>
> Thanks Terry.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A 'common' respository? (was Re: IDLE in the stdlib)

[Terry Reedy]

On 3/21/2013 2:06 AM, Philip James wrote:

I hope I'm not coming across as pedantic, because I think you have some
good arguments listed above, but shouldn't discussion like this go in
python-ideas rather than python-dev?


Normally yes. But since this is a counter-proposal or an alternate 
proposal to proposals already made in this thread, it belongs as an 
offshoot of this thread. This thread in turn is a continuation of 
similar threads here in the past, and involves some people who are less 
active in python-ideas. Also, it is more about technical development 
matters than about future *language* changes.


> I'm very new to these lists, so

forgive me if I'm stepping on any toes, I'm just trying to grok what
kind of content should go in each list.


You are not stepping on my toes, and that is a good question to think about.

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Paul Moore]

On 21 March 2013 06:54, Devin Jeanpierre  wrote:
> On Thu, Mar 21, 2013 at 2:42 AM, Terry Reedy  wrote:
>> I think being frozen in the late 1990s is better than being frozen in the
>> early 1980s, like Command Prompt is. In fact, I think we should 'deprecate'
>> the Command Prompt interpreter as the standard interactive interpreter and
>> finish polishing and de-glitching IDLE's Python Shell, which runs on top of
>> the windowless version of CP with a true GUI. Then we can promote and
>> present the latter as the preferred interface, which for many people, it
>> already is.
>
> Please don't cease supporting the command line interface. I use the
> command line interactive interpreter plenty. That way I can use git,
> grep, the unit test suite, etc. ... and the interactive interpreter,
> all from one place: the console.
>
> That can't happen with IDLE, by design.

Agreed. Command line Python is 100% of my usage, and removing it would
make Python unusable for me.

If what is being suggested is removing the "Python Command Line"
*shortcuts* that are installed by default, but leaving the console
"python.exe" program, then I have no view on that, as I don't use
those shortcuts (and if I did, I could set them up myself). But before
removing them, why not consider setting the defaults to be more
helpful (larger scrollback buffer, things like quick edit set on, etc)
if that's the real issue here? I'm not saying it is, but some of the
complaints about "the default experience" *can* be fixed simply by
changing the defaults.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Antoine Pitrou]

Le Wed, 20 Mar 2013 18:48:15 -0400,
"Kurt B. Kaiser"  a écrit :
> 
> IDLE has a single keystroke round trip - it's an IDE, not just an
> editor like Sublime Text or Notepad.  In the 21st century, people
> expect some sort of IDE.  Or, they should!

I don't think I've used an IDE in years (not seriously anyway).
I also don't think beginners "expect some sort of IDE", since they
don't know what it is. They probably don't even expect a text editor at
first.

> I'd also like to make a plea to keep IDLE's interface clean and
> basic. There are lots of complex IDEs available for those who want
> them.  It's natural for developers to add features, that's what they
> do :-), but you don't hand a novice a Ferrari (or emacs) and expect
> good results.

What is the point of an IDE without features?

Also, this is touching another issue: IDLE needs active maintainers,
who will obviously be experienced Python developers. But if they are
experienced Python developers, they will certainly want the additional
features, otherwise's they'll stop using and maintaining IDLE.

In other words, if IDLE were actually usable *and* pleasant for
experienced developers, I'm sure more developers would be motivated
to improve and maintain it.

> It's sometimes said that IDLE is "ugly" or "broken".  These terms are
> subjective!

Subjective statements are not baseless and idiotic. They come from the
experience of people actually wanting to like a piece of software, you
shouldn't discard them at face value.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Paul Moore]

On 21 March 2013 00:38, Neil Hodgson  wrote:
> Terry Reedy:
>
>> Broken (and quirky): it has an absurdly limited output buffer (under a 
>> thousand lines)
>
>The limit is actually  lines.
>
>> Quirky: Windows uses cntl-C to copy selected text to the clipboard and 
>> (where appropriate) cntl-V to insert clipboard text at the cursor pretty 
>> much everywhere.
>
>CP uses Ctrl+C to interrupt programs similar to Unix. Therefore it moves 
> copy to a different key in a similar way to Unix consoles like GNOME Terminal 
> and MATE Terminal which use Shift+Ctrl+C for copy despite Ctrl+C being the 
> standard for other applications.

Can I suggest that debates about the capability of Windows command
line programming are off-topic here? Whether it is good or bad (and in
my view, it is perfectly adequate, and in some ways better than Unix)
it is what Windows users who use the command line are used to. The
experience with Python is *identical* to what people see with other
scripting languages like Perl, Ruby, etc. It's even similar to
something like Java (I know everyone uses something like Eclipse for
Java, but that's a 3rd party download). And there's Python Tools for
Visual Studio if people want a "real Windows IDE"...

If people teaching Python have problems with the current environment
(and I know we've had some very good feedback on that score) then
that's fine, let's address it. But simply saying "Windows users have
no usable command line so they need GUI support" is neither productive
nor true.

(Apologies if this sounds grumpy. I'll go and get my first cup of tea
of the day now...)
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Antoine Pitrou]

Le Thu, 21 Mar 2013 02:42:33 -0400,
Terry Reedy  a écrit :
> On 3/20/2013 11:54 PM, Eli Bendersky wrote:
> > On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy  
> > Ugly is subjective: by what standard and compared to what?
> >
> > Compared to other existing Python IDEs and shells which are layered
> > on top of modern GUI toolkits that are actively developed to keep
> > with modern standards, unlike Tk which is frozen in the 1990s.
> 
> I think being frozen in the late 1990s is better than being frozen in 
> the early 1980s, like Command Prompt is. In fact, I think we should 
> 'deprecate' the Command Prompt interpreter as the standard
> interactive interpreter and finish polishing and de-glitching IDLE's
> Python Shell, which runs on top of the windowless version of CP with
> a true GUI.

And this may indeed be reasonable under Windows, where the command-line
is a PITA! But the Linux command-line is actually quite very usable
these days, especially if you configure your Python interpreter to use
readline for tab-completion of identifiers (which should be done by
default, see http://bugs.python.org/issue5845).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/21/2013 12:32 AM, Kurt B. Kaiser wrote:


Well, spending a lot of time backporting new features is not my idea of
fun. OTOH, I have no objection.


I intentionally did not say in the PEP that it should be mandatory.


Along those lines, I've thought that IDLE should refrain from using the
newest features in Python, to allow people running released versions of
Python to access the newest IDLE.  i.e. Python 3.4 innovations would not
be used in IDLE 3.4.  Only Python 3.3 and earlier innovations.


So far, since 3.0/1, that has been a moot point. 3.2 was syntax frozen. 
3.3 has 'yield from', but I do not know if there is much of anywhere 
that *could* be used, and for simple uses, the old 'for i in it: yield 
i; is good enough.



I don't know if this is the place to comment on PEP 434 (is it?), but
I've always taken the approach that IDLE development should be less
formal than the rest of stdlib, since it's not a dependency.  Big
changes should be reserved for the tip, but I don't see why something
like the right click menu change shouldn't be backported.


Thank you for confirming my impression of your approach. When the right 
click changed was challenged, I claimed that an *informal* relaxed 
approach was the defacto rule. Antoine said that that was not OK and 
Nick agreed and said that a relaxed approach would have to be 
*formalized* in a PEP and approved. Then there would be no (less ;-) 
arguments about IDLE pushes. Todd took the initiative to write a first 
draft and I revised it.



I think we should try a more relaxed idlelib development process inside
core before we move it out, and should be generous about adding checkin
permissions for that purpose.  Rietveld will help.  It's a good way to
habilitate new developers.



I have commented over the years, but lately I've been so distracted by
the Treasurer job that I haven't found much time for IDLE.


So I should be selective in specifically asking for comment.


I've tried to channel Guido over the years.  I looked at what he did,
and tried to project forward.

IDLE-dev is still active.  Would anyone else like to be a moderator?


Yes. I presume that is the one mirrored as gmane.comp.pythong.idle. It 
has been mostly quiet since September. When we have an accepted ground 
rule for making decisions, I expect more discussions. For instance, I 
think it might be the appropriate place to get input from interested 
users about preferred behavior on a specific issue.


http://mail.python.org/mailman/listinfo/idle-dev
is out of date in places.


Without a vision and design document, it is sometimes hard for someone
like me to know which is which.


IDLE development has always been organic, as opposed to the formal
approach of the PEPs.  What we need is a Zen of IDLE.  When I look at
it, I see a simple IDE.  I try to adhere to the principle of least
surprise, and to maintain an uncluttered interface suitable for
beginners.  Expert features can be there, but somewhat hidden (though
they should be documented!) or implemented as disabled extensions.

IDLE tries to promote Pythonic style.  For example, the lack of a
horizontal scroll bar was deliberate, I think.

We should implement the patch that adds an extension selector to the
options dialog, and keep the expert features as disabled extensions.


In all versions, I presume ;-).

I have been wondering if there are any beginner features implemented as 
extensions that should be directly incorporated and planned to ask Roger 
on idle-dev. Anyway, I like that idea as it lets us somewhat have the 
cake of simplicity and also eat the cupcakes of expert features as desired.



That way, an instructor could distribute an idlerc file which would set
IDLE up exactly as desired, including links to course specific help
files on the web.


That would be excellent.


BTW, I'll take this chance to promote the use of idlelib/NEWS.txt for
IDLE news, instead of Misc/NEWS.  That way, if IDLE is used outside of
the main release, the NEWS.txt will go with it.


Thanks for the reminder. That came up here on pydev recently and it was
agreed that IDLE should indeed go in the idlelib/NEWS and that the 
release manager or someone could then *copy* it into Misc/NEWS as a 
separate *** IDLE *** section. Or maybe the idea was vice versa. Either 
was, this would avoid NEWS conficts for IDLE patches (unless multiple 
IDLE developers pushed nearly simultaneously).

http://bugs.python.org/issue17506


Stability is paramount.

No surprises beats cool.

KISS is better than full featured.

Uniform trumps native look.

Experts go to the rear.

Where they can find what they want if they know where to look.

IDLE tests tkinter.


Thanks. I am glad I asked.

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Larry Hastings]

On 03/20/2013 11:34 PM, Georg Brandl wrote:

I don't really understand what Antoine's "quiescently torpid" means,


"quiescent" = "peaceful, quiet, still"
"torpid" = "lethargic, not moving"
"antoine" = "thesaurus owner"


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/21/2013 12:36 AM, Glenn Linderman wrote:

On 3/20/2013 5:15 PM, Terry Reedy wrote:

Broken (and quirky): it has an absurdly limited output buffer (under a
thousand lines)


People keep claiming that Windows CMD has a limited output buffer. It is
configurable, at least to  lines, which is where I have mine set.
That is far too much to actually scroll back through for most practical
purposes, although sometimes I do :)


See my response to the same point by Neil Hodgson, where I noticed that 
setting to  lines somewhat disables easy scrolling. (I checked and 
it was  also on XP.)



I'm not trying to claim that Windows CMD is wonderful, perfect, or has
large numbers of redeeming values, but let's keep to the facts.


Yes, lets do. I tried to. A person who installs Python on Windows and 
runs Python (command prompt) instead of IDLE is confronted with a 300 
line default. Someone not familiar with Command Prompt will not know 
that the limit can be increased. I use CP so seldom, until recently, 
that I had forgotten how to do so. I fiddled with the history buffer 
setting on the first page. That did not work so I gave up.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com