From rovitotv at gmail.com  Mon Apr  1 13:54:49 2013
From: rovitotv at gmail.com (Todd Rovito)
Date: Mon, 1 Apr 2013 07:54:49 -0400
Subject: [Idle-dev] Feedback requested on issue 17609: IDLE: Remove config
 option 'editor on startup' and utilize command line options
Message-ID: <CALZ1apzDhzxJ-kC7q5ZbciGmO8hCagVVJ3s4VioXYjguW777tA@mail.gmail.com>

Greetings,
    Please take a look at issue 17609:
http://bugs.python.org/issue17609

We are thinking about removing the startup option to start a editor only on
startup and replace with the command line options only.  Please feel free
to comment on the issue directly on the issue tracker.  Thanks!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130401/9f46a950/attachment.html>

From francismb at email.de  Mon Apr  1 14:58:00 2013
From: francismb at email.de (francis)
Date: Mon, 01 Apr 2013 14:58:00 +0200
Subject: [Idle-dev] Feedback requested on issue 17609: IDLE: Remove
 config option 'editor on startup' and utilize command line options
In-Reply-To: <CALZ1apzDhzxJ-kC7q5ZbciGmO8hCagVVJ3s4VioXYjguW777tA@mail.gmail.com>
References: <CALZ1apzDhzxJ-kC7q5ZbciGmO8hCagVVJ3s4VioXYjguW777tA@mail.gmail.com>
Message-ID: <51598458.8090007@email.de>

Hi Todd,
> Greetings,
>     Please take a look at issue 17609:
> http://bugs.python.org/issue17609
>
> We are thinking about removing the startup option to start a editor 
> only on startup and replace with the command line options only. 
>  Please feel free to comment on the issue directly on the issue 
> tracker.  Thanks!!!
>
Just trying to list the actual ways / options to start the idle and how
it's expected to behave. Please feel free to change/expand
it:

"StartUp             "IDLE          "IDLE
Way/Option"          Editor"        interative"
------------------------------------------------

CLI idle -e           Yes            No
CLI idle -i           No             Yes
CLI idle              No             Yes
2-click .py           ?              ?
2-click idle.app      No             Yes
?

Regards,

francis


From Bruce_Sherwood at ncsu.edu  Mon Apr  1 17:45:38 2013
From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood)
Date: Mon, 1 Apr 2013 09:45:38 -0600
Subject: [Idle-dev] Feedback requested on issue 17609: IDLE: Remove
 config option 'editor on startup' and utilize command line options
In-Reply-To: <51598458.8090007@email.de>
References: <CALZ1apzDhzxJ-kC7q5ZbciGmO8hCagVVJ3s4VioXYjguW777tA@mail.gmail.com>
	<51598458.8090007@email.de>
Message-ID: <CAFDG03j1xg-2UjTu6ZoY+dySJiG+mOqVFAN0AqAt4x8azGA9gw@mail.gmail.com>

Unless this is somehow tied solely to running IDLE from a terminal, for my
purposes this is a terrible idea. For the thousands of students in our
intro physics curriculum who use VIDLE (which I hope eventually can be
replaced by using an updated IDLE), it is extremely important that starting
IDLE (by clicking on an icon) display only an edit window at startup. By
all means provide as many options in the config file as you like, but don't
take away the capability of configuring IDLE on startup to display only an
edit window.

If the change you propose doesn't make it impossible to configure IDLE to
start with only an edit window, then I don't care.


On Mon, Apr 1, 2013 at 6:58 AM, francis <francismb at email.de> wrote:

