Re: CP65001 fails (was re: ...)

2013-12-15 Thread wxjmfauth
Le dimanche 15 décembre 2013 06:07:09 UTC+1, Terry Reedy a écrit :
 On 12/14/2013 9:39 PM, Steven D'Aprano wrote:
 
  On Sat, 14 Dec 2013 13:43:41 -0500, Terry Reedy wrote:
 
 
 
  This was reported by Victor Stinner as part of
 
  http://bugs.python.org/issue19914
 
  to explain how cp65001 causes behavior like this with Python's
 
  interactive help() function (which more for paging on Windows).
 
 
 
 help(str)
 
  Not enough memory.
 
 
 
 
 
  Terry, I see you have closed the bug report. I think you were a little
 
  hasty.
 
 
 
 I might have been premature, but I was not hasty. I read the SO reports 
 
 and though about it for an hour or so while looking at other issues. I 
 
 did not see any use to leaving it open as I did not see any realistic 
 
 propect of a useful and acceptible patch to Python. The OP himself said 
 
 that i/o did not work with 65001 and that not using it fixed his issue.
 
 
 
  The ultimate cause of the bug may be the failure of Window's
 
  more command when the code-page is set to CP-65001, but that doesn't
 
  necessarily imply that Python shouldn't, or can't, do something about it.
 
 
 
 I believe running Python on Windows with cp=65001 falls in the category 
 
 of Don't do that. This is based on my experiences and the reported 
 
 experience of other developers who have tried and failed to make it 
 
 work, reinforced by the SO thread and a couple of other web pages.
 
 
 
  The interactive help system already supports different pagers, depending
 
  on the environment. I think that it could fall back on a more primitive
 
  pager if the preferred one fails.
 
 
 
 Do you know if 'more' actually signals failure?
 
 Do you know if there are any other situations in which a pager fails?
 
 
 
  The relevant code is the pager() and
 
  getpager() functions in the pydoc module. The patch won't be trivial, but
 
  I think it can be done, and I think it should be done. Although possibly
 
  for Python 3.5 rather than a bug-fix version. Your thoughts?
 
 
 
 My thought is that if the only situation in which a pager fails is one 
 
 that one should not use, because other things will also fail, then a 
 
 patch would not be worth the bother.
 
 


If I'm understanding a little bit about coding of
characters, fonts, chars inputing, I should say
I never really understood how all this stuff is
arranged. (I never found a real explanation too).


There is something, which may be very deeply bound to
the system (kernel ?). As an example, entering a
char with Alt+0XXX always works accordingly to my (the?)
localized windows version. Entering a char with
Alt+XXX (not the missing 0) uses the OEM (bios?)
encoding.

jmf

-- 
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-15 Thread Mark Lawrence

On 15/12/2013 04:48, Chris Angelico wrote:

On Sun, Dec 15, 2013 at 3:42 PM, rusi rustompm...@gmail.com wrote:

To me all this GG complaining sounds like some elderly mom-pop-uncle
who weeps/coaxes/moans/pleads/grumbles/ about a fused light bulb,
rather than climbing on a stool and changing the bloody thing.


No, it's like moaning about Foo Brand light bulbs that die after two
weeks, when there are perfectly good light bulbs that last for years
if you'll just use a different brand. And there are people who say
But Foo Brand light bulbs are easy, you just go up on a ladder every
time you want to turn it on and make sure there's a good bulb in it!.

ChrisA



