Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #61534 > unrolled thread

Re: Experiences/guidance on teaching Python as a first programming language

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-11 19:43 +1100
    Re: Experiences/guidance on teaching Python as a first programming language wxjmfauth@gmail.com - 2013-12-11 01:39 -0800
      Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-11 10:05 +0000
      Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-11 21:45 +1100
        Re: Experiences/guidance on teaching Python as a first programming language alex23 <wuwei23@gmail.com> - 2013-12-12 15:38 +1000
        Re: Experiences/guidance on teaching Python as a first programming language wxjmfauth@gmail.com - 2013-12-12 01:17 -0800
          Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-12 21:28 +1100
            Re: Experiences/guidance on teaching Python as a first programming language wxjmfauth@gmail.com - 2013-12-12 06:34 -0800
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-13 01:47 +1100
                Re: Experiences/guidance on teaching Python as a first programming language wxjmfauth@gmail.com - 2013-12-12 08:20 -0800
                  Re: Experiences/guidance on teaching Python as a first programming language Ned Batchelder <ned@nedbatchelder.com> - 2013-12-12 11:58 -0500
              Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-12 15:01 +0000
          Re: Experiences/guidance on teaching Python as a first programming language Ned Batchelder <ned@nedbatchelder.com> - 2013-12-12 08:52 -0500
          Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-12 14:30 +0000
          Re: Experiences/guidance on teaching Python as a first programming language Terry Reedy <tjreedy@udel.edu> - 2013-12-12 12:55 -0500
            Re: Experiences/guidance on teaching Python as a first programming language wxjmfauth@gmail.com - 2013-12-13 08:15 -0800
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-14 03:27 +1100
                Re: Experiences/guidance on teaching Python as a first programming language wxjmfauth@gmail.com - 2013-12-13 10:27 -0800
                  Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-14 05:32 +1100
                    Re: Experiences/guidance on teaching Python as a first programming language wxjmfauth@gmail.com - 2013-12-13 11:30 -0800
              Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-13 16:39 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-14 03:43 +1100
                Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-13 08:54 -0800
                  Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-14 03:57 +1100
              Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-13 17:02 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Terry Reedy <tjreedy@udel.edu> - 2013-12-13 17:49 -0500
                Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-14 09:58 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-13 23:10 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Terry Reedy <tjreedy@udel.edu> - 2013-12-13 18:30 -0500
                Re: Experiences/guidance on teaching Python as a first programming language wxjmfauth@gmail.com - 2013-12-14 06:03 -0800
                  Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-15 01:15 +1100
                  Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-14 14:38 +0000
                  CP65001 fails (was re: ...) Terry Reedy <tjreedy@udel.edu> - 2013-12-14 13:43 -0500
                    Re: CP65001 fails (was re: ...) wxjmfauth@gmail.com - 2013-12-14 12:48 -0800
                      Re: CP65001 fails (was re: ...) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-14 21:05 +0000
                        Re: CP65001 fails (was re: ...) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-14 22:51 +0000
                          Re: CP65001 fails (was re: ...) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-14 23:32 +0000
                          Re: CP65001 fails (was re: ...) rusi <rustompmody@gmail.com> - 2013-12-14 20:42 -0800
                            Re: CP65001 fails (was re: ...) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-15 05:00 +0000
                              Re: CP65001 fails (was re: ...) rusi <rustompmody@gmail.com> - 2013-12-14 21:24 -0800
                            Re: CP65001 fails (was re: ...) Chris Angelico <rosuav@gmail.com> - 2013-12-15 15:48 +1100
                            Re: CP65001 fails (was re: ...) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-15 14:25 +0000
                    Re: CP65001 fails (was re: ...) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-15 02:39 +0000
                      Re: CP65001 fails (was re: ...) Terry Reedy <tjreedy@udel.edu> - 2013-12-15 00:07 -0500
                        Re: CP65001 fails (was re: ...) wxjmfauth@gmail.com - 2013-12-15 00:26 -0800
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-14 10:38 +1100
              Re: Experiences/guidance on teaching Python as a first programming language Ethan Furman <ethan@stoneleaf.us> - 2013-12-13 15:17 -0800
              Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-13 23:58 +0000
                Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-14 10:00 +0000
                  Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-14 13:21 +0000
      Re: Experiences/guidance on teaching Python as a first programming language Steve Simmons <square.steve@gmail.com> - 2013-12-11 12:33 +0100
      Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-11 23:02 +1100
      Re: Experiences/guidance on teaching Python as a first programming language Steve Simmons <square.steve@gmail.com> - 2013-12-11 13:30 +0100
    Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-11 11:17 +0000

