gmane.comp.python.idle

OS X IDLE and Tkinter users: new releases of Tcl/Tk &Python

Ned Deily — 2013-05-19T02:50:52

As I hope you've read already, new releases of Python are now available:  
3.3.2, 3.2.5, and 2.7.5.  There is also a recent release of Tcl/Tk 8.5: 
8.5.14.  If you use Tkinter apps, like IDLE, from one of the python.org 
64-bit/32-bit OS X installers for 3.3.x, 3.2.x, or 2.7.x for OS X 10.6, 
10.7, or 10.8, it would be great if you could install and try out these 
latest combinations.  Tkinter apps have proven to turn up edge cases in 
the newer Cocoa implementation of Tk 8.5 on OS X;  a number of problems 
have been fixed in recent releases.  Since these kinds of problems are 
difficult to test for automatically, it is important to get real user 
experience and feedback.  Please report any suspected new problems to 
the Python bug tracker.  Thanks for your help!

http://www.python.org/download/
http://www.python.org/download/mac/tcltk/
http://www.activestate.com/activetcl/downloads
http://bugs.python.org

Re: IDLE Unittest framework: Commencing Initial Design

Terry Jan Reedy — 2013-05-14T00:24:56


I think it a bit weird that you say this without waiting for and reading 
the promised explanation.

 > why not to follow "Special cases aren't

PEP 434 recognizes Idle as a special case that *is* special enough to 
break the rule for changes in bugfix releases. The same specialness is 
part of my reason and explanation.

tjr

Re: IDLE Unittest framework: Commencing Initial Design

francis — 2013-05-13T20:04:43

That's a bit weird Terry, why not to follow "Special cases aren't 
special enough to break the rules."?

Re: IDLE Unittest framework: Commencing Initial Design

Terry Jan Reedy — 2013-05-13T06:19:05

*after developing it*


email and idle are very different beasts.


I applied a patch and need to check if it completely resolved the issue.


It is 2 am Monday for me so I will try to be brief and coherent. I have 
a draft of a patch based somewhat on yours. I hope to finish it today 
after sleep and upload it. I still prefer idlelib/itest (better than 
'test' to avoid masking Lib/test when in idlelib) for multiple reasons 
and have a draft explanation of them, which will accompany the patch.

I too would like to do the first commit soon, so I can followup with a 
conversion of the calltips tests.

I looked through all the idlelib/*.py modules today and there is not 
much else in the way of *automated* tests to convert. There is plenty 
for multiple people to do ;-). You help will be appreciated.

Terry

IDLE Unittest framework: Commencing Initial Design

Jayakrishnan Rajagopalasarma — 2013-05-13T05:28:38

There is a need for a proper design in commencing idle unittest framework,
Two suggestions in issue 15392 <http://bugs.python.org/issue15392#> are
 create test_idle directory in test sub directory (Lib/test/test_idle)
 or to create test directory inside idlelib. (Lib/idlelib/test)

On that discussion these two approaches were proposed as follows,

David Murray said, "best practice would be to have all tests be in the
'test' sub directory. I moved email/test into test/test_email, and I prefer
having it there"

Terry J. Reedy said, "I strongly prefer idlelib/test since it will
make developing **much** easier for me on Windows. Also, it would be
part of the optional install of idlelib, as tkinter/test is for
tkinter. Adding test/test_idle will not be too much use until issue
#10652 <http://bugs.python.org/issue10652> is resolved so it would
actually run with -m test."

To continue this work with my GSoc work, considering these points , my
view is to put tests in test/test_idle directory, like test/test_email
wo

Biggest Fake Conference in Computer Science

2013-04-30T22:14:45

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on the world’s biggest 
bogus computer science conference WORLDCOMP  http://sites.google.com/site/worlddump1 
organized by Prof. Hamid Arabnia from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to 
WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that 
paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it was accepted both the times 
without any modifications (and without any r

Re: Unicode Literal in IDLE. (python2)

Andrew Svetlov — 2013-04-22T12:38:17

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:

Re: Unicode Literal in IDLE. (python2)

Tomoki Imai — 2013-04-22T12:03:12

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>

_______________________________________________
IDLE-dev mailing list
IDLE-dev< at >python.org
http://mail.python.org/mailman/listinfo/idle-dev

Re: Unicode Literal in IDLE. (python2)

Terry Jan Reedy — 2013-04-22T02:02:10

To be clearer, it was closed a March 8.


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


_______________________________________________
IDLE-dev mailing list
IDLE-dev< at >python.org
http://mail.python.org/mailman/listinfo/idle-dev

Re: Unicode Literal in IDLE. (python2)

Andrew Svetlov — 2013-04-21T20:20:20

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:

Unicode Literal in IDLE. (python2)

Tomoki Imai — 2013-04-21T16:47:29

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

Missing unittest.mock in Python2 world be problem in making unitest for IDLE.

Tomoki Imai — 2013-04-20T10:08:58

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.
_______________________________________________
IDLE-dev mailing list
IDLE-dev< at >python.org
http://mail.python.org/mailman/listinfo/idle-dev

[GSoc- 2013]: UnitTest Framework and Pep8 Integrationfor Idle

Jayakrishnan Rajagopalasarma — 2013-04-20T01:41:32

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
pat

Re: I18n of IDLE's interface ?

Damien — 2013-04-18T11:30:51

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>

_______________________________________________
IDLE-dev mailing list
IDLE-dev< at >python.org
http://mail.p

Re: I18n of IDLE's interface ?

Olivier Berger — 2013-04-18T09:28:20


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.


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

Re: I18n of IDLE's interface ?

Olivier Berger — 2013-04-18T09:20:10

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:



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


SNIP


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

Re: I18n of IDLE's interface ?

Terry Jan Reedy — 2013-04-18T03:18:35

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

Re: I18n of IDLE's interface ?

Terry Jan Reedy — 2013-04-17T20:54:56

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.

Re: I18n of IDLE's interface ?

Terry Jan Reedy — 2013-04-17T20:40:33

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


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

Re: I18n of IDLE's interface ?

Olivier Berger — 2013-04-17T16:18:47


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


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,

Re: I18n of IDLE's interface ?

Roger Serwy — 2013-04-17T14:36:28

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.



_______________________________________________
IDLE-dev mailing list
IDLE-dev< at >python.org
http://mail.python.org/mailman/listinfo/idle-dev