> Hi Todd,
>
>  Greetings,
>>     Please take a look at issue 17609:
>> http://bugs.python.org/**issue17609 <http://bugs.python.org/issue17609>
>>
>> We are thinking about removing the startup option to start a editor only
>> on startup and replace with the command line options only.  Please feel
>> free to comment on the issue directly on the issue tracker.  Thanks!!!
>>
>>  Just trying to list the actual ways / options to start the idle and how
> it's expected to behave. Please feel free to change/expand
> it:
>
> "StartUp             "IDLE          "IDLE
> Way/Option"          Editor"        interative"
> ------------------------------**------------------
>
> CLI idle -e           Yes            No
> CLI idle -i           No             Yes
> CLI idle              No             Yes
> 2-click .py           ?              ?
> 2-click idle.app      No             Yes
> ?
>
> Regards,
>
> francis
>
> ______________________________**_________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/**mailman/listinfo/idle-dev<http://mail.python.org/mailman/listinfo/idle-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130401/32efffd6/attachment.html>

From ether.joe at gmail.com  Wed Apr  3 05:57:41 2013
From: ether.joe at gmail.com (Sean Felipe Wolfe)
Date: Tue, 2 Apr 2013 20:57:41 -0700
Subject: [Idle-dev] noob questions about tkinter, tcl/tk, and wxpython
Message-ID: <CAOFf2a1jD-RVF+HC+O9ZsZSnGBi3LPgCoC9ny-j62KEQOVPhNA@mail.gmail.com>

So IDLE uses tkinter as its GUI toolkit yes? I was doing some reading
up and comparing with wxpython.

Tkinter was chosen because of simplicity? (Which seems like a good
reason). Is Tcl/tk still a relevant technology? Their website seems to
be active, soliciting students for the summer of code 2013, and lots
of advertising. What's the history between Tcl/Tk and Python?

Do we run into limitations using tkinter? Any particular annoyances?
Does it still seem like the best choice for a simple editor like IDLE?
Is tkinter a valid choice for modern GUI development or is it more of
a holdover?

As I intend get more into IDLE contributing, I'm just looking to get
more of a feel of what's going on behind the scences. I dig simple
approaches especially compared to some of the overly-complex systems I
have to work with on the day job :P

Thanks!

-- 
A musician must make music, an artist must paint, a poet must write,
if he is to be ultimately at peace with himself.
- Abraham Maslow

From rovitotv at gmail.com  Wed Apr  3 06:29:25 2013
From: rovitotv at gmail.com (Todd V Rovito)
Date: Wed, 3 Apr 2013 00:29:25 -0400
Subject: [Idle-dev] noob questions about tkinter, tcl/tk, and wxpython
In-Reply-To: <CAOFf2a1jD-RVF+HC+O9ZsZSnGBi3LPgCoC9ny-j62KEQOVPhNA@mail.gmail.com>
References: <CAOFf2a1jD-RVF+HC+O9ZsZSnGBi3LPgCoC9ny-j62KEQOVPhNA@mail.gmail.com>
Message-ID: <8059EE1B-04E4-433D-B6A0-069574B85A39@gmail.com>


On Apr 2, 2013, at 11:57 PM, Sean Felipe Wolfe <ether.joe at gmail.com> wrote:

> So IDLE uses tkinter as its GUI toolkit yes? I was doing some reading
> up and comparing with wxpython.
> 
> Tkinter was chosen because of simplicity? (Which seems like a good
> reason). Is Tcl/tk still a relevant technology? Their website seems to
> be active, soliciting students for the summer of code 2013, and lots
> of advertising. What's the history between Tcl/Tk and Python?
> 
> Do we run into limitations using tkinter? Any particular annoyances?
> Does it still seem like the best choice for a simple editor like IDLE?
> Is tkinter a valid choice for modern GUI development or is it more of
> a holdover?
> 
> As I intend get more into IDLE contributing, I'm just looking to get
> more of a feel of what's going on behind the scences. I dig simple
> approaches especially compared to some of the overly-complex systems I
> have to work with on the day job.
Sean,
   These are great questions!  First off Tkinter has been updated with themed widgets in ttk (http://docs.python.org/2/library/ttk.html). IDLE does not use ttk yet but perhaps in the future?  Tkinter has been Python's defacto GUI that ships with Python which is a good reason IDLE uses it.  Could IDLE be created with wxWidgets?  Sure but until Python ships with wxWidgets or something else there is not a point in changing IDLE.  My personal feeling is we should concentrate on IDLE bug fixing making it a great product.  Redesigns with ttk or wxWidgets should happen down the road.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130403/a4fb672a/attachment.html>

From rovitotv at gmail.com  Thu Apr 11 06:42:55 2013
From: rovitotv at gmail.com (Todd Rovito)
Date: Thu, 11 Apr 2013 00:42:55 -0400
Subject: [Idle-dev] Feedback/Suggestions on Google Summer of Code 2013 "IDLE
	Improvements"
Message-ID: <CALZ1apyCi+SkcBOH-=ngFoUrizuTKu=mqGdM-bnsotb12OQTRg@mail.gmail.com>

Greetings,
   I created a quick description, hence don't be surprised if you find
typos, of a project for Google Summer of Code 2013 for IDLE Improvements.
 Please help craft the project into a meaningful effort by supplying
feedback and suggestions:
http://wiki.python.org/moin/SummerOfCode/2013/python-core

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130411/b273283f/attachment.html>

From olivier.berger at telecom-sudparis.eu  Wed Apr 17 12:47:28 2013
From: olivier.berger at telecom-sudparis.eu (Olivier Berger)
Date: Wed, 17 Apr 2013 12:47:28 +0200
Subject: [Idle-dev] I18n of IDLE's interface ?
Message-ID: <87ip3lqvr3.fsf@inf-8657.int-evry.fr>

Hi.

I've filed a wishlist at : http://bugs.python.org/issue17760 about the
potential need for translated UI elements in IDLE. In our case, french
would be an example language.

It was suggested to me to forward the request to this list.

I hope this is not a FAQ (although I'd be surprised to be the first to
raise this need), as I haven't checked the list archives.

I'm sure some may object in the line of
http://bugs.python.org/issue17760#msg187088 but I find it a bit odd to
force this on users... which are free to set their system's locale to
english if they *do* want to force Python beginners to learn english.

FYI, we for example have the oportunity to teach Python to all students
in some classes in France (CPGE), and although they may have also some
honest english curriculum too, I'd expect their computers to have some
french locales, and the discrepency may look a bit surprising to some
(whether or not these english strings only makes Python look more or
less "sexy" is to be determined ;-).

I haven't investigated how IDLE handles UI elements, but could volunteer
for helping on translations to french of any messages in .po or likes,
of course.

Looking forward to your opinions,

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


From rovitotv at gmail.com  Wed Apr 17 13:45:37 2013
From: rovitotv at gmail.com (Todd V Rovito)
Date: Wed, 17 Apr 2013 07:45:37 -0400
Subject: [Idle-dev] I18n of IDLE's interface ?
In-Reply-To: <87ip3lqvr3.fsf@inf-8657.int-evry.fr>
References: <87ip3lqvr3.fsf@inf-8657.int-evry.fr>
Message-ID: <A1A77920-27A8-4377-AB64-AED94E8A3775@gmail.com>

On Apr 17, 2013, at 6:47 AM, Olivier Berger <olivier.berger at telecom-sudparis.eu> wrote:

> Hi.
> 
> I've filed a wishlist at : http://bugs.python.org/issue17760 about the
> potential need for translated UI elements in IDLE. In our case, french
> would be an example language.
> 
> It was suggested to me to forward the request to this list.
> 
> I hope this is not a FAQ (although I'd be surprised to be the first to
> raise this need), as I haven't checked the list archives.
> 
> I'm sure some may object in the line of
> http://bugs.python.org/issue17760#msg187088 but I find it a bit odd to
> force this on users... which are free to set their system's locale to
> english if they *do* want to force Python beginners to learn english.
> 
> FYI, we for example have the oportunity to teach Python to all students
> in some classes in France (CPGE), and although they may have also some
> honest english curriculum too, I'd expect their computers to have some
> french locales, and the discrepency may look a bit surprising to some
> (whether or not these english strings only makes Python look more or
> less "sexy" is to be determined ;-).
> 
> I haven't investigated how IDLE handles UI elements, but could volunteer
> for helping on translations to french of any messages in .po or likes,
> of course.
I think multi language support is a great idea but I have no idea how difficult implementation will be.  It is great that you have volunteered to help because we need all the help we can get.  I am a mentor for Google Summer of Code and perhaps I can add multi-language support as a stretch goal to the project.

http://wiki.python.org/moin/SummerOfCode/2013/python-core


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130417/73e8e0e5/attachment.html>

From roger.serwy at gmail.com  Wed Apr 17 16:36:28 2013
From: roger.serwy at gmail.com (Roger Serwy)
Date: Wed, 17 Apr 2013 09:36:28 -0500
Subject: [Idle-dev] I18n of IDLE's interface ?
In-Reply-To: <A1A77920-27A8-4377-AB64-AED94E8A3775@gmail.com>
References: <87ip3lqvr3.fsf@inf-8657.int-evry.fr>
	<A1A77920-27A8-4377-AB64-AED94E8A3775@gmail.com>
Message-ID: <516EB36C.5070501@gmail.com>

On 04/17/2013 06:45 AM, Todd V Rovito wrote:
> On Apr 17, 2013, at 6:47 AM, Olivier Berger 
> <olivier.berger at telecom-sudparis.eu 
> <mailto:olivier.berger at telecom-sudparis.eu>> wrote:
>
>> Hi.
>>
>> I've filed a wishlist at : http://bugs.python.org/issue17760 about the
>> potential need for translated UI elements in IDLE. In our case, french
>> would be an example language.
>>
>> It was suggested to me to forward the request to this list.
>>
>> I hope this is not a FAQ (although I'd be surprised to be the first to
>> raise this need), as I haven't checked the list archives.
>>
>> I'm sure some may object in the line of
>> http://bugs.python.org/issue17760#msg187088 but I find it a bit odd to
>> force this on users... which are free to set their system's locale to
>> english if they *do* want to force Python beginners to learn english.
>>
>> FYI, we for example have the oportunity to teach Python to all students
>> in some classes in France (CPGE), and although they may have also some
>> honest english curriculum too, I'd expect their computers to have some
>> french locales, and the discrepency may look a bit surprising to some
>> (whether or not these english strings only makes Python look more or
>> less "sexy" is to be determined ;-).
>>
>> I haven't investigated how IDLE handles UI elements, but could volunteer
>> for helping on translations to french of any messages in .po or likes,
>> of course.
> I think multi language support is a great idea but I have no idea how 
> difficult implementation will be.  It is great that you have 
> volunteered to help because we need all the help we can get.  I am a 
> mentor for Google Summer of Code and perhaps I can add multi-language 
> support as a stretch goal to the project.
>
> http://wiki.python.org/moin/SummerOfCode/2013/python-core
>

There is a project on Sourceforge that translated IDLE into Turkish, but 
I haven't tried it yet: http://sourceforge.net/projects/pyidlelif/

IDLE has a lot of hard-coded phrases scattered throughout the code. It's 
perfectly doable to add multi-language support. However, keep in mind 
that Tk itself has a problem with non-BMP unicode characters. See 
http://bugs.python.org/issue14200 which provided a work-around.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130417/06802de0/attachment.html>

From olivier.berger at telecom-sudparis.eu  Wed Apr 17 18:18:47 2013
From: olivier.berger at telecom-sudparis.eu (Olivier Berger)
Date: Wed, 17 Apr 2013 18:18:47 +0200
Subject: [Idle-dev] I18n of IDLE's interface ?
In-Reply-To: <516EB36C.5070501@gmail.com>
References: <87ip3lqvr3.fsf@inf-8657.int-evry.fr>
	<A1A77920-27A8-4377-AB64-AED94E8A3775@gmail.com>
	<516EB36C.5070501@gmail.com>
Message-ID: <878v4hqgew.fsf@inf-8657.int-evry.fr>

Roger Serwy <roger.serwy at gmail.com> writes:

>
> There is a project on Sourceforge that translated IDLE into Turkish, but 
> I haven't tried it yet: http://sourceforge.net/projects/pyidlelif/
>

I can't read turkish, but this looks to me like a fork of the code
(seing plenty of turkish phrases in comments or strings) :-/

> IDLE has a lot of hard-coded phrases scattered throughout the code. It's 
> perfectly doable to add multi-language support. However, keep in mind 
> that Tk itself has a problem with non-BMP unicode characters. See 
> http://bugs.python.org/issue14200 which provided a work-around.
>

OK, I guess that for a start and my immediate needs for french language,
this shouldn't be a problem.

It looks like Damien Mari? has started with a solution based on gettext
that looks nice to me, even though I'm not so much anymore a Python
expert : http://bugs.python.org/issue17776

After a few tests, it looks like I can translate messages in a .po file
and get them displayed in french in the menus on the 2.7 branch :-)

Looks promising :-)

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

From tjreedy at udel.edu  Wed Apr 17 22:40:33 2013
From: tjreedy at udel.edu (Terry Jan Reedy)
Date: Wed, 17 Apr 2013 16:40:33 -0400
Subject: [Idle-dev] I18n of IDLE's interface ?
In-Reply-To: <87ip3lqvr3.fsf@inf-8657.int-evry.fr>
References: <87ip3lqvr3.fsf@inf-8657.int-evry.fr>
Message-ID: <kkn1bp$bm7$1@ger.gmane.org>

On 4/17/2013 6:47 AM, Olivier Berger wrote:
> I've filed a wishlist at : http://bugs.python.org/issue17760 about the
> potential need for translated UI elements in IDLE. In our case, french
> would be an example language.
>
> It was suggested to me to forward the request to this list.

That was my suggestiion. Thank you for paying attention ;-).

> I hope this is not a FAQ (although I'd be surprised to be the first to
> raise this need), as I haven't checked the list archives.

Internationalization has been an issue, and a controversial one, for at 
least a decade. Let's categorize things that could be translated to 
reach more people.

For Python itself, there are the keywords (about 25), the builtin names 
(< 100), the stdlib module names (a few hundred), the names within 
stdlib modules (a few tens of thousands), docstrings, the tutorial, the 
other manuals, and let us not forget, the tracebacks, exception names, 
and exception messages.

For the community, there are mailing lists, web pages, and books 
(already done as people have taken the initiative to do so).\

For Idle, there is the UI and the belp page. The help page is currently 
a text file separate from the manual. There is an issue to synchronize 
the help file with the maunal chapter and then just use the manual 
chapter. Even when that is done, we could have a mechanism to grab 
translations of the manual chapter. I would be fine with that if there 
was a commitment from someone to do at least one translation.

> I'm sure some may object in the line of
> http://bugs.python.org/issue17760#msg187088 but I find it a bit odd to
> force this on users... which are free to set their system's locale to
> english if they *do* want to force Python beginners to learn english.

There are various reasons people oppose Il8n. Some apply to some 
categories more than others. I am sure you will appreciate some more 
than others.

1. Inertia: if it doesn't seem broke to me, why fix it?
2a. Self-interest 1: why should I help people write code that I cannot 
read or use?
2b. Self-interest 2: Why should we make the code base harder to maintain?
3. Visceral: I survived English, others can too.
4. Concern: programming, especially Python programming is international; 
a complete translation of everything will box people in national 
ghettos; this is ultimately a disservice to learners.
5a. Practicality 1: all the categories above are changing targets, 
nothing is fixed; all translations become obsolete sooner or later.
5b. Practicality 2: there is too much to translate everything; even if, 
for instance, keyword and builtin names were translated to native words 
and characters, people would still have to learn Latin characters to use 
the stdlib and read tracebacks and error messages.
6. Freedom: Python is given out freely; people are free to modify it 
with few restrictions; the core devs need not be involved.
7. A lack of volunteers to do the extra work required.

Point 2 lead some to object to allowing general unicode identifies even 
in Python 3.

'Moving targets' are a real concern. For instance, the 2.7 Tutorial is 
available in Spanish, but the last I knew, no 3.x Tutorial was, thus 
tending to tie Spanish-only Python users to Python 2.

> FYI, we for example have the oportunity to teach Python to all students
> in some classes in France (CPGE), and although they may have also some
> honest english curriculum too, I'd expect their computers to have some
> french locales, and the discrepency may look a bit surprising to some
> (whether or not these english strings only makes Python look more or
> less "sexy" is to be determined ;-).

Many of the objections above do not apply very much to Idle. I would 
expect that even some of the core devs use apps with non-English 
native-word menus. I think learning the keywords and a subset of builtin 
names (perhaps 50 total) is enough for a first Python course.

> I haven't investigated how IDLE handles UI elements, but could volunteer
> for helping on translations to french of any messages in .po or likes,

You have not specified which items you would translate. The File...Help 
menus? Right-context menus? Dialog boxes? Error-message boxes? Various 
help items? All of the above? Would only translating some elements be 
worthwhile?

There are people who think string literals should be collected together, 
separate from the code that uses them, where they can be easily found 
and modified, and not scattered about and hard-coded into expressions. 
But the latter can be easier in some cases.

Suppose, hypothetically, that Idle has a line like
     ErrBox("ConfigError: bad value")
Then someone posts an issue requesting that the error message be made 
more informative. With the hard-coded string, it is a simple fix:
     ErrBox("FileError: bad value {} for {} in {}".
         format(value, item, config_file))
It is easy to see that the format string and the format call match.

But if the string literal is elsewhere, the fixer has to go find it and 
fix whereever it is, complicating the patch.. It is no longer easy to 
see that the format string and format() call match.

If there are translations, the translations no longer work; instead they 
raise format string errors. So each translation has to be patched by the 
translator and tested before each release. Are you volunteering to do 
that for at least 5 years?

Of course, proper testing would mean having automated tests that causing 
each possible error to be raised. We should have that, but do not now. 
We would need to have that before separating format strings and format 
calls, even without translations.

Bottom line: a multilingual app is not trivial. Corporations pay people 
to attend to all the picky details.

> Looking forward to your opinions,

I would rather have people learn Python using Il*n'ized Idle than not at 
all. I would rather beginners struggle with Python itself than with the 
Idle interface.

--
Terry Jan Reedy



From tjreedy at udel.edu  Wed Apr 17 22:54:56 2013
From: tjreedy at udel.edu (Terry Jan Reedy)
Date: Wed, 17 Apr 2013 16:54:56 -0400
Subject: [Idle-dev] I18n of IDLE's interface ?
In-Reply-To: <kkn1bp$bm7$1@ger.gmane.org>
References: <87ip3lqvr3.fsf@inf-8657.int-evry.fr> <kkn1bp$bm7$1@ger.gmane.org>
Message-ID: <kkn26o$l3c$1@ger.gmane.org>

On 4/17/2013 4:40 PM, Terry Jan Reedy wrote:
> On 4/17/2013 6:47 AM, Olivier Berger wrote:
>> I've filed a wishlist at : http://bugs.python.org/issue17760 about the
>> potential need for translated UI elements in IDLE. In our case, french
>> would be an example language.
>>
>> It was suggested to me to forward the request to this list.
>
> That was my suggestiion. Thank you for paying attention ;-).
>
>> I hope this is not a FAQ (although I'd be surprised to be the first to
>> raise this need), as I haven't checked the list archives.
>
> Internationalization has been an issue, and a controversial one, for at
> least a decade. Let's categorize things that could be translated to
> reach more people.
>
> For Python itself, there are the keywords (about 25), the builtin names
> (< 100), the stdlib module names (a few hundred), the names within
> stdlib modules (a few tens of thousands), docstrings, the tutorial, the
> other manuals, and let us not forget, the tracebacks, exception names,
> and exception messages.
>
> For the community, there are mailing lists, web pages, and books
> (already done as people have taken the initiative to do so).\
>
> For Idle, there is the UI and the belp page. The help page is currently
> a text file separate from the manual. There is an issue to synchronize
> the help file with the maunal chapter and then just use the manual
> chapter. Even when that is done, we could have a mechanism to grab
> translations of the manual chapter. I would be fine with that if there
> was a commitment from someone to do at least one translation.
>
>> I'm sure some may object in the line of
>> http://bugs.python.org/issue17760#msg187088 but I find it a bit odd to
>> force this on users... which are free to set their system's locale to
>> english if they *do* want to force Python beginners to learn english.
>
> There are various reasons people oppose Il8n. Some apply to some
> categories more than others. I am sure you will appreciate some more
> than others.
>
> 1. Inertia: if it doesn't seem broke to me, why fix it?
> 2a. Self-interest 1: why should I help people write code that I cannot
> read or use?
> 2b. Self-interest 2: Why should we make the code base harder to maintain?
> 3. Visceral: I survived English, others can too.
> 4. Concern: programming, especially Python programming is international;
> a complete translation of everything will box people in national
> ghettos; this is ultimately a disservice to learners.
> 5a. Practicality 1: all the categories above are changing targets,
> nothing is fixed; all translations become obsolete sooner or later.
> 5b. Practicality 2: there is too much to translate everything; even if,
> for instance, keyword and builtin names were translated to native words
> and characters, people would still have to learn Latin characters to use
> the stdlib and read tracebacks and error messages.
> 6. Freedom: Python is given out freely; people are free to modify it
> with few restrictions; the core devs need not be involved.
> 7. A lack of volunteers to do the extra work required.
>
> Point 2 lead some to object to allowing general unicode identifies even
> in Python 3.
>
> 'Moving targets' are a real concern. For instance, the 2.7 Tutorial is
> available in Spanish, but the last I knew, no 3.x Tutorial was, thus
> tending to tie Spanish-only Python users to Python 2.
>
>> FYI, we for example have the oportunity to teach Python to all students
>> in some classes in France (CPGE), and although they may have also some
>> honest english curriculum too, I'd expect their computers to have some
>> french locales, and the discrepency may look a bit surprising to some
>> (whether or not these english strings only makes Python look more or
>> less "sexy" is to be determined ;-).
>
> Many of the objections above do not apply very much to Idle. I would
> expect that even some of the core devs use apps with non-English
> native-word menus. I think learning the keywords and a subset of builtin
> names (perhaps 50 total) is enough for a first Python course.
>
>> I haven't investigated how IDLE handles UI elements, but could volunteer
>> for helping on translations to french of any messages in .po or likes,
>
> You have not specified which items you would translate. The File...Help
> menus? Right-context menus? Dialog boxes? Error-message boxes? Various
> help items? All of the above? Would only translating some elements be
> worthwhile?
>
> There are people who think string literals should be collected together,
> separate from the code that uses them, where they can be easily found
> and modified, and not scattered about and hard-coded into expressions.
> But the latter can be easier in some cases.
>
> Suppose, hypothetically, that Idle has a line like
>      ErrBox("ConfigError: bad value")
> Then someone posts an issue requesting that the error message be made
> more informative. With the hard-coded string, it is a simple fix:
>      ErrBox("FileError: bad value {} for {} in {}".
>          format(value, item, config_file))
> It is easy to see that the format string and the format call match.
>
> But if the string literal is elsewhere, the fixer has to go find it and
> fix whereever it is, complicating the patch.. It is no longer easy to
> see that the format string and format() call match.

Looking at the patch at http://bugs.python.org/issue17776
I see that the gettext mechanism leaves the string where it is, just 
enclosing it in _(...), so the above is not an issue.

> If there are translations, the translations no longer work; instead they
> raise format string errors. So each translation has to be patched by the
> translator and tested before each release. Are you volunteering to do
> that for at least 5 years?
>
> Of course, proper testing would mean having automated tests that causing
> each possible error to be raised. We should have that, but do not now.
> We would need to have that before separating format strings and format
> calls, even without translations.
>
> Bottom line: a multilingual app is not trivial. Corporations pay people
> to attend to all the picky details.
>
>> Looking forward to your opinions,
>
> I would rather have people learn Python using Il*n'ized Idle than not at
> all. I would rather beginners struggle with Python itself than with the
> Idle interface.
>
> --
> Terry Jan Reedy



From tjreedy at udel.edu  Thu Apr 18 05:18:35 2013
From: tjreedy at udel.edu (Terry Jan Reedy)
Date: Wed, 17 Apr 2013 23:18:35 -0400
Subject: [Idle-dev] I18n of IDLE's interface ?
In-Reply-To: <kkn26o$l3c$1@ger.gmane.org>
References: <87ip3lqvr3.fsf@inf-8657.int-evry.fr> <kkn1bp$bm7$1@ger.gmane.org>
	<kkn26o$l3c$1@ger.gmane.org>
Message-ID: <kknom3$4fq$1@ger.gmane.org>

On 4/17/2013 4:54 PM, Terry Jan Reedy wrote:
[snip]
> Looking at the patch at http://bugs.python.org/issue17776
[snip]
This patch appears to solve the chicken and egg problem* by providing an 
initial egg. (It is useless to add Il8n facility if there are no 
translation files to use it. It is useless to write a translation file 
if the is no facility to use it.) I thought about it and posted a fairly 
long review with questions. My conclusion is this:

"Perhaps there should be an IdleIl8n project on PyPI. In fact, such a 
project could be done without 'official' cooperation. If indeed there is 
no such project, I would wonder whether such absence indicates an 
absence of need. Or is it knowledge of how? Testing something as a 3rd 
party distribution and getting community acceptance is one normal way 
for things to get added to the stdlib."

This list would be an appropriate place to discuss such a project, at 
least for now, should Olivier and anyone else wish to pursue it.

-- 
Terry Jan Reedy



From olivier.berger at telecom-sudparis.eu  Thu Apr 18 11:20:10 2013
From: olivier.berger at telecom-sudparis.eu (Olivier Berger)
Date: Thu, 18 Apr 2013 11:20:10 +0200
Subject: [Idle-dev] I18n of IDLE's interface ?
In-Reply-To: <kkn1bp$bm7$1@ger.gmane.org>
References: <87ip3lqvr3.fsf@inf-8657.int-evry.fr> <kkn1bp$bm7$1@ger.gmane.org>
Message-ID: <87ehe819h1.fsf@inf-8657.int-evry.fr>

Hi.

Thanks of the detailed argumentation. But I feel it is going a bit too
far, wrt to IDLE and my initial query. Just responding quickly below to
a few elements. I'm not an i18n expert no an IDLE developer, so, this is
just MHO.

Terry Jan Reedy <tjreedy at udel.edu> writes:

> On 4/17/2013 6:47 AM, Olivier Berger wrote:

>> I hope this is not a FAQ (although I'd be surprised to be the first to
>> raise this need), as I haven't checked the list archives.
>
> Internationalization has been an issue, and a controversial one, for at 
> least a decade. Let's categorize things that could be translated to 
> reach more people.
>
> For Python itself, there are the keywords (about 25), the builtin names 
> (< 100), the stdlib module names (a few hundred), the names within 
> stdlib modules (a few tens of thousands), docstrings, the tutorial, the 
> other manuals, and let us not forget, the tracebacks, exception names, 
> and exception messages.
>
> For the community, there are mailing lists, web pages, and books 
> (already done as people have taken the initiative to do so).\
>
> For Idle, there is the UI and the belp page. The help page is currently 
> a text file separate from the manual. There is an issue to synchronize 
> the help file with the maunal chapter and then just use the manual 
> chapter. Even when that is done, we could have a mechanism to grab 
> translations of the manual chapter. I would be fine with that if there 
> was a commitment from someone to do at least one translation.
>

My main concern for the moment is the Menus and other "higher" elements
of UI, and not internationalization of Python as a whole.

Let's Keep It Simple Stupid for a start ;)

>> I'm sure some may object in the line of
>> http://bugs.python.org/issue17760#msg187088 but I find it a bit odd to
>> force this on users... which are free to set their system's locale to
>> english if they *do* want to force Python beginners to learn english.
>
> There are various reasons people oppose Il8n. Some apply to some 
> categories more than others. I am sure you will appreciate some more 
> than others.
>

SNIP

>
> Many of the objections above do not apply very much to Idle. I would 
> expect that even some of the core devs use apps with non-English 
> native-word menus. I think learning the keywords and a subset of builtin 
> names (perhaps 50 total) is enough for a first Python course.
>

I'll not (feed the troll ;-) respond on all aspects (interesting
discussion in general, but not specific to IDLE, I guess, and... maybe
that looks to me like beating a dead horse somehow).

My main goal, again, is just to avoid the kind of discrepency one could
notice when running IDLE next to other GUI tools (editors, text
processors, etc.) on most desktop envs where menus and dialogs are
internationalized.

I want to diminish the cognitive overhead of looking for a way to save a
program to the computer for beginners.

If others aren't interested by this issue, fine with me, but I just
expect them to not refuse patches that would address such an issue.

>> I haven't investigated how IDLE handles UI elements, but could volunteer
>> for helping on translations to french of any messages in .po or likes,
>
> You have not specified which items you would translate. The File...Help 
> menus? Right-context menus? Dialog boxes? Error-message boxes? Various 
> help items? All of the above? Would only translating some elements be 
> worthwhile?

Yes, as many of these, with an order of priority that looks fine to me at
first sight.

SNIP

>> Looking forward to your opinions,
>
> I would rather have people learn Python using Il*n'ized Idle than not at 
> all. I would rather beginners struggle with Python itself than with the 
> Idle interface.
>

Exactly my idea... but maybe i18n isn't a problem after all... I'm just
starting the teaching process, so maybe not a big deal... still, I think
it can't harm caring for IDLE's i18n.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

From olivier.berger at telecom-sudparis.eu  Thu Apr 18 11:28:20 2013
From: olivier.berger at telecom-sudparis.eu (Olivier Berger)
Date: Thu, 18 Apr 2013 11:28:20 +0200
Subject: [Idle-dev] I18n of IDLE's interface ?
In-Reply-To: <kknom3$4fq$1@ger.gmane.org>
References: <87ip3lqvr3.fsf@inf-8657.int-evry.fr> <kkn1bp$bm7$1@ger.gmane.org>
	<kkn26o$l3c$1@ger.gmane.org> <kknom3$4fq$1@ger.gmane.org>
Message-ID: <87bo9c193f.fsf@inf-8657.int-evry.fr>

Terry Jan Reedy <tjreedy at udel.edu> writes:

> On 4/17/2013 4:54 PM, Terry Jan Reedy wrote:
> [snip]
>> Looking at the patch at http://bugs.python.org/issue17776
> [snip]
> This patch appears to solve the chicken and egg problem* by providing an 
> initial egg. (It is useless to add Il8n facility if there are no 
> translation files to use it. It is useless to write a translation file 
> if the is no facility to use it.) I thought about it and posted a fairly 
> long review with questions. My conclusion is this:
>
> "Perhaps there should be an IdleIl8n project on PyPI. In fact, such a 
> project could be done without 'official' cooperation. If indeed there is 
> no such project, I would wonder whether such absence indicates an 
> absence of need. Or is it knowledge of how? Testing something as a 3rd 
> party distribution and getting community acceptance is one normal way 
> for things to get added to the stdlib."
>

I'm not so sure I get your point, but usually, things proceed as such in
all FLOSS projects I know about that use the gettext standard : the core
devs replace plaing strings by their _("...") counterparts, and let
contributors (translators, sometimes organized in teams), provide the
translations for these, as .po files. There may also at times be the
need for a translation manager [0] coordinating contributions of
translators who may not be tech-savvy.

Then the compiled .mo files are distributed in the archive by the devs,
with some freeze periods before releases, that provide time for
translators to update the message translations up to the state of the
source.

This is fairly usual, and without knowledge of the Python or IDLE
dev/release process, I don't really see why such a common process
couldn't apply here.

> This list would be an appropriate place to discuss such a project, at 
> least for now, should Olivier and anyone else wish to pursue it.
>

In any case, to avoid duplication, I hereby volunteer for providing an
initial fr.po file, once the patch adding the _("") will have been
finalized (coordinated through http://bugs.python.org/issue17776 ?).

Best regards,

[0] http://producingoss.com/en/share-management.html#translation-manager
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

From damienlog at gmail.com  Thu Apr 18 13:30:51 2013
From: damienlog at gmail.com (Damien)
Date: Thu, 18 Apr 2013 13:30:51 +0200
Subject: [Idle-dev] I18n of IDLE's interface ?
In-Reply-To: <87bo9c193f.fsf@inf-8657.int-evry.fr>
References: <87ip3lqvr3.fsf@inf-8657.int-evry.fr> <kkn1bp$bm7$1@ger.gmane.org>
	<kkn26o$l3c$1@ger.gmane.org> <kknom3$4fq$1@ger.gmane.org>
	<87bo9c193f.fsf@inf-8657.int-evry.fr>
Message-ID: <CAAQ5yijmB-PSWL8wpatjGZgAdA+V89nBxhQsbA_oT8NTNZ5e+Q@mail.gmail.com>

Hi,

I'm Damien MARIE, the patch author of http://bugs.python.org/issue17776

I think adding _(..) add a negligeable overhead on the code but a practical
enchancement for many reasons : teaching kids and language consistency for
the user mainly.

The translation files aren't in the idle dir, but in a special local dir of
the user (see gettext doc).

Also I've add (but it's not in this patch) an option in idle config to
disable i18n (for unit-testing for example or to overhead the system
locale) but also to make it a disabled setting by default until the
translation environment is mature.

Should I add this setting to the config dialog ? ("Enable localisation" for
example).

I think I will just translate the menu, the context menu and the dialogs
for now. (except some dialog like the About Dialog). Anyway, you will see
that in my patch.

Damien

2013/4/18 Olivier Berger <olivier.berger at telecom-sudparis.eu>

> Terry Jan Reedy <tjreedy at udel.edu> writes:
>
> > On 4/17/2013 4:54 PM, Terry Jan Reedy wrote:
> > [snip]
> >> Looking at the patch at http://bugs.python.org/issue17776
> > [snip]
> > This patch appears to solve the chicken and egg problem* by providing an
> > initial egg. (It is useless to add Il8n facility if there are no
> > translation files to use it. It is useless to write a translation file
> > if the is no facility to use it.) I thought about it and posted a fairly
> > long review with questions. My conclusion is this:
> >
> > "Perhaps there should be an IdleIl8n project on PyPI. In fact, such a
> > project could be done without 'official' cooperation. If indeed there is
> > no such project, I would wonder whether such absence indicates an
> > absence of need. Or is it knowledge of how? Testing something as a 3rd
> > party distribution and getting community acceptance is one normal way
> > for things to get added to the stdlib."
> >
>
> I'm not so sure I get your point, but usually, things proceed as such in
> all FLOSS projects I know about that use the gettext standard : the core
> devs replace plaing strings by their _("...") counterparts, and let
> contributors (translators, sometimes organized in teams), provide the
> translations for these, as .po files. There may also at times be the
> need for a translation manager [0] coordinating contributions of
> translators who may not be tech-savvy.
>
> Then the compiled .mo files are distributed in the archive by the devs,
> with some freeze periods before releases, that provide time for
> translators to update the message translations up to the state of the
> source.
>
> This is fairly usual, and without knowledge of the Python or IDLE
> dev/release process, I don't really see why such a common process
> couldn't apply here.
>
> > This list would be an appropriate place to discuss such a project, at
> > least for now, should Olivier and anyone else wish to pursue it.
> >
>
> In any case, to avoid duplication, I hereby volunteer for providing an
> initial fr.po file, once the patch adding the _("") will have been
> finalized (coordinated through http://bugs.python.org/issue17776 ?).
>
> Best regards,
>
> [0] http://producingoss.com/en/share-management.html#translation-manager
> --
> Olivier BERGER
> http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id:
> 2048R/5819D7E8
> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130418/c2632022/attachment.html>

From raajjya at gmail.com  Sat Apr 20 03:41:32 2013
From: raajjya at gmail.com (Jayakrishnan Rajagopalasarma)
Date: Sat, 20 Apr 2013 07:11:32 +0530
Subject: [Idle-dev] [GSoc- 2013]: UnitTest Framework and Pep8 Integration
	for Idle
Message-ID: <CAEniZVjU_95Vkoc-BPBj0OKZoX8-_t1-iw5z7gdTAkxSRR_h-A@mail.gmail.com>

hi,
*I am moving on with IDLE Improvements project for GSoc 2013, from
University of Moratuwa, Sri Lanka, final year undergraduate. Hope I can
contribute something with the bit of my knowledge, gained from my 8 months
internship with python project for a commercial tool.*
*After struggled with python build missing issue of tkinter, (which does
not allow idle to open in development environment), resolved it with
installing tk-dev and configure, make again*.

1. Considering on unit-test framework for IDLE
thread<http://bugs.python.org/issue15392>,
here is what I got,

   - There is a need of a proper design in whether to put tests in test
   sub directory or to create idlelib/test directory and also
   the unit-tests in *unittest/test dir.*
   - Focus on non-GUI test for now.

2. I am planing to go with best practices with put tests in test/test_idle
like test/test_email.
(Seems like issue #10652 <http://bugs.python.org/issue10652> in this
message<http://bugs.python.org/issue15392#msg165889>is on a healthy
patch
review, so it would actually run with -m tes )
Hope I am on the right track, correct me if not.

3. I think the best starting point will be with a patch on

   - moving the already available test (
   http://bugs.python.org/file27613/issue16226_test.patch) into this
   directory,
   - and test for the presence of idle and skip if idle is not available.

Expecting suggestions and improvements on my thoughts.





*"Think big, Start Small, Move Fast"*

Thanks && Regards..
R. Jayakrishnan



<https://www.facebook.com/raajjya>
<https://plus.google.com/u/0/114501383949013359988/posts>
  <https://plus.google.com/u/0/114501383949013359988/posts>
<http://www.linkedin.com/profile/view?id=92231015&trk=tab_pro>
  <http://www.gmail.com>  <https://twitter.com/#!/raajjya>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130420/ce18d3c4/attachment.html>

From tomo832 at gmail.com  Sat Apr 20 12:08:58 2013
From: tomo832 at gmail.com (Tomoki Imai)
Date: Sat, 20 Apr 2013 19:08:58 +0900
Subject: [Idle-dev] Missing unittest.mock in Python2 world be problem in
 making unitest for IDLE.
Message-ID: <CAE-36Mbrk58Mf6EJG6KgBja_2J+HKWqzemXj_-95rOJYRegB7g@mail.gmail.com>

Hi.

I'm a student thinking of participating in Google Summer of Code.
And I'm looking for a guidance.
The proposal that I want to make is "Unit Test framework for IDLE".
http://wiki.python.org/moin/SummerOfCode/2013/python-core

I emailed to Todd Rovito and read idlelib for a while,read following link.
http://bugs.python.org/issue15392
I posted there too.

Using unittest.mock seemed to be good way to test GUI.
But there is a problem.
There is no unittest.mock in Python2.
http://docs.python.org/2/library/unittest.html

I think using third party mock seemed to be ok, but not best way.
https://pypi.python.org/pypi/mock
Because, IDLE is a part of official python.
I think relying on third party module is not good.

Do you have any advice?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130420/b3dbd1fe/attachment.html>

From tomo832 at gmail.com  Sun Apr 21 18:47:29 2013
From: tomo832 at gmail.com (Tomoki Imai)
Date: Mon, 22 Apr 2013 01:47:29 +0900
Subject: [Idle-dev] Unicode Literal in IDLE. (python2)
Message-ID: <CAE-36MZVGodk225S3VAy=Ppv5YbLLe7mM0rL_LH=iNTYneKnGw@mail.gmail.com>

Hi.

I found bug (I think) in IDLE.
That is, unicode literal in IDLE.
You can reconfirm it by executing following code in IDLE.

>> u"?????"
u'\xe3\x81\x93\xe3\x82\x93\xe3\x81\xab\xe3\x81\xa1\xe3\x81\xaf'
("?????" means hello in Japanese.It's unicode literal.)

In normal Interpreter ( running in console)

>> u"?????"
u'\u3053\u3093\u306b\u3061\u306f'

I found a solution.
I posted here.But I found it was closed after I posted.
http://bugs.python.org/issue17348

Can I reopen it?Or, this is not bug?

Thanks for your helping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130422/00aef2b5/attachment.html>

From andrew.svetlov at gmail.com  Sun Apr 21 22:20:20 2013
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Sun, 21 Apr 2013 23:20:20 +0300
Subject: [Idle-dev] Unicode Literal in IDLE. (python2)
In-Reply-To: <CAE-36MZVGodk225S3VAy=Ppv5YbLLe7mM0rL_LH=iNTYneKnGw@mail.gmail.com>
References: <CAE-36MZVGodk225S3VAy=Ppv5YbLLe7mM0rL_LH=iNTYneKnGw@mail.gmail.com>
Message-ID: <CAL3CFcUmMPaWn+Uc=3oOwsduQtgOweQv7LDTXHLNXed7cON8Yw@mail.gmail.com>

I think fixing this bug for python 2 can open a can of worms. Python 3
works correctly IIRC.

On Sun, Apr 21, 2013 at 7:47 PM, Tomoki Imai <tomo832 at gmail.com> wrote:
> Hi.
>
> I found bug (I think) in IDLE.
> That is, unicode literal in IDLE.
> You can reconfirm it by executing following code in IDLE.
>
>>> u"?????"
> u'\xe3\x81\x93\xe3\x82\x93\xe3\x81\xab\xe3\x81\xa1\xe3\x81\xaf'
> ("?????" means hello in Japanese.It's unicode literal.)
>
> In normal Interpreter ( running in console)
>
>>> u"?????"
> u'\u3053\u3093\u306b\u3061\u306f'
>
> I found a solution.
> I posted here.But I found it was closed after I posted.
> http://bugs.python.org/issue17348
>
> Can I reopen it?Or, this is not bug?
>
> Thanks for your helping.
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev
>



-- 
Thanks,
Andrew Svetlov

From tjreedy at udel.edu  Mon Apr 22 04:02:10 2013
From: tjreedy at udel.edu (Terry Jan Reedy)
Date: Sun, 21 Apr 2013 22:02:10 -0400
Subject: [Idle-dev] Unicode Literal in IDLE. (python2)
In-Reply-To: <CAL3CFcUmMPaWn+Uc=3oOwsduQtgOweQv7LDTXHLNXed7cON8Yw@mail.gmail.com>
References: <CAE-36MZVGodk225S3VAy=Ppv5YbLLe7mM0rL_LH=iNTYneKnGw@mail.gmail.com>
	<CAL3CFcUmMPaWn+Uc=3oOwsduQtgOweQv7LDTXHLNXed7cON8Yw@mail.gmail.com>
Message-ID: <kl25ml$ls1$1@ger.gmane.org>

On 4/21/2013 4:20 PM, Andrew Svetlov wrote:
> I think fixing this bug for python 2 can open a can of worms. Python 3
> works correctly IIRC.
>
> On Sun, Apr 21, 2013 at 7:47 PM, Tomoki Imai <tomo832 at gmail.com> wrote:
>> Hi.
>>
>> I found bug (I think) in IDLE.
>> That is, unicode literal in IDLE.
>> You can reconfirm it by executing following code in IDLE.
>>
>>>> u"?????"
>> u'\xe3\x81\x93\xe3\x82\x93\xe3\x81\xab\xe3\x81\xa1\xe3\x81\xaf'
>> ("?????" means hello in Japanese.It's unicode literal.)
>>
>> In normal Interpreter ( running in console)
>>
>>>> u"?????"
>> u'\u3053\u3093\u306b\u3061\u306f'
>>
>> I found a solution.
>> I posted here.But I found it was closed after I posted.

To be clearer, it was closed a March 8.

>> http://bugs.python.org/issue17348
>>
>> Can I reopen it?Or, this is not bug?

David reopened, but like Andrew, I am wary. One reason we made unicode 
the text type in Python 3 was that patching the Python 2 dual-text 
system became a bit like playing Whack-A-Mole
http://en.wikipedia.org/wiki/Whac-A-Mole



From tomo832 at gmail.com  Mon Apr 22 14:03:12 2013
From: tomo832 at gmail.com (Tomoki Imai)
Date: Mon, 22 Apr 2013 21:03:12 +0900
Subject: [Idle-dev] Unicode Literal in IDLE. (python2)
In-Reply-To: <kl25ml$ls1$1@ger.gmane.org>
References: <CAE-36MZVGodk225S3VAy=Ppv5YbLLe7mM0rL_LH=iNTYneKnGw@mail.gmail.com>
	<CAL3CFcUmMPaWn+Uc=3oOwsduQtgOweQv7LDTXHLNXed7cON8Yw@mail.gmail.com>
	<kl25ml$ls1$1@ger.gmane.org>
Message-ID: <CAE-36MZSNg7ur1VHY5yMjqeJ29qdTTefnO4Zsgbc9yoiJRrg+w@mail.gmail.com>

Of cource, I know,  using Python3 is the best way.
But, there are libraries only supporting Python2 (i.e python-xlib).
Using Python2's dual-text system is not so difficult for me.
Because I'm Japanese, I had to handle Japanese with many charsets in every
programs I made.
And I have one simple rule.

"Use unicode type all time.
Input must be converted to unicode soon.
Output must be converted to str late."

And, fixing this bug can open a can of worms ?
I think, we should open it.
IDLE needs cleanup such as removing too old codes.



2013/4/22 Terry Jan Reedy <tjreedy at udel.edu>

> On 4/21/2013 4:20 PM, Andrew Svetlov wrote:
>
>> I think fixing this bug for python 2 can open a can of worms. Python 3
>> works correctly IIRC.
>>
>> On Sun, Apr 21, 2013 at 7:47 PM, Tomoki Imai <tomo832 at gmail.com> wrote:
>>
>>> Hi.
>>>
>>> I found bug (I think) in IDLE.
>>> That is, unicode literal in IDLE.
>>> You can reconfirm it by executing following code in IDLE.
>>>
>>>  u"?????"
>>>>>
>>>> u'\xe3\x81\x93\xe3\x82\x93\**xe3\x81\xab\xe3\x81\xa1\xe3\**x81\xaf'
>>> ("?????" means hello in Japanese.It's unicode literal.)
>>>
>>> In normal Interpreter ( running in console)
>>>
>>>  u"?????"
>>>>>
>>>> u'\u3053\u3093\u306b\u3061\**u306f'
>>>
>>> I found a solution.
>>> I posted here.But I found it was closed after I posted.
>>>
>>
> To be clearer, it was closed a March 8.
>
>
>  http://bugs.python.org/**issue17348 <http://bugs.python.org/issue17348>
>>>
>>> Can I reopen it?Or, this is not bug?
>>>
>>
> David reopened, but like Andrew, I am wary. One reason we made unicode the
> text type in Python 3 was that patching the Python 2 dual-text system
> became a bit like playing Whack-A-Mole
> http://en.wikipedia.org/wiki/**Whac-A-Mole<http://en.wikipedia.org/wiki/Whac-A-Mole>
>
>
>
> ______________________________**_________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/**mailman/listinfo/idle-dev<http://mail.python.org/mailman/listinfo/idle-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130422/bb9560e9/attachment.html>

From andrew.svetlov at gmail.com  Mon Apr 22 14:38:17 2013
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Mon, 22 Apr 2013 15:38:17 +0300
Subject: [Idle-dev] Unicode Literal in IDLE. (python2)
In-Reply-To: <CAE-36MZSNg7ur1VHY5yMjqeJ29qdTTefnO4Zsgbc9yoiJRrg+w@mail.gmail.com>
References: <CAE-36MZVGodk225S3VAy=Ppv5YbLLe7mM0rL_LH=iNTYneKnGw@mail.gmail.com>
	<CAL3CFcUmMPaWn+Uc=3oOwsduQtgOweQv7LDTXHLNXed7cON8Yw@mail.gmail.com>
	<kl25ml$ls1$1@ger.gmane.org>
	<CAE-36MZSNg7ur1VHY5yMjqeJ29qdTTefnO4Zsgbc9yoiJRrg+w@mail.gmail.com>
Message-ID: <CAL3CFcWksTmPpcnuKjgggatzAA2V+LX5t=ADbJ99du6Y70vu4g@mail.gmail.com>

As http://www.python.org/dev/peps/pep-0434/ has been accepted we *can*
do enhancements in IDLE for Python 2.
Not sure we *should* do it for this case.
Lets discuss in http://bugs.python.org/issue17348 and
http://bugs.python.org/issue15809.


On Mon, Apr 22, 2013 at 3:03 PM, Tomoki Imai <tomo832 at gmail.com> wrote:

> Of cource, I know,  using Python3 is the best way.
> But, there are libraries only supporting Python2 (i.e python-xlib).
> Using Python2's dual-text system is not so difficult for me.
> Because I'm Japanese, I had to handle Japanese with many charsets in every
> programs I made.
> And I have one simple rule.
>
> "Use unicode type all time.
> Input must be converted to unicode soon.
> Output must be converted to str late."
>
> And, fixing this bug can open a can of worms ?
> I think, we should open it.
> IDLE needs cleanup such as removing too old codes.
>
>
>
> 2013/4/22 Terry Jan Reedy <tjreedy at udel.edu>
>
>> On 4/21/2013 4:20 PM, Andrew Svetlov wrote:
>>
>>> I think fixing this bug for python 2 can open a can of worms. Python 3
>>> works correctly IIRC.
>>>
>>> On Sun, Apr 21, 2013 at 7:47 PM, Tomoki Imai <tomo832 at gmail.com> wrote:
>>>
>>>> Hi.
>>>>
>>>> I found bug (I think) in IDLE.
>>>> That is, unicode literal in IDLE.
>>>> You can reconfirm it by executing following code in IDLE.
>>>>
>>>>  u"?????"
>>>>>>
>>>>> u'\xe3\x81\x93\xe3\x82\x93\**xe3\x81\xab\xe3\x81\xa1\xe3\**x81\xaf'
>>>> ("?????" means hello in Japanese.It's unicode literal.)
>>>>
>>>> In normal Interpreter ( running in console)
>>>>
>>>>  u"?????"
>>>>>>
>>>>> u'\u3053\u3093\u306b\u3061\**u306f'
>>>>
>>>> I found a solution.
>>>> I posted here.But I found it was closed after I posted.
>>>>
>>>
>> To be clearer, it was closed a March 8.
>>
>>
>>  http://bugs.python.org/**issue17348 <http://bugs.python.org/issue17348>
>>>>
>>>> Can I reopen it?Or, this is not bug?
>>>>
>>>
>> David reopened, but like Andrew, I am wary. One reason we made unicode
>> the text type in Python 3 was that patching the Python 2 dual-text system
>> became a bit like playing Whack-A-Mole
>> http://en.wikipedia.org/wiki/**Whac-A-Mole<http://en.wikipedia.org/wiki/Whac-A-Mole>
>>
>>
>>
>> ______________________________**_________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> http://mail.python.org/**mailman/listinfo/idle-dev<http://mail.python.org/mailman/listinfo/idle-dev>
>>
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev
>
>


-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130422/d5bfff51/attachment.html>

From tomo832 at gmail.com  Sat Apr 20 02:17:59 2013
From: tomo832 at gmail.com (Tomoki Imai)
Date: Sat, 20 Apr 2013 00:17:59 -0000
Subject: [Idle-dev] Missing unittest.mock in Python2 world be problem in
 making unitest for IDLE.
Message-ID: <CAE-36MYVZYTGKVjBDkeJTsF-tjefqXXkvRv8wQPAJRQU7WbnYA@mail.gmail.com>

Hi.

I'm a student thinking of participating in Google Summer of Code.
And I'm looking for a guidance.
The proposal that I want to make is "Unit Test framework for IDLE".
http://wiki.python.org/moin/SummerOfCode/2013/python-core

I emailed to Todd Rovito and read idlelib for a while,read following link.
http://bugs.python.org/issue15392

Using unittest.mock seemed to be good way to test GUI.
But there is a problem.
There is no unittest.mock in Python2.
http://docs.python.org/2/library/unittest.html

I think using third party mock seemed to be ok, but not best way.
https://pypi.python.org/pypi/mock
Because, IDLE is a part of official python.
I think relying on third party module is not good.

Do you have any advice?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130420/727489f8/attachment.html>

From mkoter at gmail.com  Tue Apr  2 08:08:28 2013
From: mkoter at gmail.com (Marek Koter)
Date: Tue, 02 Apr 2013 06:08:28 -0000
Subject: [Idle-dev] A bug report
Message-ID: <CAPWKMNF4kYtMmgsbf=wJLVdXNNS7o0q+iwcj90OizNMy8JKRcQ@mail.gmail.com>

Hi,

Clicking on any branch in File->Path Browser kills the program on Windows
Vista/7. On Ubuntu works fine.
Good luck,
Marek Koter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130402/f09b0828/attachment.html>