Page 1 of 3  [1] 2 3  Next page →

#61534 — Re: Experiences/guidance on teaching Python as a first programming language

On Wed, Dec 11, 2013 at 7:34 PM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> On Tue, Dec 10, 2013 at 2:02 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
>> Doesn't sound like they do, as that's causing plenty of problems.  In
>> today's world that level of knowledge isn't always necessary, especially if
>> your degree is not in CS.  One of the (many) nice things about Python is one
>> doesn't need to know that stuff to Get Things Done.
>
> You don't need to know how to use the brakes to drive to Wal-Mart,
> either. "Get Things Done" is not the one and only goal. It ignores
> productivity, correctness, ethics... It isn't a bad thing to learn
> things that are unnecessary to get the bare minimum accomplished.

When you tell a story, it's important to engage the reader from the
start. Sometimes that means starting the story in the middle of the
action, and filling in the important-but-less-exciting details later,
when they mean something. [1] Teaching a skill often hits the same
sorts of issues. Rather than explain "This is how to manipulate
registers in a CPU", explain "This is how to print Hello World to the
console" and worry about what exactly the console is (and how
redirection affects it) later. My tutorial on assembly language
programming did the same, though it used a one-character-output
operation so it printed a single asterisk to standard out. (Manually
setting CPU register AX to 0200 and DX to 002A, placing an INT 21
command in memory, and single-stepping it.) Learning how all that
functions - or even what the INT opcode means - came later. Start with
something visible and engaging.

After that, learn/teach as much background as is of interest, and
improve skills. But start with something that gets something done.

[1] http://tvtropes.org/pmwiki/pmwiki.php/Main/InMediasRes

ChrisA

[toc] | [next] | [standalone]

#61539

A few practical considerations, far away from theoretical
aspects. Mainly for non ascii, understand non native English
speakers.

Python is an "ascii oriented product".

Platform. On Windows, the solely version which works
harmoniously with the system is Py 2.7 in a byte string
mode (ie non unicode).

Unicode. Sorry, but Python just becomes a no-go.

The great strength is(are) the Python interactive
interpreter(s). It makes learning this language a game.

jmf
(Not teaching computer stuff, but regulary confrontated
with students and/or potential users).

[toc] | [prev] | [next] | [standalone]

#61542

On 11/12/2013 09:39, wxjmfauth@gmail.com wrote:
> A few practical considerations, far away from theoretical
> aspects. Mainly for non ascii, understand non native English
> speakers.
>
> Python is an "ascii oriented product".

Sheer unadulterated rubbish.

>
> Platform. On Windows, the solely version which works
> harmoniously with the system is Py 2.7 in a byte string
> mode (ie non unicode).

Fixed in Python 3, especially with the superb work done on PEP 393 and 
the FSR.

>
> Unicode. Sorry, but Python just becomes a no-go.

Yawn.

>
> The great strength is(are) the Python interactive
> interpreter(s). It makes learning this language a game.
>

Blimey, got something correct, miracles do happen.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#61547

On Wed, Dec 11, 2013 at 7:43 PM, Chris Angelico <rosuav@gmail.com> wrote:
> When you tell a story, it's important to engage the reader from the
> start.

