[Python-ideas] Non-English names in the turtle module.

[Al Sweigart]

Thinking about it some more, yeah, having a separate module on PyPI would
just be a waste of time. This isn't changing functionality or experimenting
with new features, it's just adding new names to existing functions. And
installing stuff with pip is going to be insurmountable barrier for a lot
of computer labs.

I'd say Python is very much a kid-friendly language. It's definitely much
friendlier than BASIC.

I'd advise against using the _() function in gettext. That function is for
string tables, which is set up to be easily changed and expanded. The
turtle API is pretty much set in stone, and dealing with separate .po files
and gettext in general would be more of a maintenance headache. It is also
dependent on the machine's localization settings.

I believe some simple code at the end of turtle.py like this would be good
enough:

    _spanish = {'forward': 'adelante'} # ...and the rest of the translated
terms
    _languages = {'spanish': _spanish} # ...and the rest of the languages

    def forward(): # this is the original turtle forward() function
        print('Blah blah blah, this is the forward() function.')

    for language in _languages:
        for englishTerm, nonEnglishTerm in _languages[language].items():
            locals()[nonEnglishTerm] = locals()[englishTerm]

Plus the diff wouldn't look too bad.

This doesn't prohibit someone from mixing both English and Non-English
names in the same program, but I don't see that as a big problem. I think
it's best to have all the languages available without having to setup
localization settings.

-Al

On Thu, Sep 3, 2015 at 7:45 PM, Steven D'Aprano <steve at pearwood.info> wrote:

> On Fri, Sep 04, 2015 at 11:05:51AM +0900, Stephen J. Turnbull wrote:
> > Al Sweigart writes:
> >
> >  > The idea for putting these modules on PyPI is interesting. My only
> >  > hesitation is I don't want "but it's already on PyPI" as an excuse
> >  > not to include these changes into the standard library turtle
> >  > module.
> >
> > Exactly backwards, as the first objection is going to be "if it could
> > be on PyPI but isn't, there's no evidence it's ready for the stdlib."
>
> *cough typing cough*
>
>
> The turtle module has been in Python for many, many years. This proposal
> doesn't change the functionality, it merely offers a localised API to
> the same functionality. A bunch of alternate names, nothing more.
>
> I would argue that if you consider the user-base of turtle, putting it
> on PyPI is a waste of time:
>
> - Beginners aren't going to know to "pip install whatever". Some of us
> here seem to think that pip is the answer to everything, but if you look
> on the python-list mailing list, you will see plenty of evidence that
> people have trouble using pip.
>
> - Schools may have policies against the installation of unapproved
> software on their desktops, and getting approval to "pip install *" may
> be difficult, time-consuming or outright impossible. If they are using
> Python, we know they have approval to use what is in the standard
> library. Everything else is, at best, a theorectical possibility.
>
> One argument against this proposal is that Python is not really designed
> as a kid-friendly learning language, and we should just abandon that
> space to languages that do it better, like Scratch. I'd hate to see that
> argument win, but given our limited resources perhaps we should know
> when we're beaten. Compared to what Scratch can do, turtle graphics are
> so very 1970s.
>
> But if we think that there is still a place in the Python infrastructure
> for turtle graphics, then I'm +1 on localising the turtle module.
>
>
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150903/4de44e33/attachment-0001.html>