On this count I observe that on 15/12/2013 GMT at 08:26 the cows still 
haven't come home :)


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


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread wxjmfauth
Le samedi 14 décembre 2013 19:43:41 UTC+1, Terry Reedy a écrit :
 On 12/14/2013 9:03 AM, wxjmfa...@gmail.com wrote:
 
 
 
  D:\chcp 65001
 
  Page de codes active : 65001
 
  D:\echo *
 
  *
 
 
 
 Try pasting *your* original echo command: echo ሴé€㑖Ѓ⌴*
 
 
 
 To repeat, here is what I see:
 
 '''
 
 C:\Users\Terryecho ?‚*
 
 ?‚*
 
 
 
 C:\Users\Terrychcp 65001
 
 Active code page: 65001
 
 
 
 C:\Users\Terryecho *
 
 The system cannot write to the specified device.
 
 '''
 
 To repeat, the second time I paste: echo ሴé€㑖Ѓ⌴*
 
 but Command Prompt only displays: echo *. Typing in the latter, 
 
 ascii-only, command is meaningless.
 
 
 
 A similar test:
 
 '''
 
 C:\Users\Terrymore
 
 ^Z
 
 
 
 C:\Users\Terrychcp 65001
 
 Active code page: 65001
 
 
 
 C:\Users\Terrymore
 
 Not enough memory.
 
 '''
 
 This was reported by Victor Stinner as part of
 
 http://bugs.python.org/issue19914
 
 to explain how cp65001 causes behavior like this with Python's 
 
 interactive help() function (which more for paging on Windows).
 
 
 
   help(str)
 
 Not enough memory.
 
 
 
 See
 
 http://stackoverflow.com/questions/3401802/codepage-850-works-65001-fails-there-is-no-response-to-call-foo-cmd-interna
 
 for other reports that cp65001 fails. It is not just me.
 
 
 



 print((os.linesep).join([unicodedata.name(c) for c in u]))
ETHIOPIC SYLLABLE SEE
LATIN SMALL LETTER E WITH ACUTE
EURO SIGN
CJK UNIFIED IDEOGRAPH-3456
CYRILLIC CAPITAL LETTER GJE
COUNTERBORE
ASTERISK

-

cp65001, font: Consolas

D:\jm\jmgoecho ሴé€㑖Ѓ⌴*
ሴé€㑖Ѓ⌴*

As I explained some chars are rendered with the .notdef glyph:
the chars 1, 4 and 7.

I build an exe with the golang. Same result.

Just for curiosity:
XeTeX - pdf: same result.
LucidaConsole CID TrueType, 
Consolas CID TrueType
understand: OpenType

jmf
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread Mark Lawrence

On 14/12/2013 20:48, wxjmfa...@gmail.com wrote:



print((os.linesep).join([unicodedata.name(c) for c in u]))

ETHIOPIC SYLLABLE SEE
LATIN SMALL LETTER E WITH ACUTE
EURO SIGN
CJK UNIFIED IDEOGRAPH-3456
CYRILLIC CAPITAL LETTER GJE
COUNTERBORE
ASTERISK

-

cp65001, font: Consolas

D:\jm\jmgoecho ሴé€㑖Ѓ⌴*
ሴé€㑖Ѓ⌴*

As I explained some chars are rendered with the .notdef glyph:
the chars 1, 4 and 7.

I build an exe with the golang. Same result.

Just for curiosity:
XeTeX - pdf: same result.
LucidaConsole CID TrueType,
Consolas CID TrueType
understand: OpenType

jmf



Where is the Python related issue here?  Why do you keep posting double 
spaced crap, despite repeated requests not to do so?  Or do you blame 
this on the allegedly failed PEP 393 FSR implementation?


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


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread Steven D'Aprano
On Sat, 14 Dec 2013 21:05:05 +, Mark Lawrence wrote:

 On 14/12/2013 20:48, wxjmfa...@gmail.com wrote:

 print((os.linesep).join([unicodedata.name(c) for c in u]))
 ETHIOPIC SYLLABLE SEE
 LATIN SMALL LETTER E WITH ACUTE
 EURO SIGN
 CJK UNIFIED IDEOGRAPH-3456
 CYRILLIC CAPITAL LETTER GJE
 COUNTERBORE
 ASTERISK

 -

 cp65001, font: Consolas

 D:\jm\jmgoecho ሴé€㑖Ѓ⌴*
 ሴé€㑖Ѓ⌴*

 As I explained some chars are rendered with the .notdef glyph: the
 chars 1, 4 and 7.

 I build an exe with the golang. Same result.

 Just for curiosity:
 XeTeX - pdf: same result.
 LucidaConsole CID TrueType,
 Consolas CID TrueType
 understand: OpenType

 jmf


 Where is the Python related issue here?