On Wed, Dec 11, 2013 at 8:39 PM,  <wxjmfauth@gmail.com> wrote:
> A few practical considerations, far away from theoretical
> aspects. Mainly for non ascii, understand non native English
> speakers.

And then, shortly after the beginning of the story, you need to
introduce the villain. Thanks, jmf, for taking that position in our
role-play storytelling scenario! A round of applause for jmf, folks,
for doing a brilliant impression of the uninformed-yet-fanatical
Knight Templar villain!

ChrisA

[toc] | [prev] | [next] | [standalone]

#61663

On 11/12/2013 8:45 PM, Chris Angelico wrote:
> A round of applause for jmf, folks,
> for doing a brilliant impression of the uninformed-yet-fanatical
> Knight Templar villain!

Jacques de Molay, thou are avenged!

[toc] | [prev] | [next] | [standalone]

#61689

Le mercredi 11 décembre 2013 11:45:43 UTC+1, Chris Angelico a écrit :
> On Wed, Dec 11, 2013 at 7:43 PM, Chris Angelico <rosuav@gmail.com> wrote:
> 
> > When you tell a story, it's important to engage the reader from the
> 
> > start.
> 
> 
> 
> On Wed, Dec 11, 2013 at 8:39 PM,  <wxjmfauth@gmail.com> wrote:
> 
> > A few practical considerations, far away from theoretical
> 
> > aspects. Mainly for non ascii, understand non native English
> 
> > speakers.
> 
> 
> 
> And then, shortly after the beginning of the story, you need to
> 
> introduce the villain. Thanks, jmf, for taking that position in our
> 
> role-play storytelling scenario! A round of applause for jmf, folks,
> 
> for doing a brilliant impression of the uninformed-yet-fanatical
> 
> Knight Templar villain!
> 

I know Python since ver. 1.5.6 and used it intensively
since ver. 2.0 or 2.1 (?). I acquired some user experience.

Windows, Py2.(7), ascii. It is not a secret Python uses
ascii for the representation. As an example, this guy
who some time ago exposed his own solution to solve that
problem (btw, elegant and correct). ---  you wrote blah, blah
about his "mysterious code point", you did not recognize
he is (was) using Turkish Windows with the code
page cp1254 ---. It is a little bit fascinating, 20 years
after the creation a language, people are still fighting
to write text in a human way.

Unicode. For a first language, it may be not a bad idea
to use a language which uses "unicode à la unicode".

Windows, Py3, unicode. It is is infortunate, but it is
a fact Python has some problems with that platform (file
sytem encoding), -> potential problems which should not
exist for a beginner.
I am the first to recognize the win console is all but
friendly. If one wishes to use a unicode code page, Python
fails [*].

Python has plenty of good qualities, you (and others)
are discussing plenty of theoretical aspects.
I'm pointing the fact, one may be stuck simply because
one cannot display a piece of of text!
I'm not so sure, such a behaviour is expected from a
beginner learning a computer language.


[*] I toyed with go(lang) and ruby 2 (only in a unicode
perspective), I should say I had no problems. Why? No
idea, it is too far beyond my knowlege.

jmf

[toc] | [prev] | [next] | [standalone]

#61693

On Thu, Dec 12, 2013 at 8:17 PM,  <wxjmfauth@gmail.com> wrote:
> Windows, Py2.(7), ascii. It is not a secret Python uses
> ascii for the representation.

Actually no, it doesn't.

Python 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit
(Intel)] on win32
>>> s = "abcd\xa9"
>>> print(s)
abcd©

The copyright symbol is not in ASCII. Are you suggesting that Python
uses a 7-bit internal representation of this data? Because a quick
squiz at the source code will prove that wrong. This is not ASCII.

ChrisA

[toc] | [prev] | [next] | [standalone]

#61718

