[issue14176] Fix unicode literals
Jean-Michel Fauth wxjmfa...@gmail.com added the comment:
2012/3/3 Terry J. Reedy rep...@bugs.python.org
Terry J. Reedy tjre...@udel.edu added the comment:
That would mean in Python 3, '...' works and u'...' will not work.
You misunderstand the PEP: in 3.3, '...' and u'...' will be *exactly* the
same. The only change is that the interpreter will ignore the u prefix
instead of raising SyntaxError. It will be as if 'u' were not there. The
only purpose is to let 2.x code run in 3.x without requiring the user to
erase the 'u'.
I can see how you could misunderstand and think that the 'u' prefix must
have some meaning. But is does not. The addition is a bit controversial but
Guido approved it with the expectation that it will encourage more
conversion of 2.x libraries to run on 3.3. In any case, the tracker is not
the place for further discussion of the value of the PEP.
Once again, an *illustration* with IDLE / Py2.
...
Of course, this is actually a no problem with Py 3.
...
It still remains that this is a serious problem on Py 2.
We are painfully aware that 2.x has problems with unicode. You do not need
to tell us. I believe that most of the problems that could be sensibly
fixed in 2.x have been fixed. 3.0 fixed more problems by changing the
language. 3.3 fixes still more problems by changing the internal
implementation of unicode, along with the C api, and the meaning of the
language on some systems. People who want to avoid all the problems that
have been fixed should use 3.3 either from the repository or when it is
released.
So, if this (u'...') works in Py 3.3, the problem can
be considered as solved.
I am glad you agree and I will close the issue.
Preliminary remark. I'm sending this via gmail, so it
may happen the glyphs you see are illformed or
transfomred by Google. Be ensured I'm typing the
right glyphs.
No, no and no. This is not a tkinter issue. This
strange behaviour, I do not find a better word,
happens with many libraries, can be Python core libs
or external libs.
To tell you the truth and dispite my experience,
I never succeeded to narrow excatly the problem.
In Python 2 sometimes, understand with some pieces
of code / software, it works and somtimes it
simply does not. The libs used here a just the
first ones, that came to my mind.
-
wxPython 2.8-ansi build.
Traceback (most recent call last):
File input, line 1, in module
File c:\python27\lib\site-packages\wx-2.8-msw-ansi\wx\py\shell.py, line
1242, in writeOut
self.write(text)
File c:\python27\lib\site-packages\wx-2.8-msw-ansi\wx\py\shell.py, line
1000, in write
self.AddText(text)
File c:\python27\lib\site-packages\wx-2.8-msw-ansi\wx\stc.py, line
1425, in AddText
return _stc.StyledTextCtrl_AddText(*args, **kwargs)
File c:\python27\lib\encodings\cp1252.py, line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode characters in position
4-5: character maps to undefined
abc需
PySide, passing unicode to a text widdget.
Passing u'abc需' works.
Passing unicode('abc需', 'cp1252') works.
Passing 'abc逜' doesn't ! 'œ€' are missing.
---
My interactive wx interpreter using wxPython. Strings
as frame title.
True
ok
Traceback (most recent call last):
File psi last command, line 1, in module
File
c:\Python27\lib\site-packages\wx-2.8-msw-ansi\wx\_windows.py,
line 505, in __init__
_windows_.Frame_swiginit(self,_windows_.new_Frame(*args,
**kwargs))
File c:\Python27\lib\encodings\cp1252.py, line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode characters in
position 5-6: character maps to undefined
True
ok
---
And so on with many libs.
You may argue that these libs are guilty.
I may argue that Python is somehow guilty, because it
let users write non working code.
And practically in all the cases, the main problem is due
to the usage of unicode literals.
Just to show you, I'm quite comfortable with all this
coding stuff. The results my interactive intepreter.
Special hack, unfortunatelly non portable, works
only with Windows and cp1252.
abcé??
unicode('abc需', sys.stdout.encoding)
abc需
print u'abc需'
abcé??
print unicode('abc需', sys.stdout.encoding)
abc需
As I am aware of this feature, all my code is
perfectly working. I'm paying attention to the
necessity of the usage of u'...' or unicode(...).
Unfortunatelly, this not a general case in a lot of
code I see, supposed to deal with texts.
To draw a conclusion.
You are wise enough to understand that, when I'm
saying Python just does not work, I'm unforunatelly
not so far away form the reality.
I really, very really, expect all this mess (sorry
for the word) will not reappear in Py 3.3.
Let's wait.
'abc需'
print('abc需')
abc需
Regards,
Jean-Michel Fauth
PS The u() trick does not help.
--
nosy: +jmfauth
[issue14176] Fix unicode literals (for PEP 414)
New submission from Jean-Michel Fauth wxjmfa...@gmail.com: Now, that the PEP 414 has been accepted, I can only strongly recommend to fix the problem of unicode literals as a partial workaround. print u'abcœé€' abcé If these six characters are not rendered correctly, you shoud read: LATIN SMALL LETTER A LATIN SMALL LETTER B LATIN SMALL LETTER C LATIN SMALL LIGATURE OE LATIN SMALL LETTER E WITH ACUTE EURO SIGN It is not necessary to give here the list of the numerous libs that do not understand u'unicode literals' as shown above. (I wrote all my Py2 code in a u'unicode mode', and I know how hard it is to have to select between the u'' or unicode() variants. Face it. Python has never worked [*], Python does not work, Python will never work. More important, it is more than clear to me, there is no willingness to solve this issue. (The holy compatibilty with not working code). [*] Except the pure ASCII serie (Py 1.5) and the Python 3[0,1,2] serie. No offense. I'm pretty sure the creator of this PEP is not even able to type on his machine the list of the 42 characters supposed to be available it the typographies (plural) used by the different countries speaking French. The whole free/open source software disaster in all its splendor. Regards. jmf -- components: None messages: 154763 nosy: Jean-Michel.Fauth priority: normal severity: normal status: open title: Fix unicode literals (for PEP 414) versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14176] Fix unicode literals (for PEP 414)
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: I deliberately hid the information about the used interactive interpreter; just to show you the experience of new Python user. (This is what I'm showing to potential Python devs who are interested in this tool; I know Python and use it since v. 1.5.6 as a non computer scientist). The interactive interpreter was: Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32 Type copyright, credits or license() for more information. In that precise case, it was Windws 7 Pro (Windows 7 Professionnel, in French because of a Swiss French version) and IDLE is just the IDLE an end user see after a fresh installation. I can ensure you, such a behaviour exists / existed on all Windows versions I used (from Win98, win2000, ...) with all the Python 2 versions since the unicode introduction. The technical reasons/aspects: sys.defaultencoding, non iso-8859-1 chars [#], *non working unicode literals*, sys.stdout.encoding = 'cp1252' and so on. [#] For those who do not know, one can not write text in French with Latin-1. Please do not take my aggressive (I recognize it), but sometimes necessary message badly. IDLE is not the cause, I use here IDLE to show as an example the disaster of code containing *unicode literals*. I'm not really happy to see this mess again in Py3.3 [†]; the key point beeing *unicode literals*. The Pandora's box is opened. [†] In fact, I will somehow never see or suffer from it. Decisions have been taken. jmf -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14176] Fix unicode literals (for PEP 414)
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: Sorry, I neglected the most important information. Python 3.2 is working perfectly. It is simply impossible to create non valid strings (type/class 'str') from a keyboard. (non programmatically created). Like the limited characters set I used when I wrote my first program on a PDP-8. Porting Py 2 code was a child play. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14176] Fix unicode literals
Jean-Michel Fauth wxjmfa...@gmail.com added the comment:
You do not get it or I do not explain it correctly.
I do not care if Py 3.3 accepts '...' ou u'...'. I'm only
affraid, Py 3.3 is suffering from the same non working
behaviour Python 2 is suffering. I have seen so many things...
I can only use an Py2/Py3 analogy, the types beeing differnt.
In Python 2, the u'...' and the unicode('...', 'coding') are
not equivalent. This leads and has lead to a lot of non
working code. unicode() is always working, while u'...'
may not work. A lot of libs, are accepting unicode() and are
failing in having to accept u'...'.
That would mean in Python 3, '...' works and u'...' will not work.
Once again, an *illustration* with IDLE / Py2.
import unicodedata as ud
for c in u'abc需':
print ud.name(c)
LATIN SMALL LETTER A
LATIN SMALL LETTER B
LATIN SMALL LETTER C
LATIN SMALL LETTER E WITH ACUTE
Traceback (most recent call last):
File pyshell#3, line 2, in module
print ud.name(c)
ValueError: no such name
# but
import sys
for c in unicode('abc需', sys.stdout.encoding):
print ud.name(c)
LATIN SMALL LETTER A
LATIN SMALL LETTER B
LATIN SMALL LETTER C
LATIN SMALL LETTER E WITH ACUTE
LATIN SMALL LIGATURE OE
EURO SIGN
A course, this is actually a no problem with Py 3.
I know nothing about the internal of Python. I have however
noticed this guilty behaviour happen especially with non
iso-8859-1 chars, valid byte string chars but equivalent chars
with unicode code point 255. Infortunately, all these chars
which are so important in French. (I heared about similar problems
with the mac-roman coding. I do not know the status).
So, if this (u'...') works in Py 3.3, the problem can
be considered as solved.
At least you have been informed about this potential issue.
It still remains that this is a serious problem on Py 2.
jmf
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14176
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13610] On Python parsing numbers.
Jean-Michel Fauth wxjmfa...@gmail.com added the comment:
I have done a little bit hd/files archeology and
found some of my comments.
Pointing on number litterals is probably wrong. The fact
is that, this happens with practically any expression. And
strangely, not all keywords (constructs?) are affected.
999if 1 else 888
999
if 1 else 888
{1: 'a'}if 1 else 888
{1: 'a'}
999 if 'a' else 888
999
999if 'a' else 888
999
999if 'a'else 888
999
999if 888else 888
File eta last command, line 1
999if 888else 888
^
SyntaxError: invalid token
999if else 888
888
To summarize: The Python syntax does not require an isolated
keyword, something like \bkeyword\b.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13610
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13610] On Python parsing numbers.
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: Ezio Melotti Good catch. I'm not complaining. I just find funny to see the number of editors not colorizing this kind of Python valid expressions. (IDLE included) For me, subject close. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13610] On Python parsing numbers.
New submission from Jean-Michel Fauth wxjmfa...@gmail.com: Can this be fixed? As far as I can remember (ver. 1.5.6), it has always existed. Python does not crash, I find it inelegant. Should it not be a SyntaxError? Side effect. Searching for keywords, (eg. with re, \b) may practically always implies to handle this case separately. Python all versions. 1and 0 0 1or 0 1 9if True else 22 9 0.1234if True else 22 0.1234 [999for i in range(3)] [999, 999, 999] -- components: Interpreter Core messages: 149596 nosy: Jean-Michel.Fauth priority: normal severity: normal status: open title: On Python parsing numbers. versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12736] Request for python casemapping functions to use full not simple casemaps per Unicode's recommendation
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: Œ, œ or even are historically ligatures or ligatured forms. In the French typography, they are single plain letters and they belong the group of the 42 letters used in the French typography. Typographically speaking, using oe instead of œ is considered as a mistake, while not using the ligatured forms for the groups of letters like ff, ffi, ffl, fj, et, st is acceptable. Microsoft with cp1252, Apple with mac-roman, Adobe and all foundries and now Unicode are working correctly. It should be noted, when TeX moved from the ascii to iso-8859-1 (more precisely CorkEncoding) as default encoding, they saw the problem and introduced the \oe or \OE commands. From my understanding and my point of view on the subject, ISO has somehow recognized his mistake by introducing iso-8859-15. Infortunatelly, it was too late. To the subject: Œdipe: correct, Oedipe, OEdipe: incorrect. Without beeing an expert on that field, all the informations one can find on Wikipedia (French) regarding questions about typography are generally correct. -- nosy: +Jean-Michel.Fauth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10920] cp65001, PowerShell, Python crash.
New submission from Jean-Michel Fauth wxjmfa...@gmail.com: Just relying a discussion open on comp.lang.python, http://groups.google.com/group/comp.lang.python/browse_thread/thread/771aa9081ad6584c# 1) Windows 7, open PowerShell 2) Change code page to cp65001 3) Launch Python3.1.2 or Python3.2.rc1 - crash Key points: - The fact that Python does not recognize cp65001 is ok. - The Python crash is unexpected. -- components: Windows messages: 126370 nosy: Jean-Michel.Fauth priority: normal severity: normal status: open title: cp65001, PowerShell, Python crash. type: crash versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8895] newline arg/attribute in the module io
New submission from Jean-Michel Fauth wxjmfa...@gmail.com:
I was confused about the newline argument/attribute
in the misc. classes of the io module until I realize
there is a spelling issue between the docs and the
real implementation. (Py 2.6.5, Py2.7b2). Py 3.x not
tested.
sys.version
2.7b2 (r27b2:81019, May 9 2010, 11:33:14) [MSC v.1500 32 bit (Intel)]
sio = io.StringIO(u'abc')
sio.encoding, type(sio.encoding)
(None, type 'NoneType')
sio.errors, type(sio.errors)
(None, type 'NoneType')
sio.newline, type(sio.newline)
Traceback (most recent call last):
File psi last command, line 1, in module
AttributeError: '_io.StringIO' object has no attribute 'newline'
sio.newlines, type(sio.newlines)
(None, type 'NoneType')
tio = io.TextIOWrapper(io.BytesIO())
tio.buffer, type(tio.buffer)
(_io.BytesIO object at 0x02E6E600, type '_io.BytesIO')
tio.encoding, type(tio.encoding)
('cp1252', type 'str')
tio.errors, type(tio.errors)
('strict', type 'str')
tio.line_buffering, type(tio.line_buffering)
(False, type 'bool')
tio.newline, type(tio.newline)
Traceback (most recent call last):
File psi last command, line 1, in module
AttributeError: '_io.TextIOWrapper' object has no attribute 'newline'
tio.newlines, type(tio.newlines)
(None, type 'NoneType')
sys.version
2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
import io
tio = io.TextIOWrapper(io.BytesIO())
tio.encoding, type(tio.encoding)
('cp1252', type 'str')
tio.line_buffering, type(tio.line_buffering)
(False, type 'bool')
tio.errors, type(tio.errors)
(u'strict', type 'unicode')
tio.newline, type(tio.newline)
Traceback (most recent call last):
File psi last command, line 1, in module
AttributeError: 'TextIOWrapper' object has no attribute 'newline'
tio.newlines, type(tio.newlines)
(None, type 'NoneType')
[e for e in dir(tio) if 'new' in e]
['__new__', 'newlines']
--
components: IO
messages: 107017
nosy: jmfauth
priority: normal
severity: normal
status: open
title: newline arg/attribute in the module io
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8895
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8895] newline vs. newlines in io module
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: 2010/6/4 R. David Murray rep...@bugs.python.org R. David Murray rdmur...@bitdance.com added the comment: This is as documented: http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines The keyword argument is named 'newline', the attribute is named 'newlines'. The attribute does not record what was passed to the newline argument, rather it records what newlines have been actually encountered. Ok, I see. I read, reread the doc prior posting, and, in my mind, it is not obvious to understand this subtle difference from the doc. Sorry for the noise. Regards. -- Added file: http://bugs.python.org/file17549/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8895 ___brbrdiv class=gmail_quote2010/6/4 R. David Murray span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/spanbrblockquote class=gmail_quote style=margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; br R. David Murray lt;a href=mailto:rdmur...@bitdance.com;rdmur...@bitdance.com/agt; added the comment:br br This is as documented:br br  a href=http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines; target=_blankhttp://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines/abr br The keyword argument is named #39;newline#39;, the attribute is named #39;newlines#39;.  The attribute does not record what was passed to the newline argument, rather it records what newlines have been actually encountered.br /blockquote/divbrOk, I see. I read, reread the doc prior posting, and, in my mind, it is not obvious to understand this subtle difference from the doc.brSorry for the noise.brRegards.brbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8895] newline vs. newlines in io module
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: 2010/6/4 Ãric Araujo rep...@bugs.python.org Ãric Araujo mer...@netwok.org added the comment: Could you think of a way to improve the docs on that point? -- Quick and dirty answer. I have ~10 years experience with Python and it seems to me the io module is technically excellent. However, I have found it is not so obvious to understand the usage of all these arguments, errors, encoding, line_buffering, ... in the class constructors and methods like io.open(). The doc describes what these arguments are, their states, but not too much how to use them. As an exemple, I read some time ago on the c.l.p mailing list, somebody complaining about the encoding argument of the class TextIOWrapper. He defined an encoding='utf-8' in the ctor and did not understand why his text was not automagically encoded. Answer: the encoding arg is only a kind of information and does not do anything. BTW, it was only when I read that post, I understand a little bit more. Regards. -- Added file: http://bugs.python.org/file17553/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8895 ___brbrdiv class=gmail_quote2010/6/4 Ãric Araujo span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/spanbrblockquote class=gmail_quote style=margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; br Ãric Araujo lt;a href=mailto:mer...@netwok.org;mer...@netwok.org/agt; added the comment:br br Could you think of a way to improve the docs on that point?br br --br divdiv/divdiv class=h5br/div/div/blockquote/divQuick and dirty answer.brbrI have ~10 years experience with Python and it seemsbrto me the io module is technically excellent.brbrHowever, I have found it is not so obvious tobr understand the usage of all these arguments,brerrors, encoding, line_buffering, ... in the brclass constructors and methods like io.open().brbrThe doc describes what these arguments are,brtheir states, but not too much how to usebr them.brbrAs an exemple, I read some time ago on the c.l.pbrmailing list, somebody complaining about the quot;encodingquot;brargument of the class TextIOWrapper. He defined an brquot;encoding=#39;utf-8#39;quot; in the ctor and did notbr understand why his quot;textquot; was not automagicallybrencoded. Answer: the encoding arg is only a kindbrof information and does not do anything.brbrBTW, it was only when I read that post, I understandbra little bit more.br brRegards.brbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8185] re.findall()
New submission from Jean-Michel Fauth wxjmfa...@gmail.com: sys.version 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] import re re.match([-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?, 1.23e-4).group() 1.23e-4 re.search([-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?, 1.23e-4).group() 1.23e-4 for e in re.finditer([-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?, 1.23e-4): print e.group() 1.23e-4 but re.findall([-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?, 1.23e-4) ['e-4'] It seems re.findall() does not like patterns containing parentheses. re.findall([-+]?[0-9]+[.]?[0-9]*[eE][-+]?[0-9]+, 1.23e-4) ['1.23e-4'] re.findall(a(b)?, ab) ['b'] re.findall(ab?, ab) ['ab'] -- components: Regular Expressions messages: 101381 nosy: jmfauth severity: normal status: open title: re.findall() versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8137] Missing iso-8859-16 codec in the docs
New submission from Jean-Michel Fauth wxjmfa...@gmail.com: The codecs — Codec registry and base classes part of the documentions (Python 2.6.4, 2.7.a?, 3.1.1) does not mention the existence of the iso-8859-16 codec. -- assignee: georg.brandl components: Documentation messages: 101047 nosy: georg.brandl, jmfauth severity: normal status: open title: Missing iso-8859-16 codec in the docs versions: Python 2.6, Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8121] Typo in cStringIO
New submission from Jean-Michel Fauth wxjmfa...@gmail.com:
There is a malformed string in the module cStringIO.
StringI -- StringIO
sys.version
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
StringIO.StringIO('123')
StringIO.StringIO instance at 0x02D230D0
cStringIO.StringIO('123')
cStringIO.StringI object at 0x0183ECB0
--
components: None
messages: 100920
nosy: jmfauth
severity: normal
status: open
title: Typo in cStringIO
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8121
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8121] Typo in cStringIO
Jean-Michel Fauth wxjmfa...@gmail.com added the comment:
Wow! I never been aware of this (documentation, dir(), __doc__)
Indeed:
cStringIO.StringIO()
cStringIO.StringO object at 0x02D94F40
cStringIO.StringIO('abc')
cStringIO.StringI object at 0x016DE920
Sorry for the noise.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8121
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7660] Two float('nan') are not equal
New submission from Jean-Michel Fauth wxjmfa...@gmail.com:
I did not find any report about this.
Windows 7, Python 2.6.4
float('inf') == float('inf')
True
float('-inf') == float('-inf')
True
float('-inf') == float('inf')
False
float('-inf') != float('inf')
True
float('nan') == float('nan')
False
float('nan') != float('nan')
True
I'm not an expert on that field, I wonder if the following is
not related to a sign bit missmatch, see also Python 3.1.1 below.
copysign(1, float('inf'))
1.0
copysign(1, float('-inf'))
-1.0
copysign(1, float('nan'))
-1.0
copysign(1, float('-nan'))
-1.0
Windows 7, Python 3.1.1
float('inf') == float('inf')
True
float('-inf') == float('-inf')
True
float('-inf') == float('inf')
False
float('-inf') != float('inf')
True
float('nan') == float('nan')
False
float('nan') != float('nan')
True
Same behaviour as with Python 2.6.4
copysign(1, float('inf'))
1.0
copysign(1, float('-inf'))
-1.0
copysign(1, float('nan'))
-1.0
copysign(1, float('-nan'))
1.0
Different behaviour from Python 2.6.4
--
components: None
messages: 97432
nosy: jmfauth
severity: normal
status: open
title: Two float('nan') are not equal
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7660
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7426] StringIO and with statement
New submission from Jean-Michel Fauth wxjmfa...@gmail.com:
When toying with the with statement, I fell on this:
Python 2.6.4
with open('abc.txt', 'r') as f:
for line in f:
print line.rstrip()
abc
def
import StringIO
fo = StringIO.StringIO('abc\ndef\n')
fo.seek(0)
with fo as f2:
for line in f2:
print line.rstrip()
Traceback (most recent call last):
File psi last command, line 2, in module
AttributeError: StringIO instance has no attribute '__exit__'
Same result with cStringIO
-
Python 3.1.1
fo = io.StringIO('abc\ndef\n')
fo.seek(0)
0
with fo as f:
for line in f:
print(line.rstrip())
abc
def
--
components: None
messages: 95924
nosy: jmfauth
severity: normal
status: open
title: StringIO and with statement
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7426
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4015] [patch] make installed scripts executable on windows
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: It is true, that on Windows the mime types, .py, .pyw point to a specific version of Python. Having Python 2.4, 2.5, 2.6, 3.0, 3.1 installed on my hd and applications using these (different) versions, I am *very glad* on that system, all versions, including \site-packages, are isolated from each other. Technically, one can argue a Python developer/user should be able to write a one line batch file if necessary. Compared to *x systems, I have always found the Windows way as being very clean and flexible. -- nosy: +jmfauth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4626] compile() doesn't ignore the source encoding when a string is passed in
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: Quick feedback from a Windows user. I made a few more tests with the freshly installed Pyton 3.1a1. The compile() function is running very well. As a side effect, it now possible to write an execfile() without any problem. Tests with execfile() versions reading files as text or as binary, with/without coding cookies, BOM, cp1252, cp850, cp437, utf-8 cookie, utf-8 with bom, (Of course, taking in account and managing universal newline). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4626] compile() doesn't ignore the source encoding when a string is passed in
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: Victor Yes, I could, but I think this is not an IDLE issue, I'm just using IDLE to illustrate the problem. I got the same when I'm working from within an editor or with my interactive interpreter I wrote for the fun. Code in the editor: # -*- coding: cp1252 -*- # Python 3.0.1, winxp sp2 from code import InteractiveInterpreter ii = InteractiveInterpreter() source = b'print(999)' ii.runsource(source) Output: c:\python30\pythonw -u uuu.py Traceback (most recent call last): File uuu.py, line 8, in module ii.runsource(source) File c:\python30\lib\code.py, line 63, in runsource code = self.compile(source, filename, symbol) File c:\python30\lib\codeop.py, line 168, in __call__ return _maybe_compile(self.compiler, source, filename, symbol) File c:\python30\lib\codeop.py, line 70, in _maybe_compile for line in source.split(\n): TypeError: Type str doesn't support the buffer API Exit code: 1 My interactive interpreter --- from code import InteractiveInterpreter --- ii = InteractiveInterpreter() --- source = b'print(999)' --- ii.runsource(source) Traceback (most recent call last): File smid last command, line 1, in module File c:\Python30\lib\code.py, line 63, in runsource code = self.compile(source, filename, symbol) File c:\Python30\lib\codeop.py, line 168, in __call__ return _maybe_compile(self.compiler, source, filename, symbol) File c:\Python30\lib\codeop.py, line 70, in _maybe_compile for line in source.split(\n): TypeError: Type str doesn't support the buffer API --- === I realised and missed the fact the str() function is now accepting an encoding argument (very good). With it, the above code works. Code in the editor: # -*- coding: cp1252 -*- # Python 3.0.1, winxp sp2 from code import InteractiveInterpreter ii = InteractiveInterpreter() source = b'print(999)' source = str(source, 'cp1252') # ii.runsource(source) Output: (ok) c:\python30\pythonw -u uuu.py 999 Exit code: 0 === In a few words, my empirical understanding of the story. 1) Things are in good shape, but Python, itsself and its components (compile, interactiveinterpreter module, runsource(), exec(), ...) are lacking in consistency, the all accept miscellanous arguments type or they are not strict enough in their arguments acceptance. When they accept a str, which encoding is accepted? 2) Python 3 is now using unicode as str. Of course, this is welcome, but the caveat is that there are now two encodings in use. Code source defaults to utf-8, but the str in code defaults to ucs-2/4 (eg. in IDLE). 3) Maybe a solution is to have an optional encoding argument as we now have everywhere eg. str(), open(), which defaults to one encoding. compile(source, filename, encodings='utf-8', ...) (Problem: BOM, coding cookies?). I suspect the miscellaneous discussions one finds from people attempting to write a correct execfile() for Python 3 are coming from this. Regards. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4626] compile() doesn't ignore the source encoding when a string is passed in
Jean-Michel Fauth wxjmfa...@gmail.com added the comment: I'm glad to have discovered this topic. I bumped into something similar when I toyed with an interactive interpreter. from code import InteractiveInterpreter ii = InteractiveInterpreter() source = ... ii.runsource(source) What should be the encoding and/or the type (str, bytes) of the source string? Taking into account the encoding of the script which contains this code, I have the feeling there is always something going wrong, this can be a non ascii char in the source (encoded in utf-8!) or the interactive interpreter does not accept very well a byte string representing a utf-8 encoded string. IDLE is not suffering from this. Its interactive interpreter is somehow receiving ucs-2 ready string from tkinter. I'm a little bit confused here (win2k, winXP sp2, Python 3.0.1). -- nosy: +jmfauth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5556] interactive interpreter, source encoding
New submission from Jean-Michel Fauth wxjmfa...@gmail.com: A few hours ago I sent a comment to the issue #4626. I didn't notice the issue was closed. So I repeat it here. I'm interested in comments because I have the feeling it is still a pending annoying isssue. --- I'm glad to have discovered this topic. I bumped into something similar when I toyed with an interactive interpreter. from code import InteractiveInterpreter ii = InteractiveInterpreter() source = ... ii.runsource(source) What should be the encoding and/or the type (str, bytes) of the source string? Taking into account the encoding of the script which contains this code, I have the feeling there is always something going wrong, this can be a non ascii char in the source (encoded in utf-8!) or the interactive interpreter does not accept very well a byte string representing a utf-8 encoded string. IDLE is not suffering from this. Its interactive interpreter is somehow receiving ucs-2 ready string from tkinter. I'm a little bit confused here (win2k, winXP sp2, Python 3.0.1). -- components: Interpreter Core messages: 84107 nosy: jmfauth severity: normal status: open title: interactive interpreter, source encoding type: behavior versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4337] Iteration over a map object with list()
New submission from Jean-Michel Fauth [EMAIL PROTECTED]:
win XP sp2, Py3.0c2
I had to face an annoying problem when iterating over a map object.
With a range class, this works
r = range(5)
list(r)
[0, 1, 2, 3, 4]
With dict_keys/values/items objects, the following works
d = {1: 'a', 2:'b', 3:'c'}
list(d.keys())
[1, 2, 3]
list(d.values())
['a', 'b', 'c']
list(d.items())
[(1, 'a'), (2, 'b'), (3, 'c')]
But with a map object...
def plus(i):
return i + 1
a = list(range(3))
a
[0, 1, 2]
r = map(plus, a)
r
map object at 0x01371570
for e in r: print(e)
1
2
3
list(r)
[]
#empty list!
Bug or feature?
--
components: None
messages: 75965
nosy: jmfauth
severity: normal
status: open
title: Iteration over a map object with list()
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4337
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4337] Iteration over a map object with list()
Jean-Michel Fauth [EMAIL PROTECTED] added the comment: 2008/11/17 Raymond Hettinger [EMAIL PROTECTED] Raymond Hettinger [EMAIL PROTECTED] added the comment: Feature :-) You will get the expected result if you skip the step where you ran the for-loop over r before running list(). Either listing or for-looping will exhaust the iterator. This is how iterators work. -- nosy: +rhettinger resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4337 ___ Thanks for the reply and sorry for the noise. Indeed, you are right and for some strange personal reasons (bad habits?), I frequently fall in this trap. return i + 1 [1, 2, 3, 4] Regards Added file: http://bugs.python.org/file12039/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4337 ___brbrdiv class=gmail_quote2008/11/17 Raymond Hettinger span dir=ltrlt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;/spanbrblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; br Raymond Hettinger lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; added the comment:br br Feature :-)br br You will get the expected result if you skip the step where you ran thebr for-loop over r before running list(). nbsp;Either listing or for-loopingbr will exhaust the iterator. nbsp;This is how iterators work.br br --br nosy: +rhettingerbr resolution: nbsp;-gt; invalidbr status: open -gt; closedbr divdiv/divdiv class=Wj3C7cbr ___br Python tracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue4337; target=_blankhttp://bugs.python.org/issue4337/agt;br ___br /div/div/blockquote/divbrThanks for the reply and sorry for the noise. Indeed, you are right and for some quot;strange personal reasonsquot; (bad habits?), I frequently fall in this trap.brbrgt;gt;gt; def plus(i):br nbsp;nbsp;nbsp; return i + 1brbrgt;gt;gt; list(map(plus, range(4)))br[1, 2, 3, 4]brgt;gt;gt; brbrRegardsbrbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3995] iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*
New submission from Jean-Michel Fauth [EMAIL PROTECTED]:
XP SP2 fr_CH cp1252
I have always found, there are some inconsistencies in the Python =2.5
serie regarding the char endodings, especially the iso-8859-1, cp1252,
iso-8859-15 encodings.
I do not know if this must be considered as a bug or as a feature.
Python is quite friendly with these encodings. It may not be a problem
for a daily work, it is more acute when one wish to teach the
chararacter encodings.
char œ: code point 156 in cp1252
char €: code point 128 in cp1252
Python 2.5.2
unicode('œ', 'cp1252')
u'\u0153'
unicode('€', 'cp1252')
u'\u20ac'
unicode('œ', 'iso-8859-15')
u'\x9c'
unicode('€', 'iso-8859-15')
u'\x80'
unicode('€', 'iso-8859-1') #***
u'\x80'
unicode('œ', 'iso-8859-1') #***
u'\x9c'
#*** should raise an error since œ and €
#are not existing in an iso-8859-1 table.
It looks like iso-8859-1 behaves as iso-8859-15 (typo somewhere?)
Python 3.0 rc1 does the job correctly and notices the difference
bytes('œ', 'cp1252')
b'\x9c'
bytes('€', 'cp1252')
b'\x80'
bytes('œ', 'iso-8859-15')
b'\xbd'
bytes('€', 'iso-8859-15')
b'\xa4'
bytes('œ', 'iso-8859-1')
Traceback (most recent call last):
File pyshell#5, line 1, in module
bytes('œ', 'iso-8859-1')
UnicodeEncodeError: 'latin-1' codec can't encode character '\u0153' in
position 0: ordinal not in range(256)
bytes('€', 'iso-8859-1')
Traceback (most recent call last):
File pyshell#6, line 1, in module
bytes('€', 'iso-8859-1')
UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in
position 0: ordinal not in range(256)
# these errors are expected
Python 2.6**
The latest version is not installed. If I recall correcly, 2.6b* are
presenting the same issue as in 2.5.2 .
--
messages: 74017
nosy: jmfauth
severity: normal
status: open
title: iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*
versions: Python 2.5
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3995
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3943] IDLE won't start in 3.0rc1 Subprocess didn't make connection....
Jean-Michel Fauth [EMAIL PROTECTED] added the comment: I think the problem is fixed. See issue 3905. -- nosy: +jmfauth ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3922] 3.0rc1 missing tk lib in sys.path?
New submission from Jean-Michel Fauth [EMAIL PROTECTED]: 3.0rc1: When toying and attempting to import the scrolledtext module, I noticed the tkinter library path is no more by default included in the sys.path. Unfortunate omission or new Python 3.0 design? C:\Python30python Python 3.0rc1 (r30rc1:66507, Sep 18 2008, 14:47:08) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import sys for e in sys.path: print(e) ... C:\Python30\python30.zip C:\Python30\DLLs C:\Python30\lib C:\Python30\lib\plat-win C:\Python30 C:\Python30\lib\site-packages C:\Python26python Python 2.6rc2 (r26rc2:66507, Sep 18 2008, 14:27:33) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import sys for e in sys.path: print e ... C:\Python26\python26.zip C:\Python26\DLLs C:\Python26\lib C:\Python26\lib\plat-win C:\Python26\lib\lib-tk C:\Python26 C:\Python26\lib\site-packages -- components: Library (Lib) messages: 73508 nosy: jmfauth severity: normal status: open title: 3.0rc1 missing tk lib in sys.path? type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2384] [Py3k] line number is wrong after encoding declaration
Jean-Michel Fauth [EMAIL PROTECTED] added the comment: Python 3.0rc1 If the lines are now displayed correctly, I think there is still a numbering issue, a +1 offset. Python 2.5.2 # -*- coding: cp1252 -*- line 1, first line s = 'abc' import dummy s = 'def' --- pythonw -u testpy2.py Traceback (most recent call last): File testpy2.py, line 4, in module import dummy ImportError: No module named dummy Exit code: 1 Python 3.0rc1 # -*- coding: cp1252 -*- s = 'abc' import dummy s = 'def' --- c:\python30\pythonw -u testpy3.py Traceback (most recent call last): File testpy3.py, line 5, in module s = 'def' ImportError: No module named dummy Exit code: 1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2384 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3905] subprocess failing in GUI applications on Windows
Jean-Michel Fauth [EMAIL PROTECTED] added the comment: Georg Brandl Thanks, patch applied on w2k+sp4 box, swiss french, Python 3.0rc1. IDLE is working fine. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3905] subprocess failing in GUI applications on Windows
Jean-Michel Fauth [EMAIL PROTECTED] added the comment: Just for information and from an end user perspective. I have tried to replace the socketserver.py from the original 3.0rc1 distribution by the socketserver.py as proposed by Benjamin Peterson (r66520). Script difference (line 568): if self.daemon_threads: t.daemon = True t.start() and if self.daemon_threads: t.set_daemon(True) t.start() Unfortunately, no luck, I'm still getting exactly the same error messages, the msg box and the raised AttributeError: AttributeError: 'Thread' object has no attribute 'set_daemon' ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3905] subprocess failing in GUI applications on Windows
Jean-Michel Fauth [EMAIL PROTECTED] added the comment: I do not really know if this is related to this, but I suspect yes. On my w2k+sp4 box, swiss french, Python 3.0rc1, IDLE does not start or more precisely it starts by opening the following message box: Subprocess Startup Error --- IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection. It is certainly neither a firewall issue, nor a tkinter issue (tkinter applications are working fine.) No problem with the 3.0b2 realease, 3.0b3: not tested. -- nosy: +jmfauth ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3905] subprocess failing in GUI applications on Windows
Jean-Michel Fauth [EMAIL PROTECTED] added the comment: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\cd python30 C:\Python30python Lib/idlelib/idle.py Traceback (most recent call last): File string, line 1, in module File C:\Python30\lib\idlelib\run.py, line 76, in main sockthread.set_daemon(True) AttributeError: 'Thread' object has no attribute 'set_daemon' C:\Python30 Sorry if I can help here, things like socket and subprocess are not my cup of tea. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2384] [Py3k] line number is wrong after encoding declaration
Jean-Michel Fauth [EMAIL PROTECTED] added the comment: Py3.0b2. This bug seems to be quite annoying. Especially when one works with a main module importing modules which are importing modules and so on, all modules having an encoding declaration. The Traceback (and the user) is (are) a little bit lost. - # -*- coding: cp1252 -*- # modb.py def fb(): i = 1 j = 0 r = i / j --- # -*- coding: cp1252 -*- # moda.py import modb def fa(): modb.fb() --- # -*- coding: cp1252 -*- # main.py import moda def main(): moda.fa() if __name__ == '__main__': main() --- Running main.py leads to an c:\python30\pythonw -u main.py (Traceback (most recent call last): File main.py, line 11, in module File main.py, line 8, in main File C:\jm\jmpy3\moda.py, line 8, in fa File C:\jm\jmpy3\modb.py, line 8, in fb ZeroDivisionError: int division or modulo by zero Exit code: 1 -- nosy: +jmfauth ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2384 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
