Re: [Python-Dev] cpython: Closes issue 17467. Add readline and readlines support to

[Antoine Pitrou]

On Tue, 19 Mar 2013 21:44:15 -0700
Michael Foord  wrote:
> 
> mock_open makes it easy to put a StringIO in place if that's what you want. 
> It's just a simple helper function for providing some known data *along with 
> the Mock api* to make asserts that it was used correctly. It isn't presenting 
> a full file-system. My suggestion to the implementor of the patch was that 
> read / readline / readlines be disconnected - but the patch provided allows 
> them to be interleaved and I saw no reason to undo that.
> 
> If users want more complex behaviour (like universal newline support) they 
> can use mock_open along with a StringIO.

This is not about complex behaviour but simply correct behaviour.
For the record, universal newlines are enabled by default in Python 3:

>>> with open("foo", "wb") as f: f.write(b"a\r\nb\rc\n")
... 
7
>>> with open("foo", "r") as f: print(list(f))
... 
['a\n', 'b\n', 'c\n']


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] cpython: Closes issue 17467. Add readline and readlines support to

[Michael Foord]

On 20 Mar 2013, at 00:09, Antoine Pitrou  wrote:

> On Tue, 19 Mar 2013 21:44:15 -0700
> Michael Foord  wrote:
>> 
>> mock_open makes it easy to put a StringIO in place if that's what you want. 
>> It's just a simple helper function for providing some known data *along with 
>> the Mock api* to make asserts that it was used correctly. It isn't 
>> presenting a full file-system. My suggestion to the implementor of the patch 
>> was that read / readline / readlines be disconnected - but the patch 
>> provided allows them to be interleaved and I saw no reason to undo that.
>> 
>> If users want more complex behaviour (like universal newline support) they 
>> can use mock_open along with a StringIO.
> 
> This is not about complex behaviour but simply correct behaviour.
> For the record, universal newlines are enabled by default in Python 3:
> 
 with open("foo", "wb") as f: f.write(b"a\r\nb\rc\n")
> ... 
> 7
 with open("foo", "r") as f: print(list(f))
> ... 
> ['a\n', 'b\n', 'c\n']
> 

mock_open is •not• presenting a mock filesystem, but is about providing a mock 
object to avoid •either• reading or writing to the real filesystem. You don't 
•tend• to do both with a single file handle  - I know it's possible but 
mock_open is a convenience function for the common case.

This commit simply adds support for readline and readlines, whereas before only 
read was supported.

If you want to add support for additional functionality feel free to propose a 
patch.

Michael



> 
> 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/fuzzyman%40voidspace.org.uk
___
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: Closes issue 17467. Add readline and readlines support to

[Antoine Pitrou]

On Wed, 20 Mar 2013 00:50:27 -0700
Michael Foord  wrote:
> 
> If you want to add support for additional functionality feel free to propose 
> a patch.

This isn't about additional functionality, this is about
correctness. You don't want to write multiple, slightly different,
implementations of readline() and friends (which is what Python 2 did).

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] cpython: Closes issue 17467. Add readline and readlines support to

[Michael Foord]

On 20 Mar 2013, at 01:03, Antoine Pitrou  wrote:

> On Wed, 20 Mar 2013 00:50:27 -0700
> Michael Foord  wrote:
>> 
>> If you want to add support for additional functionality feel free to propose 
>> a patch.
> 
> This isn't about additional functionality, this is about
> correctness. You don't want to write multiple, slightly different,
> implementations of readline() and friends (which is what Python 2 did).
> 


This change allows you to set a series of return values for readlines when 
mocking open.

We are not reading data from anywhere the user is supplying it pre-canned.

Do you have a specific problem with it? 

Michael

> 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/fuzzyman%40voidspace.org.uk
___
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: Closes issue 17467. Add readline and readlines support to

[Michael Foord]

On 19 Mar 2013, at 23:09, "Gregory P. Smith"  wrote:

> 
> On Tue, Mar 19, 2013 at 9:44 PM, Michael Foord  
> wrote:
>> 
>> On 19 Mar 2013, at 17:26, Antoine Pitrou  wrote:
>> 
>> > On Wed, 20 Mar 2013 01:22:58 +0100 (CET)
>> > michael.foord  wrote:
>> >> http://hg.python.org/cpython/rev/684b75600fa9
>> >> changeset:   82811:684b75600fa9
>> >> user:Michael Foord 
>> >> date:Tue Mar 19 17:22:51 2013 -0700
>> >> summary:
>> >>  Closes issue 17467. Add readline and readlines support to 
>> >> unittest.mock.mock_open
>> >
>> > Wasn't it possible to re-use an existing implementation (such as
>> > TextIOBase or StringIO) rather than re-write your own?
>> >
>> > (it's not even obvious your implementation is correct, BTW. How about
>> > universal newlines?)
>> 
>> mock_open makes it easy to put a StringIO in place if that's what you want. 
>> It's just a simple helper function for providing some known data *along with 
>> the Mock api* to make asserts that it was used correctly. It isn't 
>> presenting a full file-system. My suggestion to the implementor of the patch 
>> was that read / readline / readlines be disconnected - but the patch 
>> provided allows them to be interleaved and I saw no reason to undo that.
>> 
>> If users want more complex behaviour (like universal newline support) they 
>> can use mock_open along with a StringIO.
> 
> It'd be good to mention that in the unittest.mock.rst docs.
>  

I'll look at clarifying the intent and limitations of mock_open in the docs - 
plus an example of using it with a StringIO.

It maybe that the support for interleaving of read and readline (etc) is  just 
unnecessary and setting them separately is enough (which simplifies the 
implementation). I know Toshio had a specific use case needing readline support 
so I'll check with him.

Michael



>> 
>> Michael
>> 
>> 
>> >
>> > 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/fuzzyman%40voidspace.org.uk
>> 
>> 
>> --
>> http://www.voidspace.org.uk/
>> 
>> 
>> May you do good and not evil
>> May you find forgiveness for yourself and forgive others
>> May you share freely, never taking more than you give.
>> -- the sqlite blessing
>> http://www.sqlite.org/different.html
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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/greg%40krypto.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] [Python-checkins] cpython: Issue #13248: removed deprecated and undocumented difflib.isbjunk, isbpopular.

[Eli Bendersky]

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

Eli


On Tue, Mar 19, 2013 at 4:44 PM, terry.reedy wrote:

> http://hg.python.org/cpython/rev/612d8bbcfa3a
> changeset:   82807:612d8bbcfa3a
> user:Terry Jan Reedy 
> date:Tue Mar 19 19:44:04 2013 -0400
> summary:
>   Issue #13248: removed deprecated and undocumented difflib.isbjunk,
> isbpopular.
>
> files:
>   Lib/difflib.py |  14 --
>   1 files changed, 0 insertions(+), 14 deletions(-)
>
>
> diff --git a/Lib/difflib.py b/Lib/difflib.py
> --- a/Lib/difflib.py
> +++ b/Lib/difflib.py
> @@ -336,20 +336,6 @@
>  for elt in popular: # ditto; as fast for 1% deletion
>  del b2j[elt]
>
> -def isbjunk(self, item):
> -"Deprecated; use 'item in SequenceMatcher().bjunk'."
> -warnings.warn("'SequenceMatcher().isbjunk(item)' is deprecated;\n"
> -  "use 'item in SMinstance.bjunk' instead.",
> -  DeprecationWarning, 2)
> -return item in self.bjunk
> -
> -def isbpopular(self, item):
> -"Deprecated; use 'item in SequenceMatcher().bpopular'."
> -warnings.warn("'SequenceMatcher().isbpopular(item)' is
> deprecated;\n"
> -  "use 'item in SMinstance.bpopular' instead.",
> -  DeprecationWarning, 2)
> -return item in self.bpopular
> -
>  def find_longest_match(self, alo, ahi, blo, bhi):
>  """Find longest matching block in a[alo:ahi] and b[blo:bhi].
>
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
>
___
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] IDLE in the stdlib

[Eli Bendersky]

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

Personally, I think that IDLE reflects badly on Python in more ways than
one. It's badly maintained, quirky and ugly. It serves a very narrow set of
uses, and does it badly.

Being part of Python *distributions* and being part of core Python standard
library are two different things. The former may make sense, the latter
IMHO makes no sense whatsoever. Outside the Python core IDLE can be
maintained more freely, with less restrictions on contributors and
hopefully become a better tool.


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

[Todd Rovito]

On Wed, Mar 20, 2013 at 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."
>
> Personally, I think that IDLE reflects badly on Python in more ways than
> one. It's badly maintained, quirky and ugly. It serves a very narrow set of
> uses, and does it badly.
>
> Being part of Python *distributions* and being part of core Python standard
> library are two different things. The former may make sense, the latter IMHO
> makes no sense whatsoever. Outside the Python core IDLE can be maintained
> more freely, with less restrictions on contributors and hopefully become a
> better tool.
Eli,
   Thanks for sharing that article it was a fun read.  I think the
next paragraph from the article is important as well:
"I believe my first contribution to the Python Standard Library will
be fixes to IDLE. I really do like it that much. Happily, the kids
were flexible. If they needed to do a workaround, or ignore something
on our slides (they were written with the standard shell in mind),
they did so. They were total champs. My adult students would have been
much more upset."

Having an IDE that ships with Python is powerful and follows Python's
mantra "batteries included".  Personally I think removing IDLE from
the Python Standard Library is a mistake.  IDLE helps the novice get
started as demonstrated by this article.   What is frustrating is many
patches already exist for IDLE in the bug tracker they simply have not
been committed.  PEP-434 (http://www.python.org/dev/peps/pep-0434/) is
designed to make it easier to get these patches committed.  I would
ask that you give PEP-434 some time and let the process work before we
start a in-depth discussion on if IDLE should stay or go.
___
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 10:11 AM, Todd Rovito  wrote:

> On Wed, Mar 20, 2013 at 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."
> >
> > Personally, I think that IDLE reflects badly on Python in more ways than
> > one. It's badly maintained, quirky and ugly. It serves a very narrow set
> of
> > uses, and does it badly.
> >
> > Being part of Python *distributions* and being part of core Python
> standard
> > library are two different things. The former may make sense, the latter
> IMHO
> > makes no sense whatsoever. Outside the Python core IDLE can be maintained
> > more freely, with less restrictions on contributors and hopefully become
> a
> > better tool.
> Eli,
>Thanks for sharing that article it was a fun read.  I think the
> next paragraph from the article is important as well:
> "I believe my first contribution to the Python Standard Library will
> be fixes to IDLE. I really do like it that much. Happily, the kids
> were flexible. If they needed to do a workaround, or ignore something
> on our slides (they were written with the standard shell in mind),
> they did so. They were total champs. My adult students would have been
> much more upset."
>
> Having an IDE that ships with Python is powerful and follows Python's
> mantra "batteries included".  Personally I think removing IDLE from
> the Python Standard Library is a mistake.  IDLE helps the novice get
> started as demonstrated by this article.   What is frustrating is many
> patches already exist for IDLE in the bug tracker they simply have not
> been committed.  PEP-434 (http://www.python.org/dev/peps/pep-0434/) is
> designed to make it easier to get these patches committed.  I would
> ask that you give PEP-434 some time and let the process work before we
> start a in-depth discussion on if IDLE should stay or go.
>

Todd, note that I did not propose to remove IDLE from Python distributions,
just from the Python core (Mercurial repository, to be technically
precise). This is a big difference. Outside the Python core a more
free-moving community can be built around developing IDLE. I've seen PEP
434, but it's far from being enough. I just don't think there are enough
core devs with the time and desire to review IDLE patches (especially
non-trivial ones). Outside the Python code, this can be relaxed. And Python
distributions can still bundle some stable IDLE release.

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

[Nick Coghlan]

On Wed, Mar 20, 2013 at 9:41 AM, 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."
>
> Personally, I think that IDLE reflects badly on Python in more ways than
> one. It's badly maintained, quirky and ugly. It serves a very narrow set of
> uses, and does it badly.
>
> Being part of Python *distributions* and being part of core Python standard
> library are two different things. The former may make sense, the latter IMHO
> makes no sense whatsoever. Outside the Python core IDLE can be maintained
> more freely, with less restrictions on contributors and hopefully become a
> better tool.

Unfortunately, this cannot change until we have a usable installation
tool shipping with CPython. Thus, it can only be on the agenda for
serious consideration in Python 3.5 at the earliest. In the meantime,
any core developers concerned that IDLE reflects badly on Python could
go through the tracker issues on bugs.python.org and try to improve
the situation for 3.4 (and 3.3.2 and 2.7.5). Feedback on Terry's PEP
434 (explicitly pushing IDLE towards "application that ships with
Python that may receive minor enhancements in maintenance releases"
status, rather than "no new features whatsoever in maintenance
releases") would also be appreciated.

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

[R. David Murray]

On Wed, 20 Mar 2013 09:41:53 -0700, Eli Bendersky  wrote:
> Personally, I think that IDLE reflects badly on Python in more ways than
> one. It's badly maintained, quirky and ugly. It serves a very narrow set of
> uses, and does it badly.
> 
> Being part of Python *distributions* and being part of core Python standard
> library are two different things. The former may make sense, the latter
> IMHO makes no sense whatsoever. Outside the Python core IDLE can be
> maintained more freely, with less restrictions on contributors and
> hopefully become a better tool.

On the other hand, after several years of almost complete neglect,
we have some people interested in and actively contributing to making
it better *in the stdib*.  Terry has proposed a PEP for allowing it
to see more rapid changes than a "normal" stdlib package, and I haven't
perceived a lot of opposition to this.  I think Terry's PEP represents
less of change to how we do things than bundling an externally maintained
IDLE would be, especially with respect to Linux.

FYI I talked to someone at PyCon who is not a current contributor to
IDLE but who is very interested in helping with it, and it sounded like
he had the backing of his organization to do this (it was a quick hall
conversation and unfortunately I did not get his name).  So we may be
approaching an inflection point where IDLE will start getting the love
that it needs.

That said, there is something important in the argument that more
contributors could be attracted to an external project.  I'm wondering,
however, if this is more a reflection of a general issue we might want to
look at, than anything specific to IDLE.  Python is a growing project,
and it may be time to start thinking about better ways to encourage
and coordinate more contributions to various pieces of Python and its
standard library.  But that is a much bigger conversation.

--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] [Python-checkins] cpython: Issue #13248: removed deprecated and undocumented difflib.isbjunk, isbpopular.

[R. David Murray]

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

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.

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

[Eli Bendersky]

On Wed, Mar 20, 2013 at 11:09 AM, R. David Murray wrote:

> On Wed, 20 Mar 2013 09:41:53 -0700, Eli Bendersky 
> wrote:
> > Personally, I think that IDLE reflects badly on Python in more ways than
> > one. It's badly maintained, quirky and ugly. It serves a very narrow set
> of
> > uses, and does it badly.
> >
> > Being part of Python *distributions* and being part of core Python
> standard
> > library are two different things. The former may make sense, the latter
> > IMHO makes no sense whatsoever. Outside the Python core IDLE can be
> > maintained more freely, with less restrictions on contributors and
> > hopefully become a better tool.
>
> On the other hand, after several years of almost complete neglect,
> we have some people interested in and actively contributing to making
> it better *in the stdib*.  Terry has proposed a PEP for allowing it
> to see more rapid changes than a "normal" stdlib package, and I haven't
> perceived a lot of opposition to this.  I think Terry's PEP represents
> less of change to how we do things than bundling an externally maintained
> IDLE would be, especially with respect to Linux.
>
> FYI I talked to someone at PyCon who is not a current contributor to
> IDLE but who is very interested in helping with it, and it sounded like
> he had the backing of his organization to do this (it was a quick hall
> conversation and unfortunately I did not get his name).  So we may be
> approaching an inflection point where IDLE will start getting the love
> that it needs.
>

The "choke point" is going to be core devs with the time and desire to
review such contributions though. We have a relatively strict process in
the Python core, which makes a lot of since *because* it's Python core.
Getting things committed in Python is not easy, and even if we get a sudden
influx of good patches (which I doubt) these will take time to review and
get committed. In an outside project there's much less friction.

IDLE would be a great first foray into this "separate project" world,
because it is many ways a separate project.

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

[Barry Warsaw]

On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:

>IDLE would be a great first foray into this "separate project" world,
>because it is many ways a separate project.

I really think that's true.  A separate project, occasionally sync'd back into
the stdlib by a core dev seems like the right way to manage IDLE.

-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

[Guido van Rossum]

On Wed, Mar 20, 2013 at 11:22 AM, Eli Bendersky  wrote:

>
>
>
> On Wed, Mar 20, 2013 at 11:09 AM, R. David Murray 
> wrote:
>
>> On Wed, 20 Mar 2013 09:41:53 -0700, Eli Bendersky 
>> wrote:
>> > Personally, I think that IDLE reflects badly on Python in more ways than
>> > one. It's badly maintained, quirky and ugly. It serves a very narrow
>> set of
>> > uses, and does it badly.
>> >
>> > Being part of Python *distributions* and being part of core Python
>> standard
>> > library are two different things. The former may make sense, the latter
>> > IMHO makes no sense whatsoever. Outside the Python core IDLE can be
>> > maintained more freely, with less restrictions on contributors and
>> > hopefully become a better tool.
>>
>> On the other hand, after several years of almost complete neglect,
>> we have some people interested in and actively contributing to making
>> it better *in the stdib*.  Terry has proposed a PEP for allowing it
>> to see more rapid changes than a "normal" stdlib package, and I haven't
>> perceived a lot of opposition to this.  I think Terry's PEP represents
>> less of change to how we do things than bundling an externally maintained
>> IDLE would be, especially with respect to Linux.
>>
>> FYI I talked to someone at PyCon who is not a current contributor to
>> IDLE but who is very interested in helping with it, and it sounded like
>> he had the backing of his organization to do this (it was a quick hall
>> conversation and unfortunately I did not get his name).  So we may be
>> approaching an inflection point where IDLE will start getting the love
>> that it needs.
>>
>
> The "choke point" is going to be core devs with the time and desire to
> review such contributions though. We have a relatively strict process in
> the Python core, which makes a lot of since *because* it's Python core.
> Getting things committed in Python is not easy, and even if we get a sudden
> influx of good patches (which I doubt) these will take time to review and
> get committed. In an outside project there's much less friction.
>
> IDLE would be a great first foray into this "separate project" world,
> because it is many ways a separate project.
>

+1



-- 
--Guido van Rossum (python.org/~guido)
___
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

[Benjamin Peterson]

2013/3/20 Barry Warsaw :
> On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:
>
>>IDLE would be a great first foray into this "separate project" world,
>>because it is many ways a separate project.
>
> I really think that's true.  A separate project, occasionally sync'd back into
> the stdlib by a core dev seems like the right way to manage IDLE.

I would advise against this. Basically, every "externally-maintained"
package with have causes pain. For example, the stdlib now has some
long-diverged fork of simplejson. With xml.etree, it was not clear for
years whether core developers could touch it even though the external
project had died. Either the stdlib and IDLE should go separate ways
or development has to happen in the stdlib with CPython release
schedule and policies.



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

[Python-Dev] PyCon Sprints - Thank you

[Daniel Wozniak]

David and Senthil,

I won't make it to the sprints today because my ride wants to go into 
San Francisco to do touristy things. I'll be flying back to Arizona this 
evening. I still have a fair amount of code that has not been submitted 
to the issue tracker. I will sprint from my house tomorrow and will 
submit whatever else I have ready tomorrow night.


In the future, I'd also like to continue contributing by continuing to 
improve test coverage since that is helping me get familiar with both 
the code base, style, and general processes of contributing. Thank you 
both for all your help and patience. You have been very welcoming. I am 
sure Python will continue to grow and attract new contributors so long 
as there are mentors such as yourselves there to support n00bs like me.


Thanks again,

Daniel Wozniak
___
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] PyCon Sprints - Thank you

[R. David Murray]

Thank you for your contributions, and we look forward to anything else
you may choose to contribute!

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

[Guido van Rossum]

On Wed, Mar 20, 2013 at 12:14 PM, Benjamin Peterson wrote:

> 2013/3/20 Barry Warsaw :
> > On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:
> >
> >>IDLE would be a great first foray into this "separate project" world,
> >>because it is many ways a separate project.
> >
> > I really think that's true.  A separate project, occasionally sync'd
> back into
> > the stdlib by a core dev seems like the right way to manage IDLE.
>
> I would advise against this. Basically, every "externally-maintained"
> package with have causes pain. For example, the stdlib now has some
> long-diverged fork of simplejson. With xml.etree, it was not clear for
> years whether core developers could touch it even though the external
> project had died. Either the stdlib and IDLE should go separate ways
> or development has to happen in the stdlib with CPython release
> schedule and policies.
>

Agreed that the "sync into stdlib" think should not happen, or should at
best be a temporary measure until we can remove idle from the source
tarball (maybe at the 3.4 release, otherwise at 3.5).

The main thing I like about the separate project idea is that, given that
only a small group of people care about IDLE, it is much more satisfying
for them to be able to release IDLE separately to their user community
regularly (every month if they want to) rather than being held to the core
Python release schedule and practices. We should deal with compatibility
obligations of the stdlib in the usual way, though maybe we can just delete
it in 3.4, since few people presumably use idlelib apart from IDLE itself.
Binary distributions from python.org should still include IDLE (and Tcl/Tk)
-- however we should switch to bundling the separate project's output
rather than bundling the increasingly broken version in the stdlib. What
other distributors do is outside our control, but we ought to recommend
them to do the same.

-- 
--Guido van Rossum (python.org/~guido)
___
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 20, 2013, at 12:31 PM, Guido van Rossum wrote:

>Agreed that the "sync into stdlib" think should not happen, or should at
>best be a temporary measure until we can remove idle from the source
>tarball (maybe at the 3.4 release, otherwise at 3.5).

Right.  Ultimately, I think IDLE should be a separate project entirely, but I
guess there's push back against that too.

-Barry


signature.asc
Description: PGP signature
___
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

[Guido van Rossum]

On Wed, Mar 20, 2013 at 12:38 PM, Barry Warsaw  wrote:

> On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote:
>
> >Agreed that the "sync into stdlib" think should not happen, or should at
> >best be a temporary measure until we can remove idle from the source
> >tarball (maybe at the 3.4 release, otherwise at 3.5).
>
> Right.  Ultimately, I think IDLE should be a separate project entirely,
> but I
> guess there's push back against that too.


I didn't hear any at the sprint here.

-- 
--Guido van Rossum (python.org/~guido)
___
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 12:14 PM, Benjamin Peterson wrote:

> 2013/3/20 Barry Warsaw :
> > On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:
> >
> >>IDLE would be a great first foray into this "separate project" world,
> >>because it is many ways a separate project.
> >
> > I really think that's true.  A separate project, occasionally sync'd
> back into
> > the stdlib by a core dev seems like the right way to manage IDLE.
>
> I would advise against this. Basically, every "externally-maintained"
> package with have causes pain. For example, the stdlib now has some
> long-diverged fork of simplejson. With xml.etree, it was not clear for
> years whether core developers could touch it even though the external
> project had died. Either the stdlib and IDLE should go separate ways
> or development has to happen in the stdlib with CPython release
> schedule and policies.
>

There are other dependencies like libffi, but I really think IDLE is
different. xml.etree and libffi are building blocks upon which a lot of
users' code depends. So we have to keep maintaining them (unless there's
some sort of agreed deprecation process). IDLE is really a stand-alone
project built on Python. It's unique in this respect.
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

[Xavier Morel]

On 2013-03-20, at 20:38 , Barry Warsaw wrote:

> On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote:
> 
>> Agreed that the "sync into stdlib" think should not happen, or should at
>> best be a temporary measure until we can remove idle from the source
>> tarball (maybe at the 3.4 release, otherwise at 3.5).
> 
> Right.  Ultimately, I think IDLE should be a separate project entirely, but I
> guess there's push back against that too.

The problem with it is, well, that it's a separate project so unless it
is still packaged in (in which case it's not quite separate project,
just a separate source tree) it's got to be downloaded and installed
separately.

That would be a blow to educators, but also Windows users: while the CLI
works very nicely in unices, that's not the case with the win32 console
which is as best as I can describe it a complete turd, making IDLE a
very nice proposition there (I never use IDLE on Linux or OSX, but do
all the time in Windows). It also provides a rather capable (and in many
case sufficient) code editor for a platform which lacks any form of
native text editor allowing sane edition of code.

Installing the Python windows packages and having everything "work" (in
the sense that you can immediately start writing and running python
code) is — I think — a pretty big feature.
___
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 20, 2013, at 12:40 PM, Guido van Rossum wrote:

>I didn't hear any at the sprint here.

JFDI! :)

-Barry


signature.asc
Description: PGP signature
___
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 12:51 PM, Xavier Morel wrote:

> On 2013-03-20, at 20:38 , Barry Warsaw wrote:
>
> > On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote:
> >
> >> Agreed that the "sync into stdlib" think should not happen, or should at
> >> best be a temporary measure until we can remove idle from the source
> >> tarball (maybe at the 3.4 release, otherwise at 3.5).
> >
> > Right.  Ultimately, I think IDLE should be a separate project entirely,
> but I
> > guess there's push back against that too.
>
> The problem with it is, well, that it's a separate project so unless it
> is still packaged in (in which case it's not quite separate project,
> just a separate source tree) it's got to be downloaded and installed
> separately.
>
> That would be a blow to educators, but also Windows users: while the CLI
> works very nicely in unices, that's not the case with the win32 console
> which is as best as I can describe it a complete turd, making IDLE a
> very nice proposition there (I never use IDLE on Linux or OSX, but do
> all the time in Windows). It also provides a rather capable (and in many
> case sufficient) code editor for a platform which lacks any form of
> native text editor allowing sane edition of code.
>
> Installing the Python windows packages and having everything "work" (in
> the sense that you can immediately start writing and running python
> code) is — I think — a pretty big feature.
> _
>

FWIW, I specifically suggested that IDLE still gets packaged with Python
releases for Windows. This shouldn't be hard, because IDLE depends on
Python rather than the other way around. Packaging is not what I'm against.
Maintaining this project's source within the Python core *is*.

I would be interested to hear Martin's opinion on this, as he's producing
the Windows installers.

Eli

P.S. other Python distributions like ActiveState already bundle additional
projects with their Python releases (pywin32 if I'm not mistaken).
___
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

[Brian Curtin]

On Wed, Mar 20, 2013 at 2:51 PM, Xavier Morel  wrote:
> That would be a blow to educators, but also Windows users: while the CLI
> works very nicely in unices, that's not the case with the win32 console
> which is as best as I can describe it a complete turd, making IDLE a
> very nice proposition there (I never use IDLE on Linux or OSX, but do
> all the time in Windows).

Can you explain this a bit more? I've been using the CLI python.exe on
Windows, Mac, and Linux for years and I don't know what you're talking
about.
___
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]

>> Agreed that the "sync into stdlib" think should not happen, or should at

>  >> best be a temporary measure until we can remove idle from the source
> >> tarball (maybe at the 3.4 release, otherwise at 3.5).
> >
> > Right.  Ultimately, I think IDLE should be a separate project entirely,
> but I
> > guess there's push back against that too.
>
> The problem with it is, well, that it's a separate project so unless it
> is still packaged in (in which case it's not quite separate project,
> just a separate source tree) it's got to be downloaded and installed
> separately.
>
> That would be a blow to educators, but also Windows users: while the CLI
> works very nicely in unices, that's not the case with the win32 console
> which is as best as I can describe it a complete turd, making IDLE a
> very nice proposition there (I never use IDLE on Linux or OSX, but do
> all the time in Windows). It also provides a rather capable (and in many
> case sufficient) code editor for a platform which lacks any form of
> native text editor allowing sane edition of code.
>
> Installing the Python windows packages and having everything "work" (in
> the sense that you can immediately start writing and running python
> code) is — I think — a pretty big feature.


Oh, and another thing. If a Windows user wants a good Python shell, IDLE
should be his last choice. There's Spyder, there's IPython, there's
probably a bunch of others I'm not aware of.

This is for IDLE as a shell. The same can be said for IDLE as an editor.

This is precisely my main gripe with IDLE: it does a lot of things, but
neither of them it does well. It stomps in place while "competition" moves
fast forward. If someone cares about it, that someone should fix it and
improve it, quickly. The speed required for such improvements is
unrealistic for Python core.

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

[Daniel Holth]

On Wed, Mar 20, 2013 at 3:54 PM, Barry Warsaw  wrote:
> On Mar 20, 2013, at 12:40 PM, Guido van Rossum wrote:
>
>>I didn't hear any at the sprint here.
>
> JFDI! :)
>
> -Barry

+1 why are we still talking show me the patches
___
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] How to fix the incorrect shared library extension on linux for 3.2 and newer?

[Matthias Klose]

This is http://bugs.python.org/issue16754, affecting Linux systems only, and
only those which don't provide static libraries. PEP 3149 did change the SO
macro to include the ABI tag, although the SO macro is used to search for shared
system libraries too.  E.g. searching for the jpeg library search for a file
libjpeg.cpython3.3m.so, which is not found. If the static library libjpeg.a is
found, it is taken, and linked as -ljpeg, which then links with the shared 
library.

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.

  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] IDLE in the stdlib

[Xavier Morel]

On 2013-03-20, at 20:59 , Brian Curtin wrote:

> On Wed, Mar 20, 2013 at 2:51 PM, Xavier Morel  wrote:
>> That would be a blow to educators, but also Windows users: while the CLI
>> works very nicely in unices, that's not the case with the win32 console
>> which is as best as I can describe it a complete turd, making IDLE a
>> very nice proposition there (I never use IDLE on Linux or OSX, but do
>> all the time in Windows).
> 
> Can you explain this a bit more? I've been using the CLI python.exe on
> Windows, Mac, and Linux for years and I don't know what you're talking
> about.

Windows's terminal emulator (the "win32 console")'s deficiencies don't
break it for running existing script, but make using it interactively a
rather thankless task, at least as far as I'm concerned: no readline
keybinding (e.g. C-a & C-e), very limited scrollback, fixed width,
non-handling of signals (C-d will simply print ^D, a syntax error),
odd copy behavior (rectangle copies *only*), etc…
___
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

[Xavier Morel]

On 2013-03-20, at 21:14 , Eli Bendersky wrote:

>>> Agreed that the "sync into stdlib" think should not happen, or should at
> 
 best be a temporary measure until we can remove idle from the source
 tarball (maybe at the 3.4 release, otherwise at 3.5).
>>> 
>>> Right.  Ultimately, I think IDLE should be a separate project entirely,
>> but I
>>> guess there's push back against that too.
>> 
>> The problem with it is, well, that it's a separate project so unless it
>> is still packaged in (in which case it's not quite separate project,
>> just a separate source tree) it's got to be downloaded and installed
>> separately.
>> 
>> That would be a blow to educators, but also Windows users: while the CLI
>> works very nicely in unices, that's not the case with the win32 console
>> which is as best as I can describe it a complete turd, making IDLE a
>> very nice proposition there (I never use IDLE on Linux or OSX, but do
>> all the time in Windows). It also provides a rather capable (and in many
>> case sufficient) code editor for a platform which lacks any form of
>> native text editor allowing sane edition of code.
>> 
>> Installing the Python windows packages and having everything "work" (in
>> the sense that you can immediately start writing and running python
>> code) is — I think — a pretty big feature.
> 
> 
> Oh, and another thing. If a Windows user wants a good Python shell, IDLE
> should be his last choice. There's Spyder, there's IPython, there's
> probably a bunch of others I'm not aware of.

Sure, there are plenty of tools for the experienced python developer
with reasons to invest time in a windows development setup, but IDLE
provides an acceptable low-cost and low-investment base which is
*there*: it does not require spending a day downloading, trying out and
getting familiar with a dozen different Python IDEs, it's simple and
for the most part it works.

I view it as an mg, not an emacs, if you see what I mean.
___
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

[Brett Cannon]

On Wed, Mar 20, 2013 at 3:51 PM, Xavier Morel wrote:

> On 2013-03-20, at 20:38 , Barry Warsaw wrote:
>
> > On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote:
> >
> >> Agreed that the "sync into stdlib" think should not happen, or should at
> >> best be a temporary measure until we can remove idle from the source
> >> tarball (maybe at the 3.4 release, otherwise at 3.5).
> >
> > Right.  Ultimately, I think IDLE should be a separate project entirely,
> but I
> > guess there's push back against that too.
>
> The problem with it is, well, that it's a separate project so unless it
> is still packaged in (in which case it's not quite separate project,
> just a separate source tree) it's got to be downloaded and installed
> separately.
>
> That would be a blow to educators, but also Windows users: while the CLI
> works very nicely in unices, that's not the case with the win32 console
> which is as best as I can describe it a complete turd, making IDLE a
> very nice proposition there (I never use IDLE on Linux or OSX, but do
> all the time in Windows). It also provides a rather capable (and in many
> case sufficient) code editor for a platform which lacks any form of
> native text editor allowing sane edition of code.
>
> Installing the Python windows packages and having everything "work" (in
> the sense that you can immediately start writing and running python
> code) is — I think — a pretty big feature.


First, a clarification since people seem to have missed it a couple of
times: both Eli and Guido said IDLE would continue to be bundled with
binary distributions from python.org, just developed independently. Now
Guido's comment may have just been to handle deprecation of IDLE from the
stdlib, but at least he wasn't saying "leave it out tomorrow", just "take
it out of the stdlib to be developed independently". That still allows it
to come with Python and alleviate any installation issues by shifting the
load to release managers.

Second, I hear the "it will hurt educators" argument every time this topic
comes up, and so I want to know exactly where the challenge comes from. Is
it from people coming to a class with their own laptop where they can't
install anything due to lack of knowledge but can bring up a shell and type
"idle"? If that were the case can't you also just as easily teach them to
type "pysetup pip", "pip install idle", "idle"? Or heck, if Nick's
dead-simple bootstrap installer could handle "pysetup idle" then you can
cut that down a step. Notice that none of this suggests the removal of
tkinter since that never changes and the hard work is already done
(although if we could get the binary wheel for the various OSs to just
include tkinter w/ IDLE then that could also potentially move out and
shrink the binary even further).

Is it lack of administrative access on machines in a computer lab? Then I
would ask if IDLE is even included in Linux distributions by default
typically or can be removed separately?

Is it lack of administrative access on personal laptops? In that case you
should be able to ask them to find out the password before they come. You
can also ask them to install into their user-level site-packages directory
(we have PEP 370 for a reason).

Regardless of the answers to the questions above, I support the idea of at
least releasing IDLE more often and that mostly means developing it
externally from the stdlib. If we want to continue to bundle it in the
binary, then we should pull in the latest stable release when we cut a new
version of Python. But regardless the current situation should not continue.
___
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 1:59 PM, Xavier Morel wrote:

>
> On 2013-03-20, at 21:14 , Eli Bendersky wrote:
>
> >>> Agreed that the "sync into stdlib" think should not happen, or should
> at
> >
>  best be a temporary measure until we can remove idle from the source
>  tarball (maybe at the 3.4 release, otherwise at 3.5).
> >>>
> >>> Right.  Ultimately, I think IDLE should be a separate project entirely,
> >> but I
> >>> guess there's push back against that too.
> >>
> >> The problem with it is, well, that it's a separate project so unless it
> >> is still packaged in (in which case it's not quite separate project,
> >> just a separate source tree) it's got to be downloaded and installed
> >> separately.
> >>
> >> That would be a blow to educators, but also Windows users: while the CLI
> >> works very nicely in unices, that's not the case with the win32 console
> >> which is as best as I can describe it a complete turd, making IDLE a
> >> very nice proposition there (I never use IDLE on Linux or OSX, but do
> >> all the time in Windows). It also provides a rather capable (and in many
> >> case sufficient) code editor for a platform which lacks any form of
> >> native text editor allowing sane edition of code.
> >>
> >> Installing the Python windows packages and having everything "work" (in
> >> the sense that you can immediately start writing and running python
> >> code) is — I think — a pretty big feature.
> >
> >
> > Oh, and another thing. If a Windows user wants a good Python shell, IDLE
> > should be his last choice. There's Spyder, there's IPython, there's
> > probably a bunch of others I'm not aware of.
>
> Sure, there are plenty of tools for the experienced python developer
> with reasons to invest time in a windows development setup, but IDLE
> provides an acceptable low-cost and low-investment base which is
> *there*: it does not require spending a day downloading, trying out and
> getting familiar with a dozen different Python IDEs, it's simple and
> for the most part it works.
>
> I view it as an mg, not an emacs, if you see what I mean.
> ___
>

This seems more like an education & documentation issue than a technical
problem. We can explicitly recommend Python Windows users to install IDLE
or Spyder or IPython in some friendly "get started on Windows" guide.

But we seem to be talking about different things, really. I'm not saying we
shouldn't distribute IDLE with Python on Windows, at this point (I think
this will be a good idea in the future, but let's make it gradual). All I'm
saying is that IDLE should be developed outside the CPython core project.
This has the potential of making  both CPython and IDLE better.

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] PyCon Sprints - Thank you

[Senthil Kumaran]

Thanks Daniel, for all the patches and improving the test coverage.
Hope you had a good time and will you enjoy contributing further.

Happy touring SF.

-- 
Senthil

On Wed, Mar 20, 2013 at 12:24 PM, R. David Murray  wrote:
> Thank you for your contributions, and we look forward to anything else
> you may choose to contribute!
>
> --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] How to fix the incorrect shared library extension on linux for 3.2 and newer?

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

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.

-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

[Nick Coghlan]

On Wed, Mar 20, 2013 at 12:54 PM, Barry Warsaw  wrote:
> On Mar 20, 2013, at 12:40 PM, Guido van Rossum wrote:
>
>>I didn't hear any at the sprint here.
>
> JFDI! :)

Please don't rush this. We have Roger Serwy being given commit
privileges specifically to work on Idle, Terry's PEP proposing to make
it explicit that we consider IDLE an application bundled with Python
that can receive new features in maintenance releases and several
people expressing interest in helping to make IDLE better (primarily
educators, including Katie Cunningham, one of the teachers who ran the
Raspberry Pi based Young Coders sessions for teens and pre-teens here
at PyCon).

These are the people who care about Idle, we should be recruiting them
to work on it *as it is now*, and then letting them decide if they
wish to continue working on it as it is now, or if they prefer to move
to a more inclusive development platform which allows them to accept
pull requests rather than requiring patches to be generated locally
and uploaded to our tracker.

It's not as simple as saying "let's split it out to a separate repo
and then bundle it", because bundling still means python-dev is
placing it's stamp of approval on the application, which means we
should be satisfied that the developers leading the project are people
we trust as stewards of software we distribute.

Yes, the status quo of Idle is not something we should allow to
continue indefinitely, but decisions about its future development
should be made by active maintainers that are already trusted to make
changes to it (such as Terry and Roger), rather than those of us that
don't use it, and aren't interested in maintaining it.

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] Recent changes to TextIOWrapper and its tests

[Jeff Allen]

On 19/03/2013 08:03, Serhiy Storchaka wrote:

On 18.03.13 22:26, Jeff Allen wrote:

The puzzle is that it requires t.read() to succeed.

When I insert a check for bytes type in all the places it seems
necessary in my code, I pass the first two conditions, but since
t.read() also raises TypeError, the overall test fails. Is reading the
stream with read() intended to succeed? Why is this desired?


An alternative option is to change C implementation of 
TextIOWrapper.read() to raise an exception in this case. However I 
worry that it can break backward compatibility.
Thanks for this and the previous note. It is good to get it from the 
horse's mouth. I was surprised that the Python 3 version of the test was 
different here. I'd looked at the source of textio.c and found no test 
for bytes type in the n<0 branch of textiowrapper_read. Having tested it 
just now, I see that the TypeError is raised by the decoder in Py3k, 
because the input (when it is a unicode string) does not bear the buffer 
API, and not by a type test in TextIOWrapper.read() at all.


For Jython, I shall make TextIOWrapper raise TypeError and our version 
of test_io will check for it. Any incompatibility relates only to 
whether a particular mistake sometimes goes undetected, so I feel pretty 
compatible. Added to which, this is the behaviour of Python 3 and we 
feel safe anticipating Py3k in small ways.


  Are there other tests (in other test files) which fail with a new 
Jython TextIOWrapper?


I don't think there is anything else specific to TextIOWrapper, but if 
there is I will first treat that as a fault in our implementation. This 
is the general approach, to emulate the CPython implementation unless a 
test is clearly specific to arbitrary implementation choices. (There's a 
general exclusion for garbage collection.) In this case the test 
appeared to reflect an accident of implementation, but might just have 
been deliberate.


Parts of the Jython implementation of io not yet implemented in Java are 
supplied by a Python module _jyio. This is essentially a copy of the 
corresponding parts of _pyio, except that it has to pass the C* tests, 
not the Py* tests. In places _jyio is therefore closer to _io than is 
_pyio. For example, it makes the type tests just discussed, and passes 
CTextIOWrapperTest.test_illegal_decoder and test_initialization. 
_jyio.StringIO has getstate and setstate methods lacking in _pyio 
counterparts to pass pickling tests in test_memoryio. This might be of 
interest to CPython for _pyio.


Jeff Allen

___
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 15:05:40 -0700
Nick Coghlan  wrote:
> 
> Yes, the status quo of Idle is not something we should allow to
> continue indefinitely, but decisions about its future development
> should be made by active maintainers that are already trusted to make
> changes to it (such as Terry and Roger), rather than those of us that
> don't use it, and aren't interested in maintaining it.

Definitely. People shouldn't remain quiescently torpid about the idle
status quo.

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] IDLE in the stdlib

[Kurt B. Kaiser]

[Barry]
> On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:
>>IDLE would be a great first foray into this "separate project" world,
because it is many ways a separate project.
> I really think that's true.  A separate project, occasionally sync'd
back
> into
> the stdlib by a core dev seems like the right way to manage IDLE.

It seems to me that we are seeing increasing use of IDLE for beginner
training. I've seen several recent Python books that use IDLE as their
programming environment, and which include IDLE screen captures in the
text.

I've always felt that IDLE should be targeted to an eight year old
beginner, and should work uniformly across the major platforms.  That
now
includes the Raspberry Pi!!

I believe it's very important that Python come with an IDE as part of
the
"batteries"  - it's very awkward for a beginner to write code in
something
like Notepad and then run and debug it in a Windows command shell. Just
getting the paths right is problematic (and I'm not talking about
backslashes).

It's very helpful for an instructor to be able to deal with a single
application that runs on all the major platforms, and not have to spend
a
lot of time getting the tools up to speed before the actual Python
training can begin.

And, while an instructor can walk a student through downloading and
installing some IDE, it's very helpful IMHO for a beginner working alone
on Windows or Mac to be able to just click on IDLE.

A Raspberry Pi might not even have a web connection!

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!

IDLE forked nearly a decade ago to introduce subprocess execution and
the
configuration dialog.  Subsequently, I merged it back into core and it
played a useful role in Python 3 development.

Scheme hackers write new Scheme implementations.  Python hackers tend to
write editors and IDEs, it seems.  I think, considering all the
competition, that IDLE would have died if it hadn't been merged back. 
Instead, many of its competitors died.

So, although I'm pretty agnostic regarding where development is done, I
think Python should continue to release a simple native IDE in its
binaries, and I worry that IDLE will be eventually dropped from the
binaries if it's separate. Right now, Apple is delivering IDLE along
with
Python (though there are issues with the current installation) and I
hope
that will continue.

OTOH, development is likely to be more vigorous if it's separate.

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.  IMHO
some of the feature patches on the tracker should be rejected on that
basis.

It's sometimes said that IDLE is "ugly" or "broken".  These terms are
subjective!  If it's truly broken, then we should fix it.  If it's
"broken" because a feature is missing, maybe that's an intentional part
of
Guido's design of a simple Python IDE.

-- 
KBK
___
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] IDLE in the stdlib

[Kurt B. Kaiser]

I apologize for that formatting mess - the Barracuda rejected my
original email for some reason (squirrelmail directly from shore.net)
and I had to resend it from rejects - it got re-wrapped on transmission.

-- 
KBK
___
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 20, 2013, at 11:11 PM, Antoine Pitrou wrote:

>On Wed, 20 Mar 2013 15:05:40 -0700
>Nick Coghlan  wrote:
>> 
>> Yes, the status quo of Idle is not something we should allow to
>> continue indefinitely, but decisions about its future development
>> should be made by active maintainers that are already trusted to make
>> changes to it (such as Terry and Roger), rather than those of us that
>> don't use it, and aren't interested in maintaining it.
>
>Definitely. People shouldn't remain quiescently torpid about the idle
>status quo.

The release managers should have a say in the matter, since it does cause some
amount of pain there.

-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

[Terry Reedy]

On 3/20/2013 2:22 PM, Eli Bendersky wrote:

On Wed, Mar 20, 2013 at 11:09 AM, R. David Murray mailto:rdmur...@bitdance.com>> wrote:

On Wed, 20 Mar 2013 09:41:53 -0700, Eli Bendersky mailto:eli...@gmail.com>> wrote:

Personally, I think that IDLE reflects badly on Python in more ways than
one. It's badly maintained, quirky and ugly. It serves a very narrow set of
uses, and does it badly.


Personally, I think running Python with the imitation-MSDOS Windows 
Command Prompt (CP) reflects badly on Python in more ways than one. It's 
anti-maintained, quirky and ugly, and for some uses is badly broken.


I am serious and am not just being sarcastic. I suggested years ago that 
we try to find an alternative. Some details:


Ugly (and quirky): it imitates ancient white type on black background 
CRT monitors. I do not know of anything else on Windows that looks like 
that.


Broken (and quirky): it has an absurdly limited output buffer (under a 
thousand lines) that is over-flowed, for instance, by "python -m test". 
In other words, by the time the test suite has finished, the early 
results and error messages have scrolled off the top. Same can be true 
of verbose repository pulls, doc builds, external dependency fetch and 
compile, help messages, and any other substantial printing. For example, 
start the standard interpreter, enter 'help(str)', page down to the 
bottom, scroll back up, and the top of the help message is gone. *That* 
is real 'broken'.


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.


(Anti-maintained: I think Microsoft wants people to abandon unix-like 
command processing and that they are intentionally keeping CP ugly and 
disfunctional.)


Now lets look at IDLE: Standard black (+ other colors) on white and 
close to standard gui. *Much* prettier than CP 'Unlimited' lines of code 
and output in windows. *Much* more functional in this respect. I cannot 
think of *anything* in IDLE that compares to the brokeness of CP in 
throwing output away. Standard ^C,^V behavior. To me, IDLE is much less 
quirky than CP.


Oh, but it did have one quirk -- the right context menus lacked the 
standard Copy and Paste entries of Windows applications. When that was 
added for all versions, a couple of people challenged it as a 
default-only 'enhancement' rather than all-versions 'bugfix'. That 
challenge directly lead to PEP434.  In last two months since, IDLE work 
has mostly stopped.  I will say more about maintenance problems, but 
getting back to CP versus IDLE...


From IDLE:
>>> print('\x80')
€
>>> print('\xc8')
È

Impressed? You should be. Open Start menu / Python33 / Python (command 
line) and both of those result (modulo the specific character) in

  UnicodeEncodeError: 'charmap' codec can't encode character
  '\xc8' in position 0: character maps to 

and we have not even gotten beyond latin-1, into the 'real' unicode char 
set, which IDLE supports MUCH better. For display, default United States 
CP is close to ascii-only.


In summary: IDLE makes Python interactive mode tolerable and useful on 
Windows in ways where CP completely fails. If you are worried about 
something making Python look bad on Windows, target CP before IDLE.



Getting things committed in Python is not easy, and even if we get a
sudden influx of good patches (which I doubt)


Given recent history, this is silly. A year and a few months ago, (Dec 
2011, I think), I asked Roger Serwy to start submitting patches, with 
the promise to review and possibly commit some. Consequently, in the 
last year, we have *already* gotten a 'sudden influx of good patches'.


It is true that I have not yet kept up my end of the bargain. One 
problem for me has been an inability to test IDLE patches on Windows 
with repository builds, due to the need for a working tkinter. It turns 
out that the pc build files are buggy and the devguide and the (to me 
confusing) pcbuild/readme do not have the workaround that was 
communicated to me only about 10 days ago.


> these will take time to review and get committed.

In spite of my slowness, others have been active. Searching 
cpython/Misc/NEWS for ' IDLE ' (case-insensitive) returns 31 hits. For 4 
months (Oct-Jan), that is pretty active, certainly much more active than 
in the years prior to 2012. As soon as PEP434 is resolved and Roger is 
fully on board, the pace will pick up again.


At least a few people have been given commit privileges but never (or 
essentially never) exercised them. I think a couple were specifically 
for working on IDLE. I have not asked any of these people why, but I can 
imagine from my own experience that uncertainty over what is and is not 
allowed is one reason.


I will discuss repository separation in another response, but request 
here that the still vague idea of doing something in the *future* not be 
used to stop PEP434, in whatever form, and current 

Re: [Python-Dev] IDLE in the stdlib

[Terry Reedy]

On 3/20/2013 3:59 PM, Brian Curtin wrote:

On Wed, Mar 20, 2013 at 2:51 PM, Xavier Morel  wrote:

That would be a blow to educators, but also Windows users: while the CLI
works very nicely in unices, that's not the case with the win32 console
which is as best as I can describe it a complete turd, making IDLE a
very nice proposition there (I never use IDLE on Linux or OSX, but do
all the time in Windows).


Can you explain this a bit more? I've been using the CLI python.exe on
Windows, Mac, and Linux for years and I don't know what you're talking
about.


I gave examples in my response to the original post: ^C,^V do not work 
(but do in IDLE); the output buffer cannot even hold the entire 
'help(str)' response (IDLE can, and much more) ; by default, print() 
cannot even print all latin-1 chars, let alone the BMP (IDLE will at 
least print a box for the entire BMP); CP is frozen in time 30 years 
ago, while IDLE is being maintained and modernized.


--
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/20/2013 6:48 PM, Kurt B. Kaiser wrote:


It seems to me that we are seeing increasing use of IDLE for beginner
training. I've seen several recent Python books that use IDLE as their
programming environment, and which include IDLE screen captures in the
text.


Well, one can hardly use Command Prompt captures, unless one were to 
flip black and white within the window (but not its frame).



I've always felt that IDLE should be targeted to an eight year old
beginner, and should work uniformly across the major platforms.  That
now includes the Raspberry Pi!!


I think it should also work uniformly across Python versions. That is 
the gist of PEP434.



I believe it's very important that Python come with an IDE as part of
the "batteries"  - it's very awkward for a beginner to write code in
something like Notepad and then run and debug it in a Windows command shell.


I cut and pasted when I began ;-).


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 have never understood those who suggest that an editor, even a super 
editor, can replace IDLE's one key F5-run, with one click return to the 
spot of the foul on syntax errors.



OTOH, development is likely to be more vigorous if it's separate.


Perhaps, perhaps not, or perhaps it would become 'too' vigorous if too 
many developers pushed multiple 'kitchen sinks'.



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.  IMHO
some of the feature patches on the tracker should be rejected on that
basis.


Have you commented on those issues? I so far have mostly concentrated on 
fixing current features. I agree that major new features should be 
considered carefully and perhaps discussed on a revived idle-sig list. I 
have never used some of the existing features, like breakpoints, that 
seem pretty advanced. I first opened a debugger window only recently, in 
order to comment on a issue about a possible bug. We should document how 
to use that before adding anything else comparable.



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


When IDLE-closing bugs are all fixed, I would like to see how much 
difference themed widgets would make to appearance. Then we could debate 
whether IDLE should look 'native' on each platform or have a common 
'Python' theme -- or have both and let users choose.



If it's truly broken, then we should fix it.  If it's
"broken" because a feature is missing, maybe that's an intentional part
of Guido's design of a simple Python IDE.


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


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

[Neil Hodgson]

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.

   Neil

___
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

[Beni Paskin-Cherniavsky]

Eli Bendersky  gmail.com> writes:

> Oh, and another thing. If a Windows user wants a good Python shell,
> IDLE should be his last choice. There's Spyder, there's IPython,
> there's probably a bunch of others I'm not aware of.This is for IDLE
> as a shell. The same can be said for IDLE as an editor.This is
> precisely my main gripe with IDLE: it does a lot of things, but
> neither of them it does well.

Actually, there are surprisingly little competition to IDLE as a shell!
IDLE has mostly working multi-line editing and history, while most 
"sophisticated" environments (including Spyder) work line-by-line, which makes  
defining a function (let alone a class) in the shell prohibitively painful.

The only other shells I could recommend to a beginner are:
1. IPython, which of course does multi-line editing superbly.
   Its non-standard extensions are a distraction and it's too far into 
   power-user end of the spectrum to ever become a fits-all recommendation.
   The notebook is enough of a win to tip the scales for some educators,
   but the jury is still out if that's a smooth beginner experience.
2. Dreampie, designed by an ex-IDLE-contributor for the sole purpose of 
   being a better shell than IDLE.
   However, lack of an editor makes it less practical as an introductory tool.


___
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] A 'common' respository? (was Re: IDLE in the stdlib)

[Terry Reedy]

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


I will discuss repository separation in another response


Here is a radical idea I have been toying with: set up a 'common' 
repository to 'factor out' files that are, could be, or should be the 
same across versions. The 'common' files would be declared (especially 
to packagers, when relevant) to be a part of each branch. Each release 
would (somehow - not my department) incorporate the latest version of 
everything in 'common'.


What would go here?

Misc/ACKS: the sensible idea that there should only be one copy of this 
file has been discussed before.


LICENSE: I believe this is the same across current versions and must be 
edited in parallel for all future branches.


xxx: others that I have not thought of.

Doc/tools (sphinx and dependencies): setting this up separately but 
identically for each branch is a bit silly if it could be avoided. The 
sphinx versions should, of course, be the new one that runs on both 
python 2 and 3.


idlelib: already discussed. Having only one IDLE version would partially 
speed up development.


(surely controvesial) tkinter and _tkinter: I think the _tkinter and 
tkinter for each release should work with and be tested with the most 
recent tcl/tk release. Having only one tkinter version might make having 
one version of IDLE even easier.


(probably even more controversial) tcl/tk (or at least the files needed 
to fetch and build - but as long as the sources are on python.org 
anyway, the sources could also be moved here from svn): For IDLE to 
really work the same across versions, it needs to run on the same tcl/tk 
version with the same bugfixes. For example, over a year ago, a French 
professor wrote python-list or idle-sig or maybe both saying that he 
would like to use IDLE in a class in Sept 2012, but there was a bug 
keeping it from working properly with French keyboards. He wanted to 
know if we were likely to fix it. The first answer (provided by Kevin 
Walzer) was that it was a tcl/tk bug that he (Kevin) was working on. The 
fix made it into 8.5.9 a year ago and hence into 3.3 but 2.7.3 or 3.2.3, 
released a month after the fix. So I later told him he could use IDLE, 
but, at least on Windows, only with the then upcoming 3.3. (I don't know 
the tcl/tk version policy for the non-Apple builds.)


I do not know if tcl/tk 8.5.z releases have added many features or are 
primarily bugfixes like our micro releases. If the latter, the case for 
distributing at least the most recent 8.5.z with windows would seem 
pretty strong. I also do not know what 8.6.z adds. But an tcl/tk 
'enhancement' of supporting astral characters might look like a bugfix 
for IDLE. (Running from IDLE, print(astral_char) raises, but I believe 
the same code works in some Linux interpreters.)


yyy: any other external dependencies that we update on all versions.

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

[Raymond Hettinger]

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.

> JFDI! :)


That is a comment from a person who uses Emacs every day.
For those of us who have to support people with basic installs,
it is essential that they have some Python aware editor on their
machine.   Without IDLE, a shocking number of people would
create Python files using notepad.


Raymond



___
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

[Steven D'Aprano]

On 21/03/13 11:15, Terry Reedy wrote:


getting back to CP versus IDLE...

 From IDLE:

print('\x80')

€

print('\xc8')

È

Impressed? You should be. Open Start menu / Python33 / Python (command line) 
and both of those result (modulo the specific character) in
   UnicodeEncodeError: 'charmap' codec can't encode character
   '\xc8' in position 0: character maps to 



Terry, you have just done something I didn't think was possible: you've changed 
my personal opinion about IDLE. On the rare, rare occasions where I've had to 
use Python interactively on Windows, I use the standard python.exe command 
prompt, which I thought was easier than learning the (to me) quirks of IDLE's 
UI.

You've just given me a reason to use IDLE.

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.


Thanks Terry.


--
Steven
___
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 7:57 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> 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.
>
>
+1, FWIW

MarkJ
___
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:


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 suggested in my previous response why I think 'badly maintained' is 
untrue and/or unfair. Dismissing the recent work that has been done does 
not help.


There are 20 open issues with smtp(lib) in the title. It is 37 kb, 
making .54 issues per kb. For idlelib, with 786 kb, there are 104 
issues, or .13 issues per kb, which is one fourth as many. I could claim 
that smtplib, based on 1990s RFCs is much worse maintained. It certainly 
could use somee positive attention.


What current quirks, not already the subject of a tracker issue, are you 
thinking of?


> It serves a very narrow set of uses,

Relative to the computing universe, yes. It focuses on editing and 
running Python code.


> and does it badly.

As a user, I rate it at least 'good'. Most of the tracker issues hardly 
affect me, and many or most of the worst problems for me have already 
been fixed. What IDE would you suggest as a simple, install and go, 
alternative? It should have the following features or something close:
* One-key saves the file and runs it with the -i option (enter 
interactive mode after running the file) so one can enter additional 
statements interactively.
* Syntax errors cause a message display; one click returns to the spot 
the error was detected.
* Error tracebacks are displayed unmodified, without extra garbage or 
censorship.

# Right click on a line like
 File "C:\Programs\Python33\lib\difflib.py", line 1759, ...
and then left click on the goto popup to go to that line in that file, 
opening the file if necessary.


As of 3.3.0, this last feature was not documented, at least not in the 
Idle Help file. Since then, it has been.


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

[Eli Bendersky]

On Wed, Mar 20, 2013 at 7:57 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> 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.
>

Why is it necessary to conflate distribution and development. "standard
library" != "Python distribution".

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.

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

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 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?
>
>
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 suggested in my previous response why I think 'badly maintained' is
> untrue and/or unfair. Dismissing the recent work that has been done does
> not help.
>

I did not intend to dismiss your work Terry, and I'm sorry if it came out
this way. You know that I also contributed bug fixes to IDLE in the past so
I'm not a complete outsider. I see the value of IDLE being distributed with
Python. However, especially in view of the recent developments in the area
of alternative Python implementations, I think it's important to clearly
mark the boundaries between things that belong in the core CPython code
repository and things that don't.

>
> There are 20 open issues with smtp(lib) in the title. It is 37 kb, making
> .54 issues per kb. For idlelib, with 786 kb, there are 104 issues, or .13
> issues per kb, which is one fourth as many. I could claim that smtplib,
> based on 1990s RFCs is much worse maintained. It certainly could use somee
> positive attention.
>

You know better than I do that the number of open issues is not really the
only factor for determining the quality of a module.



Eli

--


> What current quirks, not already the subject of a tracker issue, are you
> thinking of?
>
>
> > It serves a very narrow set of uses,
>
> Relative to the computing universe, yes. It focuses on editing and running
> Python code.
>
> > and does it badly.
>
> As a user, I rate it at least 'good'. Most of the tracker issues hardly
> affect me, and many or most of the worst problems for me have already been
> fixed. What IDE would you suggest as a simple, install and go, alternative?
> It should have the following features or something close:
> * One-key saves the file and runs it with the -i option (enter interactive
> mode after running the file) so one can enter additional statements
> interactively.
> * Syntax errors cause a message display; one click returns to the spot the
> error was detected.
> * Error tracebacks are displayed unmodified, without extra garbage or
> censorship.
> # Right click on a line like
>  File "C:\Programs\Python33\lib\**difflib.py", line 1759, ...
> and then left click on the goto popup to go to that line in that file,
> opening the file if necessary.
>
> As of 3.3.0, this last feature was not documented, at least not in the
> Idle Help file. Since then, it has been.
>
>


> --
> 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/**
> eliben%40gmail.com
>
___
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

[Kurt B. Kaiser]

On Wed, Mar 20, 2013, at 09:17 PM, Terry Reedy wrote:
> On 3/20/2013 6:48 PM, Kurt B. Kaiser wrote:
>
> Well, one can hardly use Command Prompt captures, unless one were to
> flip black and white within the window (but not its frame).

And yet many books do - it's really ugly.  When I see a book with a
bunch of DOS windows, white on black, printed on cheap paper, 900 pages,
I just put it back on the shelf.  Quickly.


> > I've always felt that IDLE should be targeted to an eight year old
> > beginner, and should work uniformly across the major platforms. That
> > now includes the Raspberry Pi!!
>
> I think it should also work uniformly across Python versions. That is
> the gist of PEP434.

Well, spending a lot of time backporting new features is not my idea of
fun. OTOH, I have no objection.  Maybe we could automate checkpoints of
IDLE into PyPI or somewhere for those who don't care to pull from hg,
yet want to be on the cutting  edge?

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.

[...]

> > OTOH, development is likely to be more vigorous if it's separate.
>
> Perhaps, perhaps not, or perhaps it would become 'too' vigorous if too
> many developers pushed multiple 'kitchen sinks'.

Oh, I agree with that.  Distributed version control can lead to chaos
and dilution of effort.

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.

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'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.  IMHO some of the feature patches on the tracker
> > should be rejected on that basis.
>
> Have you commented on those issues? I so far have mostly concentrated
> on fixing current features. I agree that major new features should be
> considered carefully and perhaps discussed on a revived idle-sig list.
> I have never used some of the existing features, like breakpoints,
> that seem pretty advanced. I first opened a debugger window only
> recently, in order to comment on a issue about a possible bug. We
> should document how to use that before adding anything else
> comparable.

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.  And as I was
telling Ned here at PyCon, when you step off the train, it can be hard
to get back on.

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?


> > It's sometimes said that IDLE is "ugly" or "broken".  These terms
> > are subjective!
>
> When IDLE-closing bugs are all fixed, I would like to see how much
> difference themed widgets would make to appearance. Then we could
> debate whether IDLE should look 'native' on each platform or have a
> common 'Python' theme -- or have both and let users choose.
>
> > If it's truly broken, then we should fix it.  If it's "broken"
> > because a feature is missing, maybe that's an intentional part of
> > Guido's design of a simple Python IDE.
>
> 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.

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.

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

Re: [Python-Dev] IDLE in the stdlib

[Glenn Linderman]

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


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.
___
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/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.

--
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] A 'common' respository? (was Re: IDLE in the stdlib)

[Philip James]

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

PJJ
http://philipjohnjames.com


On Wed, Mar 20, 2013 at 7:30 PM, Terry Reedy  wrote:

> On 3/20/2013 8:15 PM, Terry Reedy wrote:
>
>  I will discuss repository separation in another response
>>
>
> Here is a radical idea I have been toying with: set up a 'common'
> repository to 'factor out' files that are, could be, or should be the same
> across versions. The 'common' files would be declared (especially to
> packagers, when relevant) to be a part of each branch. Each release would
> (somehow - not my department) incorporate the latest version of everything
> in 'common'.
>
> What would go here?
>
> Misc/ACKS: the sensible idea that there should only be one copy of this
> file has been discussed before.
>
> LICENSE: I believe this is the same across current versions and must be
> edited in parallel for all future branches.
>
> xxx: others that I have not thought of.
>
> Doc/tools (sphinx and dependencies): setting this up separately but
> identically for each branch is a bit silly if it could be avoided. The
> sphinx versions should, of course, be the new one that runs on both python
> 2 and 3.
>
> idlelib: already discussed. Having only one IDLE version would partially
> speed up development.
>
> (surely controvesial) tkinter and _tkinter: I think the _tkinter and
> tkinter for each release should work with and be tested with the most
> recent tcl/tk release. Having only one tkinter version might make having
> one version of IDLE even easier.
>
> (probably even more controversial) tcl/tk (or at least the files needed to
> fetch and build - but as long as the sources are on python.org anyway,
> the sources could also be moved here from svn): For IDLE to really work the
> same across versions, it needs to run on the same tcl/tk version with the
> same bugfixes. For example, over a year ago, a French professor wrote
> python-list or idle-sig or maybe both saying that he would like to use IDLE
> in a class in Sept 2012, but there was a bug keeping it from working
> properly with French keyboards. He wanted to know if we were likely to fix
> it. The first answer (provided by Kevin Walzer) was that it was a tcl/tk
> bug that he (Kevin) was working on. The fix made it into 8.5.9 a year ago
> and hence into 3.3 but 2.7.3 or 3.2.3, released a month after the fix. So I
> later told him he could use IDLE, but, at least on Windows, only with the
> then upcoming 3.3. (I don't know the tcl/tk version policy for the
> non-Apple builds.)
>
> I do not know if tcl/tk 8.5.z releases have added many features or are
> primarily bugfixes like our micro releases. If the latter, the case for
> distributing at least the most recent 8.5.z with windows would seem pretty
> strong. I also do not know what 8.6.z adds. But an tcl/tk 'enhancement' of
> supporting astral characters might look like a bugfix for IDLE. (Running
> from IDLE, print(astral_char) raises, but I believe the same code works in
> some Linux interpreters.)
>
> yyy: any other external dependencies that we update on all versions.
>
> ---
> 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/**
> pjj%40philipjohnjames.com
>
___
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 8:38 PM, Neil Hodgson wrote:

Terry Reedy:


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


The limit is actually  lines.


I clicked Start / All programs / Python 3.3 / Python (command line)
>>> help(str)
 (several times)
and scrolled back up and the result was as I described. Help was gone 
above the 'c' methods. That is not  lines.


I believe I later specified 'as installed'. But you are right. If one 
knows to right click on the blue and yellow Python snake, select 
Properties, Layout, and find Screen Buffer Size and Height, then one can 
increase the miserly default of 300 to , at least on Win 7. 'Under a 
thousand lines' may be a vague memory from XP. I am also sure that with 
XP, the settings would revert for non-admin users after closing. Maybe 
MS did upgrade Command Prompt a bit.


Oh, but we are not done with the stupidity of Command Prompt. If one 
does set the buffer to  lines, it pads the output to  lines and 
shrinks the movable scroll bar down to an eighth inch. If you move it. 
say, 1/20 of the screen, you jump 500 lines, which initially is way past 
your actually output. The standard 'modern' convenience of dynamically 
resized buffers and bars, such as found in the nearly 20 year old 
Notepad, is not for CP. (There is an idea for MS: junk CP and re-build a 
modern version on top of Notepad.)


Setting properties by right clicking the icon is not standard on 
Windows. There is no help available from the window that I could find. I 
also could not find anything about the properties dialog in Windows 
help. If you can find an official entry for 'QuickEdit Mode' and 'Insert 
Mode', please let me know. Python Setup and Usage also says nothing 
about using the Command Prompt interpreter.


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

[Georg Brandl]

Am 21.03.2013 00:47, schrieb Barry Warsaw:
> On Mar 20, 2013, at 11:11 PM, Antoine Pitrou wrote:
> 
>>On Wed, 20 Mar 2013 15:05:40 -0700
>>Nick Coghlan  wrote:
>>> 
>>> Yes, the status quo of Idle is not something we should allow to
>>> continue indefinitely, but decisions about its future development
>>> should be made by active maintainers that are already trusted to make
>>> changes to it (such as Terry and Roger), rather than those of us that
>>> don't use it, and aren't interested in maintaining it.
>>
>>Definitely. People shouldn't remain quiescently torpid about the idle
>>status quo.
> 
> The release managers should have a say in the matter, since it does cause some
> amount of pain there.

I don't really understand what Antoine's "quiescently torpid" means, but
splitting IDLE out to a separate repo and then merging it back every time
a release rolls around sounds stupid.

Either split it off completely or develop it here (my preferred solution).
It's really not that hard to get CPython commit bits.

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] IDLE in the stdlib

[Terry Reedy]

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 20 open issues with smtp(lib) in the title. It is 37 kb,
making .54 issues per kb. For idlelib, with 786 kb, there are 104
issues, or .13 issues per kb, which is one fourth as many. I could
claim that smtplib, based on 1990s RFCs is much worse maintained. It
certainly could use somee positive attention.


Repeat: based on the 1990s RFCs, needing to be updated to the 2008 RFC, 
itself in the process of being superseded by a more unicode aware RFC.



You know better than I do that the number of open issues is not really
the only factor for determining the quality of a module.


And you should notice that I did not present that as the only factor for 
what I said I *could* claim. Actually, I think the comparison would be 
fairer if enhancements were not counted. I am pretty sure this would 
favor IDLE even more (depending on what one counted as a bug).


Let me repeat this question.

What IDE might be a simple, install and go, alternative to IDLE that I
might investigate, even if just as a source of ideas for IDLE?

> It should have the following features or something close:

* One-key saves the file and runs it with the -i option (enter
interactive mode after running the file) so one can enter additional
statements interactively.
* Syntax errors cause a message display; one click returns to the
spot the error was detected.
* Error tracebacks are displayed unmodified, without extra garbage
or censorship.
# Right click on a line like
  File "C:\Programs\Python33\lib\__difflib.py", line 1759, ...
and then left click on the goto popup to go to that line in that
file, opening the file if necessary.


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

[Devin Jeanpierre]

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.

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