Le jeudi 12 décembre 2013 11:28:35 UTC+1, Chris Angelico a écrit :
> On Thu, Dec 12, 2013 at 8:17 PM,  <wxjmfauth@gmail.com> wrote:
> 
> > Windows, Py2.(7), ascii. It is not a secret Python uses
> 
> > ascii for the representation.
> 
> 
> 
> Actually no, it doesn't.
> 
> 
> 
> Python 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit
> 
> (Intel)] on win32
> 
> >>> s = "abcd\xa9"
> 
> >>> print(s)
> 
> abcd©
> 
> 
> 
> The copyright symbol is not in ASCII. Are you suggesting that Python
> 
> uses a 7-bit internal representation of this data? Because a quick
> 
> squiz at the source code will prove that wrong. This is not ASCII.
> 
> 

>>> sys.version
'2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]'
>>> sys.stdout.encoding
'cp1252'
>>> s = 'abc\xa9'
>>> t = 'abc©'
>>> s
'abc\xa9'
>>> t
'abc\xa9'
>>> print s, t, (s, t)
abc© abc© ('abc\xa9', 'abc\xa9')
>>> def HumanStr(o):
	t = repr(o)
	newt = t.replace('\\xa9', '©')
	return newt

>>> print s, t, (s, t), HumanStr((s, t))
abc© abc© ('abc\xa9', 'abc\xa9') ('abc©', 'abc©')
>>> 

jmf

PS I do not insist on "sys.displayhook"

PS2 I can only congratulate this Turkish guy for
his understanding of Python

[toc] | [prev] | [next] | [standalone]

#61721

On Fri, Dec 13, 2013 at 1:34 AM,  <wxjmfauth@gmail.com> wrote:
> Le jeudi 12 décembre 2013 11:28:35 UTC+1, Chris Angelico a écrit :
>> On Thu, Dec 12, 2013 at 8:17 PM,  <wxjmfauth@gmail.com> wrote:
>>
>> > Windows, Py2.(7), ascii. It is not a secret Python uses
>> > ascii for the representation.
>>
>> Actually no, it doesn't.
>
>>>> sys.version
> '2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]'
>>>> sys.stdout.encoding
> 'cp1252'

What has this to do with ASCII or with Python's internal
representation? All you've proven is that you can convert the repr of
a string back into a byte-string, by replacing "\\xa9" with "\xa9",
and then shown that you can successfully render that as CP-1252 and it
displays as a copyright symbol. Meanwhile when I try the same thing on
my Windows box, the default encoding is cp437, so it throws. Proves
nothing about ASCII, as neither of those encodings is ASCII, and A9
does not decode as ASCII.

ChrisA

[toc] | [prev] | [next] | [standalone]

#61730

Le jeudi 12 décembre 2013 15:47:40 UTC+1, Chris Angelico a écrit :
> On Fri, Dec 13, 2013 at 1:34 AM,  <wxjmfauth@gmail.com> wrote:
> 
> > Le jeudi 12 décembre 2013 11:28:35 UTC+1, Chris Angelico a écrit :
> 
> >> On Thu, Dec 12, 2013 at 8:17 PM,  <wxjmfauth@gmail.com> wrote:
> 
> >>
> 
> >> > Windows, Py2.(7), ascii. It is not a secret Python uses
> 
> >> > ascii for the representation.
> 
> >>
> 
> >> Actually no, it doesn't.
> 
> >
> 
> >>>> sys.version
> 
> > '2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]'
> 
> >>>> sys.stdout.encoding
> 
> > 'cp1252'
> 
> 
> 
> What has this to do with ASCII or with Python's internal
> 
> representation? All you've proven is that you can convert the repr of
> 
> a string back into a byte-string, by replacing "\\xa9" with "\xa9",
> 
> and then shown that you can successfully render that as CP-1252 and it
> 
> displays as a copyright symbol. Meanwhile when I try the same thing on
> 
> my Windows box, the default encoding is cp437, so it throws. Proves
> 
> nothing about ASCII, as neither of those encodings is ASCII, and A9
> 
> does not decode as ASCII.
> 
> 


Are you understanding Python by chance? print, __repr__, __str__,
sys.std*.encoding, ...
Are you understanding Windows? CHCP
Are you understanding the coding of the characters? cp1252, cp850, cp437, ...