Read the whole thread before charging in like a bull at a gate accusing 
people of being off-topic. This is on-topic, and if you don't see the 
connection, you need to read the whole thread.


 Why do you keep posting double spaced crap, despite repeated requests
 not to do so?  Or do you blame this on the allegedly failed PEP 393 
 FSR implementation?

I see no double-spacing in the text you quoted.

Do you have nothing better to do than continually hassle people over 
minor formatting issues?

Formatting issues are harmful to the degree they get in the way of 
efficient communication. Since by your own admission you have never 
treated JMF as being credible, there's nothing he can write or say that 
you will believe, so why do you care what he writes? You are not the 
target of his communication unless you choose to be.

Apart from annoying the bystanders, your repeated angry and abusive 
screeds aimed at JMF in particular but others as well over minor 
formatting issues is more disruptive than the issues you are complaining 
about. I am grateful to you for taking the time and effort to write up a 
wiki page on fixing this issues, but gratitude for that will only go so 
far in forgiving disruptive behaviour.


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread Mark Lawrence

On 14/12/2013 22:51, Steven D'Aprano wrote:

On Sat, 14 Dec 2013 21:05:05 +, Mark Lawrence wrote:


On 14/12/2013 20:48, wxjmfa...@gmail.com wrote:



print((os.linesep).join([unicodedata.name(c) for c in u]))

ETHIOPIC SYLLABLE SEE
LATIN SMALL LETTER E WITH ACUTE
EURO SIGN
CJK UNIFIED IDEOGRAPH-3456
CYRILLIC CAPITAL LETTER GJE
COUNTERBORE
ASTERISK

-

cp65001, font: Consolas

D:\jm\jmgoecho ሴé€㑖Ѓ⌴*
ሴé€㑖Ѓ⌴*

As I explained some chars are rendered with the .notdef glyph: the
chars 1, 4 and 7.

I build an exe with the golang. Same result.

Just for curiosity:
XeTeX - pdf: same result.
LucidaConsole CID TrueType,
Consolas CID TrueType
understand: OpenType

jmf



Where is the Python related issue here?


Read the whole thread before charging in like a bull at a gate accusing
people of being off-topic. This is on-topic, and if you don't see the
connection, you need to read the whole thread.


I have.  Going back over this thread the words from Terry Reedy make 
things perfectly clear that this is a *WINDOWS* problem, not a *PYTHON* 
one.  Chris Angelico also weighed in, but again he was simply ignored. 
Instead some completely irrelevant cobblers turned up from Joseph 
McCarthy.






Why do you keep posting double spaced crap, despite repeated requests
not to do so?  Or do you blame this on the allegedly failed PEP 393
FSR implementation?


I see no double-spacing in the text you quoted.


There is no double spacing because for the umpteenth time I've snipped 
the whole damn lot.




Do you have nothing better to do than continually hassle people over
minor formatting issues?


This is *NOT* a minor formatting issue, it's a big PITA that should be 
stopped at source.  It would be easier for this to happen if and only if 
people would stop defending the bug ridden crap tools that are being 
used to send the double spaced crap.


Oh Lord, won't you buy me Mozilla Thunderbird ?
My friends all use GG, I think that's absurd.
Worked hard all my lifetime, no help from the nerds,
So Lord, won't you buy me Mozilla Thunderbird ?



Formatting issues are harmful to the degree they get in the way of
efficient communication. Since by your own admission you have never
treated JMF as being credible, there's nothing he can write or say that
you will believe, so why do you care what he writes? You are not the
target of his communication unless you choose to be.