Python (2) is managing 	all this very well. Unfortunately, not in
a friendly way.

jmf

[toc] | [prev] | [next] | [standalone]

#61732

On 12/12/13 11:20 AM, wxjmfauth@gmail.com wrote:
> Le jeudi 12 décembre 2013 15:47:40 UTC+1, Chris Angelico a écrit :
>> On Fri, Dec 13, 2013 at 1:34 AM,  <wxjmfauth@gmail.com> wrote:
>>
>>> Le jeudi 12 décembre 2013 11:28:35 UTC+1, Chris Angelico a écrit :
>>
>>>> On Thu, Dec 12, 2013 at 8:17 PM,  <wxjmfauth@gmail.com> wrote:
>>
>>>>
>>
>>>>> Windows, Py2.(7), ascii. It is not a secret Python uses
>>
>>>>> ascii for the representation.
>>
>>>>
>>
>>>> Actually no, it doesn't.
>>
>>>
>>
>>>>>> sys.version
>>
>>> '2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]'
>>
>>>>>> sys.stdout.encoding
>>
>>> 'cp1252'
>>
>>
>>
>> What has this to do with ASCII or with Python's internal
>>
>> representation? All you've proven is that you can convert the repr of
>>
>> a string back into a byte-string, by replacing "\\xa9" with "\xa9",
>>
>> and then shown that you can successfully render that as CP-1252 and it
>>
>> displays as a copyright symbol. Meanwhile when I try the same thing on
>>
>> my Windows box, the default encoding is cp437, so it throws. Proves
>>
>> nothing about ASCII, as neither of those encodings is ASCII, and A9
>>
>> does not decode as ASCII.
>>
>>
>
>
> Are you understanding Python by chance? print, __repr__, __str__,
> sys.std*.encoding, ...
> Are you understanding Windows? CHCP
> Are you understanding the coding of the characters? cp1252, cp850, cp437, ...
>

Before we talk about Unicode, we should talk about the process of 
convincing people of things.

Asking questions won't convince anyone of anything.  If you have new 
information, then present it to us.  Presenting it means: show some 
code, show some bad outcome, and then explain what you you have 
demonstrated.  Be specific about what problem you are showing.

You said "Python uses ASCII."  Then you showed us Python code with 
non-ASCII characters.  We are confused what you are trying to tell us.

Python 2 uses byte strings.  Those byte strings can contain any bytes, 
conforming to any encoding the developer desires.  You asserted that it 
uses ASCII.  That is incorrect.

We have discussed Unicode with you enough to believe that we are not 
going to agree with you.  You hold a (very) minority view about what 
Python does with text, and you are not able to convince people of your 
view.  Isn't that frustrating?  Perhaps you need a new approach.

> Python (2) is managing 	all this very well. Unfortunately, not in
> a friendly way.
>
> jmf
>


-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#61725

On 12/12/2013 14:34, wxjmfauth@gmail.com wrote:
> Le jeudi 12 décembre 2013 11:28:35 UTC+1, Chris Angelico a écrit :
>> On Thu, Dec 12, 2013 at 8:17 PM,  <wxjmfauth@gmail.com> wrote:
>>
>>> Windows, Py2.(7), ascii. It is not a secret Python uses
>>
>>> ascii for the representation.
>>
>>
>>
>> Actually no, it doesn't.
>>
>>
>>
>> Python 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit
>>
>> (Intel)] on win32
>>
>>>>> s = "abcd\xa9"
>>
>>>>> print(s)
>>
>> abcd©
>>
>>
>>
>> The copyright symbol is not in ASCII. Are you suggesting that Python
>>
>> uses a 7-bit internal representation of this data? Because a quick
>>
>> squiz at the source code will prove that wrong. This is not ASCII.
>>
>>
>
>>>> sys.version
> '2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]'
>>>> sys.stdout.encoding
> 'cp1252'
>>>> s = 'abc\xa9'
>>>> t = 'abc©'
>>>> s
> 'abc\xa9'
>>>> t
> 'abc\xa9'
>>>> print s, t, (s, t)
> abc© abc© ('abc\xa9', 'abc\xa9')
>>>> def HumanStr(o):
> 	t = repr(o)
> 	newt = t.replace('\\xa9', '©')
> 	return newt
>
>>>> print s, t, (s, t), HumanStr((s, t))
> abc© abc© ('abc\xa9', 'abc\xa9') ('abc©', 'abc©')
>>>>
>
> jmf
>
> PS I do not insist on "sys.displayhook"
>
> PS2 I can only congratulate this Turkish guy for
> his understanding of Python
>

I understand that this Turkish guy will be added to the list here 
http://en.wikipedia.org/wiki/Turing_Award next year for his stunning 
contribution to the field of computer science.  The year after he will 
win the award again for his outstanding contribution which prevents 
people from sending double spaced crap to this list.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#61708

On 12/12/13 4:17 AM, wxjmfauth@gmail.com wrote:
> Le mercredi 11 décembre 2013 11:45:43 UTC+1, Chris Angelico a écrit :
>> On Wed, Dec 11, 2013 at 7:43 PM, Chris Angelico <rosuav@gmail.com> wrote:
>>
>>> When you tell a story, it's important to engage the reader from the
>>
>>> start.
>>
>>
>>
>> On Wed, Dec 11, 2013 at 8:39 PM,  <wxjmfauth@gmail.com> wrote:
>>
>>> A few practical considerations, far away from theoretical
>>
>>> aspects. Mainly for non ascii, understand non native English
>>
>>> speakers.
>>
>>
>>
>> And then, shortly after the beginning of the story, you need to
>>
>> introduce the villain. Thanks, jmf, for taking that position in our
>>
>> role-play storytelling scenario! A round of applause for jmf, folks,
>>
>> for doing a brilliant impression of the uninformed-yet-fanatical
>>
>> Knight Templar villain!
>>
>
> I know Python since ver. 1.5.6 and used it intensively
> since ver. 2.0 or 2.1 (?). I acquired some user experience.
>
> Windows, Py2.(7), ascii. It is not a secret Python uses
> ascii for the representation.

It is incorrect that Py2.x uses ASCII strings.  It uses byte strings. 
Source files are assumed to be encoded in ASCII, so byte strings often 
are ASCII.  But as Chris has pointed out, bytestrings can hold any byte 
data, including UTF-8 if you wish.

JMF, I think you are clever enough and care enough about these issues to 
get this straight.

Many people seem to like the Pragmatic Unicode presentation I did, it 
may clear up some issues:  http://nedbatchelder.com/text/unipain.html

I'd be glad to have an extended conversation with you offline if you 
don't want to get into details here.

> As an example, this guy
> who some time ago exposed his own solution to solve that
> problem (btw, elegant and correct). ---  you wrote blah, blah
> about his "mysterious code point", you did not recognize
> he is (was) using Turkish Windows with the code
> page cp1254 ---. It is a little bit fascinating, 20 years
> after the creation a language, people are still fighting
> to write text in a human way.

"This guy": I have no idea who you are talking about.

>
> Unicode. For a first language, it may be not a bad idea
> to use a language which uses "unicode à la unicode".
>
> Windows, Py3, unicode. It is is infortunate, but it is
> a fact Python has some problems with that platform (file
> sytem encoding), -> potential problems which should not
> exist for a beginner.

File system encodings are very difficult.  Linux uses byte strings for 
file names, with no attempt to record the encoding, so there's a strong 
possibility that the declared encoding for the filesystem is wrong, or 
that your guess at the encoding will be wrong.

> I am the first to recognize the win console is all but
> friendly. If one wishes to use a unicode code page, Python
> fails [*].