While he continues to talk crap here I will respond, as I will also 
complain about double spaced google crap until it stops.  I will further 
state again that I find his disgusting, unwarrented attacks on the PEP 
393 FSR indefensible, and are also an attack on the core developers 
who've taken the time to deliver a faster, (relatively) bug free and 
lower memory useage implementation of unicode for Python 3.3+.




Apart from annoying the bystanders, your repeated angry and abusive
screeds aimed at JMF in particular but others as well over minor
formatting issues is more disruptive than the issues you are complaining
about. I am grateful to you for taking the time and effort to write up a
wiki page on fixing this issues, but gratitude for that will only go so
far in forgiving disruptive behaviour.



Your opinion, obviously I disagree, these IMO are *NOT* minor issues, 
and they're also completely avoidable.  Stop the problems at source and 
there are no issues to complain about.  I've written no such thing, I 
simply point it out half a dozen times a day as the latest pile of crap 
turns up here.  Stop the problems at source and there are no issues to 
complain about.  Yes, that's there twice so nobody can miss it.


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


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread Steven D'Aprano
On Sat, 14 Dec 2013 13:43:41 -0500, Terry Reedy wrote:

 This was reported by Victor Stinner as part of
 http://bugs.python.org/issue19914
 to explain how cp65001 causes behavior like this with Python's
 interactive help() function (which more for paging on Windows).
 
   help(str)
 Not enough memory.


Terry, I see you have closed the bug report. I think you were a little 
hasty. The ultimate cause of the bug may be the failure of Window's 
more command when the code-page is set to CP-65001, but that doesn't 
necessarily imply that Python shouldn't, or can't, do something about it.

The interactive help system already supports different pagers, depending 
on the environment. I think that it could fall back on a more primitive 
pager if the preferred one fails. The relevant code is the pager() and 
getpager() functions in the pydoc module. The patch won't be trivial, but 
I think it can be done, and I think it should be done. Although possibly 
for Python 3.5 rather than a bug-fix version. Your thoughts?



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread rusi
On Sunday, December 15, 2013 4:21:08 AM UTC+5:30, Steven D'Aprano wrote:
 Apart from annoying the bystanders, your repeated angry and abusive 
 screeds aimed at JMF in particular but others as well over minor 
 formatting issues is more disruptive than the issues you are complaining 
 about. I am grateful to you for taking the time and effort to write up a 
 wiki page on fixing this issues, but gratitude for that will only go so 
 far in forgiving disruptive behaviour.

I guess you are talking about
https://wiki.python.org/moin/GoogleGroupsPython

As you will see
https://wiki.python.org/moin/GoogleGroupsPython?action=info

most of the edits there are by rurpy and the recent ones
(sorry I missed putting comments) which are for a more automatic solution
are by me.

[No I am not asking for 'gratitude'... just sayin' and giving some context]

There was this ridiculous guy Jonas
https://mail.python.org/pipermail/python-list/2013-October/658671.html

who responded to calls to correct the typical GG mess with more and more
exceptional rudeness
https://mail.python.org/pipermail/python-list/2013-October/658816.html

So I thought to myself: Well this is too much!
And yet while the rudeness is indefensible the technical grumble:
I'm not going to go deleting newlines is not.

Hell! Rather than making a socio-eco-politco-anthropo-marxist-feminist
mess, why dont we fix a technical problem technically??

To me all this GG complaining sounds like some elderly mom-pop-uncle
who weeps/coaxes/moans/pleads/grumbles/ about a fused light bulb,
rather than climbing on a stool and changing the bloody thing.

So, given that I am a programmer I came up (with some tips from Kushal
Kumaran?) with a technical solution.  If I were an ace programmer (can
learn JS in a day and make useful contributions) it would have been a
0-click solution.  [And if I were a super-ace, it would have been a
beneficient virus, that would comb the net, discover all GG users and
self-install without anyone's knowing] Since I am not ace or super-ace
but only a humble programmer (like Dijkstra!) its a 2-click solution
that needs installation :-;

Still, GIVEN THE CONTEXT -- addressing not anyone but an already-GG
user who is clueless about the nuisance he's causing -- I think this
solution is easiest to all.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread Steven D'Aprano
On Sat, 14 Dec 2013 20:42:40 -0800, rusi wrote:

 On Sunday, December 15, 2013 4:21:08 AM UTC+5:30, Steven D'Aprano wrote:
 Apart from annoying the bystanders, your repeated angry and abusive
 screeds aimed at JMF in particular but others as well over minor
 formatting issues is more disruptive than the issues you are
 complaining about. I am grateful to you for taking the time and effort
 to write up a wiki page on fixing this issues, but gratitude for that
 will only go so far in forgiving disruptive behaviour.
 
 I guess you are talking about
 https://wiki.python.org/moin/GoogleGroupsPython
 
 As you will see
 https://wiki.python.org/moin/GoogleGroupsPython?action=info
 
 most of the edits there are by rurpy and the recent ones (sorry I missed
 putting comments) which are for a more automatic solution are by me.

I'm sorry, I was under the impression that Mark had done most of the 
work. I hadn't realised that others had contributed most of the practical 
advice.


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread Terry Reedy

On 12/14/2013 9:39 PM, Steven D'Aprano wrote:

On Sat, 14 Dec 2013 13:43:41 -0500, Terry Reedy wrote:


This was reported by Victor Stinner as part of
http://bugs.python.org/issue19914
to explain how cp65001 causes behavior like this with Python's
interactive help() function (which more for paging on Windows).

   help(str)
Not enough memory.



Terry, I see you have closed the bug report. I think you were a little
hasty.


I might have been premature, but I was not hasty. I read the SO reports 
and though about it for an hour or so while looking at other issues. I 
did not see any use to leaving it open as I did not see any realistic 
propect of a useful and acceptible patch to Python. The OP himself said 
that i/o did not work with 65001 and that not using it fixed his issue.



The ultimate cause of the bug may be the failure of Window's
more command when the code-page is set to CP-65001, but that doesn't
necessarily imply that Python shouldn't, or can't, do something about it.


I believe running Python on Windows with cp=65001 falls in the category 
of Don't do that. This is based on my experiences and the reported 
experience of other developers who have tried and failed to make it 
work, reinforced by the SO thread and a couple of other web pages.



The interactive help system already supports different pagers, depending
on the environment. I think that it could fall back on a more primitive
pager if the preferred one fails.


Do you know if 'more' actually signals failure?
Do you know if there are any other situations in which a pager fails?


The relevant code is the pager() and
getpager() functions in the pydoc module. The patch won't be trivial, but
I think it can be done, and I think it should be done. Although possibly
for Python 3.5 rather than a bug-fix version. Your thoughts?


My thought is that if the only situation in which a pager fails is one 
that one should not use, because other things will also fail, then a 
patch would not be worth the bother.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread Chris Angelico
On Sun, Dec 15, 2013 at 3:42 PM, rusi rustompm...@gmail.com wrote:
 To me all this GG complaining sounds like some elderly mom-pop-uncle
 who weeps/coaxes/moans/pleads/grumbles/ about a fused light bulb,
 rather than climbing on a stool and changing the bloody thing.

No, it's like moaning about Foo Brand light bulbs that die after two
weeks, when there are perfectly good light bulbs that last for years
if you'll just use a different brand. And there are people who say
But Foo Brand light bulbs are easy, you just go up on a ladder every
time you want to turn it on and make sure there's a good bulb in it!.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: CP65001 fails (was re: ...)

2013-12-14 Thread rusi
On Sunday, December 15, 2013 10:30:12 AM UTC+5:30, Steven D'Aprano wrote:
 I'm sorry, I was under the impression that Mark had done most of the 
 work. I hadn't realised that others had contributed most of the practical 
 advice.

To be fair, I added the stuff to the wiki on Mark's prompting.
Earlier was under the impression that not anyone could edit the wiki.
-- 
https://mail.python.org/mailman/listinfo/python-list