Yes, the Windows console and Python don't get along well with Unicode. 
This is a long-standing ticket: http://bugs.python.org/issue1602  I'm 
sure they would welcome your contribution towards a solution.  When I 
use Windows, I often wish this were solved.

>
> Python has plenty of good qualities, you (and others)
> are discussing plenty of theoretical aspects.
> I'm pointing the fact, one may be stuck simply because
> one cannot display a piece of of text!
> I'm not so sure, such a behaviour is expected from a
> beginner learning a computer language.
>
>
> [*] I toyed with go(lang) and ruby 2 (only in a unicode
> perspective), I should say I had no problems. Why? No
> idea, it is too far beyond my knowlege.
>
> jmf
>
>


-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#61717

On 12/12/2013 13:52, Ned Batchelder wrote:
>
> I'd be glad to have an extended conversation with you offline if you
> don't want to get into details here.

Would you please to kind enough to keep it online, I enjoy a good 
comedian and our erstwhile unicode expert is one of the best, if not the 
best, in this field.

If you do take it offline would you please ask him to stop sending via 
google groups, or to take appropriate action to stop the extremely 
annoying double spacing.

> Yes, the Windows console and Python don't get along well with Unicode.
> This is a long-standing ticket: http://bugs.python.org/issue1602  I'm
> sure they would welcome your contribution towards a solution.  When I
> use Windows, I often wish this were solved.
>

There's also http://bugs.python.org/issue14170 and 
http://bugs.python.org/issue15809 amongst others.  Contributing towards 
a solution is a simple thing to do.  Finding a solution isn't as simple 
see e.g. http://www.gossamer-threads.com/lists/python/dev/731701

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#61733

On 12/12/2013 4:17 AM, wxjmfauth@gmail.com wrote:

> Windows, Py3, unicode. It is is infortunate, but it is
> a fact Python has some problems with that platform (file
> sytem encoding), -> potential problems which should not
> exist for a beginner.

Some disappear if, for instance, one uses Idle.

> I am the first to recognize the win console is all but
> friendly.

Something we agree on. It is a piece crap. I believe that MS keeps it 
crippled to discourage use. (They apparently would like to remove it.)

> If one wishes to use a unicode code page, Python fails [*].

If you mean cp65xxx (I forget exact numbers), MS Command Prompt fails, 
not Python. One should not use any other code page, but only other code 
pages work.

Tk, and hence tkinter and idle work fine with the entire BMP. If one 
tells tk to use a font that can handle the entire BMP, it displays the 
entire BMP.

> Python has plenty of good qualities, you (and others)
> are discussing plenty of theoretical aspects.
> I'm pointing the fact, one may be stuck simply because
> one cannot display a piece of of text!

Most text display problems disappear if one avoids Command Prompt and 
uses a GUI that can handle at least the BMP. Idle works on Windows after 
Python is installed unless one tells the installer to not install tcl/tk.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#61829

Le jeudi 12 décembre 2013 18:55:15 UTC+1, Terry Reedy a écrit :
> 
> 
> 
> 
> 
> If you mean cp65xxx (I forget exact numbers), MS Command Prompt fails, 
> 
> not Python. One should not use any other code page, but only other code 
> 
> pages work.
> 
> 
> 

-----

Please, do not exaggerate too much.
On my win7 box, using cp65001:

The golang works. Despite my poor knowledge with with
this language, I even relatively quickly succeded to write
a "readline" fct.

Ruby 2 works.

irb, the interactive ruby works. I remember to have had
some diffuculties in entering some chars, this a different
problem.

echo "unicode" works.

xelatex (my favourite tool), a tex-unicode engine, works.
I'm usualy using a GUI tool, I just tested with a "éàü.tex"
document. Indeed, it works.

Starting that created document "éàü.pdf" with the cmd
> start éàü.pdf
works. It calls Acrobat Reader.

Starting that created document with Sumatra, a pdf viewer
works.

Not directly related to my comment, I can compile a
.tex document in such a dir
> D:\jm\Москва\Zürich\Αθήνα\œdipe
and it works.

Something a little bit different. Neil Hodgson's SciTE
editor. One can configure the output pane to use 65001.
All the examples above works. It is also possible to 
make Python working, but I had to write my own "printing
material".

A note about font. The console does not, and is not able,
to display all the "chars". It is however always displaying
text very smoothly and correctly using the replacement *glyph".
Nothing to do with an "incorrect behaviour" of the console.

Eg:
> echo "ሴé€㑖Ѓ⌴*"
works.

I mainly considered BMP "characters".

Windows is not so bad. One can discuss ad nauseam
the pros and cons of console-gui application. I have
always considered Windows as a system which use gui
applications. And even with Python using a gui toolkit,
I sometimes "link" my own created "gui console".

I do not wish to defend MS. What I wrote depends
on the Windows version, XP, Vista, Windows 7. 
One should recognize, with win7, MS, finally, produce
a full unicode system. Strangely, among all the "bashing"
one can read about that system, this is rarely mentioned.
(With an excellent unicode coding scheme!)

jmf

[toc] | [prev] | [next] | [standalone]

#61832

On Sat, Dec 14, 2013 at 3:15 AM,  <wxjmfauth@gmail.com> wrote:
> One should recognize, with win7, MS, finally, produce
> a full unicode system. Strangely, among all the "bashing"
> one can read about that system, this is rarely mentioned.
> (With an excellent unicode coding scheme!)

[citation needed]

ChrisA

[toc] | [prev] | [next] | [standalone]

#61859

Le vendredi 13 décembre 2013 17:27:35 UTC+1, Chris Angelico a écrit :
> On Sat, Dec 14, 2013 at 3:15 AM,  <wxjmfauth@gmail.com> wrote:
> 
> > One should recognize, with win7, MS, finally, produce
> 
> > a full unicode system. Strangely, among all the "bashing"
> 
> > one can read about that system, this is rarely mentioned.
> 
> > (With an excellent unicode coding scheme!)
> 
> 
> 
> [citation needed]
> 
-----

My guess is that you are referring to that
sentence "(With an excellent unicode coding scheme!)".
I do not need to cite anything. That's my opinion.

My comment was mainly oriented about cp65*** in the
context of a teaching programming language. I pointed
that some tools are working very well with that code
page.

jmf

[toc] | [prev] | [next] | [standalone]

#61861

On Sat, Dec 14, 2013 at 5:27 AM,  <wxjmfauth@gmail.com> wrote:
> My guess is that you are referring to that
> sentence "(With an excellent unicode coding scheme!)".
> I do not need to cite anything. That's my opinion.

Just as much to what's above it, where you state that MS has produced
"a full unicode system". Is that, too, just opinion, utterly unfounded
in fact, or can you provide a citation?

ChrisA

[toc] | [prev] | [next] | [standalone]

#61862

Le vendredi 13 décembre 2013 19:32:58 UTC+1, Chris Angelico a écrit :
> On Sat, Dec 14, 2013 at 5:27 AM,  <wxjmfauth@gmail.com> wrote:
> 
> > My guess is that you are referring to that
> 
> > sentence "(With an excellent unicode coding scheme!)".
> 
> > I do not need to cite anything. That's my opinion.
> 
> 
> 
> Just as much to what's above it, where you state that MS has produced
> 
> "a full unicode system". Is that, too, just opinion, utterly unfounded
> 
> in fact, or can you provide a citation?
> 
> 

I have not the knowledge to put a jugment on this. 
I read many articles on the subject from people
who seems to have some skills on the subject.

From my own experience with my limited and empirical
computing experience, when I see the file system,
the rendering engine, the usage of OpenType fonts, ...
I tend to have to agree. I can also point that all
these aspects jump to my mind when I switched from
XP to 7. Some time ago, I even fall on an article
about the bootstraping mechanism (7 or 8 or future
version or RT ?) which uses natively ucs-2.

jmf

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web