[issue12913] Add a debugging howto
Ezio Melotti added the comment: > Hadn’t though about coverage. Will mention it and add a link > to the devguide part that talks about it. Is devguide/coverage.html#using-coverage-py generic enough? We don't have to duplicate the coverage documentation though, mentioning the tool and what it does, provide a couple of simple example and a link to the coverage doc should be enough. Talking about unittest and coverage is not strictly about debugging (you don't have any bug yet), but it's useful because it might reveal bugs earlier and avoid debugging sessions later. This might also go with pyflakes and friends, since they both provide a way to detect bugs earlier. > - running Python in gdb This is somewhat orthogonal, but the devguide/gdb page doesn't say how to start running Python in gdb (it might be obvious to people used to use gdb, but it should still be mentioned). > If error not obvious from quick read, in a 20 line function, > add print around line 10. I usually print variables in order of suspiciousness, i.e., I usually have an idea about where the problem might be, if it's not there I move to the next suspect. This also applies when I know which variable is "wrong" but I don't know where it got wrong: I just add the prints around the most suspicious function that might have changed. -- ___ Python tracker <http://bugs.python.org/issue12913> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12969] Command 'open(0, "wb").close()' cause crash of Python interpreter [interactive mode]
Changes by Ezio Melotti : -- components: +IO nosy: +benjamin.peterson, ezio.melotti, pitrou, stutzbach stage: -> test needed versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue12969> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12969] Command 'open(0, "wb").close()' cause crash of Python interpreter [interactive mode]
Ezio Melotti added the comment: fd support is intentional, see Modules/_io/_iomodule.c:318 OTOH closing sys.stdin doesn't exit Python, so I'm not sure why closing fd 0 should. I was also thinking about possible security implications of this, but if someone tries to pass '0' as filename, it will most likely be passed to open as a string. -- ___ Python tracker <http://bugs.python.org/issue12969> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12975] Invitation to connect on LinkedIn
Changes by Ezio Melotti : -- Removed message: http://bugs.python.org/msg144010 ___ Python tracker <http://bugs.python.org/issue12975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12975] spam
Changes by Ezio Melotti : -- stage: -> committed/rejected title: Invitation to connect on LinkedIn -> spam ___ Python tracker <http://bugs.python.org/issue12975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12983] byte string literals with invalid hex escape codes raise ValueError instead of SyntaxError
Changes by Ezio Melotti : -- nosy: +ezio.melotti stage: -> test needed ___ Python tracker <http://bugs.python.org/issue12983> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1170] shlex have problems with parsing unicode
Ezio Melotti added the comment: That can be done programmatically using the unicodedata module. The regex module (that will hopefully be include in 3.3) is also able to match characters that belongs to specific categories. -- ___ Python tracker <http://bugs.python.org/issue1170> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12992] Python build finished, but the necessary bits to build these modules were not found: _tkinter
Ezio Melotti added the comment: The bug tracker is not the right place for this kind of questions (the fact that some modules are not built is not a bug). You might want to try installing the tk-dev package and see if that solves the problem though. -- nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12992> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12961] unlabelled balls in boxes
Changes by Ezio Melotti : Removed file: http://bugs.python.org/file23132/unnamed ___ Python tracker <http://bugs.python.org/issue12961> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12961] unlabelled balls in boxes
Changes by Ezio Melotti : Removed file: http://bugs.python.org/file23134/unnamed ___ Python tracker <http://bugs.python.org/issue12961> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12931] xmlrpclib confuses unicode and string
Changes by Ezio Melotti : -- nosy: +ezio.melotti versions: -Python 2.6 ___ Python tracker <http://bugs.python.org/issue12931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1170] shlex have problems with parsing unicode
Ezio Melotti added the comment: I haven't looked at the shlex code (yet), my comment was just about the idea of adding constants with chars that belong to different Unicode categories. -- ___ Python tracker <http://bugs.python.org/issue1170> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12737] str.title() is overzealous by upcasing combining marks inappropriately
Ezio Melotti added the comment: I think string methods (and other parts of the stdlib) assume NFC and leave normalization to NFC up to the user. Before fixing str.title() we should take a more general decision about handling strings that use other normalization forms. -- ___ Python tracker <http://bugs.python.org/issue12737> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4153] Unicode HOWTO up to date?
Changes by Ezio Melotti : -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue4153> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12508] Codecs Anomaly
Changes by Ezio Melotti : -- nosy: +lemburg ___ Python tracker <http://bugs.python.org/issue12508> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13004] pprint: add option to truncate seqeunces
Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue13004> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13005] operator module docs include repeat
Changes by Ezio Melotti : -- nosy: +ezio.melotti, sandro.tosi stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue13005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug
Ezio Melotti added the comment: We could also look at what other languages do and/or ask to the Unicode consortium [0]. [0]: http://www.unicode.org/consortium/distlist.html -- ___ Python tracker <http://bugs.python.org/issue12729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13010] devguide doc: ./python.exe on OS X
Ezio Melotti added the comment: I believe it's ./python.exe on OS X. I'm not sure about Windows, maybe it's just python.exe there. -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue13010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13012] Allow keyword argument in str.splitlines()
Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue13012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13021] Resource is not released before returning from the functiion
Changes by Ezio Melotti : -- nosy: +haypo stage: -> patch review ___ Python tracker <http://bugs.python.org/issue13021> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13021] Resource is not released before returning from the functiion
Changes by Ezio Melotti : -- stage: patch review -> test needed ___ Python tracker <http://bugs.python.org/issue13021> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13020] Resource is not released before returning from the functiion
Ezio Melotti added the comment: Hi, thanks for the report(s) and the patch(es)! I think it would be better to have a test that shows the refleak for each of the patches that you submitted. Just out of curiosity, how did you find these? -- nosy: +ezio.melotti stage: -> test needed ___ Python tracker <http://bugs.python.org/issue13020> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13008] syntax error when pasting valid snippet into console without empty string after the function def
Changes by Ezio Melotti : -- nosy: +ezio.melotti versions: -Python 2.7 ___ Python tracker <http://bugs.python.org/issue13008> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13012] Allow keyword argument in str.splitlines()
Ezio Melotti added the comment: LGTM -- ___ Python tracker <http://bugs.python.org/issue13012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12508] Codecs Anomaly
Ezio Melotti added the comment: AFAIU final means: * final=0: I'm passing in a few bytes, but there are more to come, so if the last byte(s) doesn't make sense on its own (e.g. it's a start byte but the continuation bytes are missing), wait for the others before raising an error; * final=1: these are the last bytes, so if the last byte(s) doesn't make sense raise an error (or ignore/replace) because there won't be other bytes that might turn that in a well-formed byte sequence. -- ___ Python tracker <http://bugs.python.org/issue12508> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13010] devguide doc: ./python.exe on OS X
Ezio Melotti added the comment: Fixed, thanks for the report and the suggestion! -- components: +Devguide -Documentation resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13010] devguide doc: ./python.exe on OS X
Changes by Ezio Melotti : -- assignee: docs@python -> ezio.melotti ___ Python tracker <http://bugs.python.org/issue13010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13027] python 2.6.6 interpreter core dumps on modules command from help prompt
Ezio Melotti added the comment:
help("modules") imports all the modules, and you probably have some module that
once imported makes the interpreter crash (maybe _keybinder? you could try
importing that from the interpreter and see if it crashes).
The deprecation warnings comes from deprecated modules that get imported too,
maybe these could be silenced by help().
I'm not sure there's much we can do with this though, see also #12902.
--
nosy: +ezio.melotti, terry.reedy
___
Python tracker
<http://bugs.python.org/issue13027>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13027] python 2.6.6 interpreter core dumps on modules command from help prompt
Ezio Melotti added the comment:
Doing "help('modules')" and "help(), help> modules" should be the same.
My point is that the crash is not Python's fault, but it's caused by some
extension module that gets imported by help('modules'). This module is
probably not installed on the other machines and on the same machine for other
Python versions, so it doesn't crash there. You can look on sys.path to see
the places where Python searches for the modules.
If you manage to identify the module, you could report the problem to their bug
tracker. AFAIK Python can't do anything to prevent/contain a crash while
importing an extension module.
--
___
Python tracker
<http://bugs.python.org/issue13027>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12902] help("modules") executes module code
Ezio Melotti added the comment:
Since help("modules") just shows a list of modules without any description,
maybe it could avoid importing them until further information about individual
modules are requested.
Also while trying to do help("modules") twice on py3k, I noticed that the
second time many modules are missing from the list. Is this expected and/or a
known issue?
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue12902>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12902] help("modules") executes module code
Ezio Melotti added the comment: Right, I missed that. If we change the way the list is created this bug will be probably get fixed too. If we don't, we should open another issue. -- ___ Python tracker <http://bugs.python.org/issue12902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
Ezio Melotti added the comment:
Can the workaround be removed from Lib/pydoc.py:2001 ?
I tried to remove it from 3.2 and help('modules spam') seems to work fine.
--
nosy: +ezio.melotti
___
Python tracker
<http://bugs.python.org/issue9319>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12902] help("modules") executes module code
Ezio Melotti added the comment:
> A separate issue would be a feature request to not do that (assuming it
> really does).
I tried to verify this (the fact that modules get imported with
help('modules')). Here are the results:
* Lib/foobar.py:
- help('modules'): foobar in the list, code is *not* executed;
- help('foobar'): code is executed;
* Lib/deleteme/__init__.py:
- help('modules'): deleteme in the list, code is executed;
- help('deleteme'): code is executed;
* Lib/deleteme/__init__.py and Lib/deleteme/foobar.py:
- help('modules'): deleteme in the list, only __init__ code is executed;
- help('deleteme.foobar'): foobar code is executed;
So it seems the only code that gets executed with help('modules') is the one in
packages' __init__s. It also seems that the code is executed only once, so
doing help('deleteme') after help('modules') doesn't execute the code again.
--
___
Python tracker
<http://bugs.python.org/issue12902>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12931] xmlrpclib confuses unicode and string
Changes by Ezio Melotti : -- stage: -> committed/rejected ___ Python tracker <http://bugs.python.org/issue12931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13034] Python does not read Alternative Subject Names from SSL certificates larger than 1024 bits
Changes by Ezio Melotti : -- components: +Extension Modules nosy: +giampaolo.rodola, janssen, pitrou ___ Python tracker <http://bugs.python.org/issue13034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13036] time format in logging is wrong
Changes by Ezio Melotti : -- nosy: +belopolsky, vinay.sajip ___ Python tracker <http://bugs.python.org/issue13036> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13033] Support recursivity in shutil.chown
Ezio Melotti added the comment: http://mail.python.org/pipermail/python-dev/2011-May/111661.html -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue13033> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13025] mimetypes should read the rule file using UTF-8, not the locale encoding
Changes by Ezio Melotti : -- stage: -> test needed type: -> behavior ___ Python tracker <http://bugs.python.org/issue13025> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13012] Allow keyword argument in str.splitlines()
Ezio Melotti added the comment: The attached patch adds 'keepends=' to a few calls and replaces 0/1 with False/True. The patch can be applied after Mark's patch. Doing two separate commits is probably better. -- Added file: http://bugs.python.org/file23233/issue13012-repl.diff ___ Python tracker <http://bugs.python.org/issue13012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13012] Allow keyword argument in str.splitlines()
Ezio Melotti added the comment: > Out of curiosity, what is typically the convention on that? In theory every issue should be about a single problem and therefore have a single patch to fix it. Sometimes a secondary "problem" that is not strictly related to the first one arises, for example when a cleanup is necessary before applying the patch, or when a new feature is added and a few places get changed to use it. In these cases is not worth opening another issue, so both the patches are attached to the same issue, but committed separately because they address two different "problems". > Sometime people forget to add a News or Acks entry and have to > followup with an addendum. (Mark's patch still lack that, for > instance.) Avoiding to include the NEWS entry in patches is common, because the file gets updated often and it will most likely cause conflicts. `make patchcheck` remind us to add it -- assuming you don't forget to use it. > Ezio's patch looks fine to me, though as Meador points out in the > Rietveld review, there are a couple of omissions that could be fixed. Adding keepends there would have made the line too long, required some splitting and probably made the code less readable overall, so I prefer to keep it out. > Personally, I'm not so convinced of the value of upgrading all the > existing uses of splitlines to use 'keepends'; I just wanted to be > able to do this in *new* code. :-) If we can make old code more readable too and we already have a patch to do it, why not? (one instance also had the comment # True == keep line ends) -- ___ Python tracker <http://bugs.python.org/issue13012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
Changes by Ezio Melotti : -- nosy: +bethard ___ Python tracker <http://bugs.python.org/issue13041> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13042] argparse: terminal width is not detected properly
Changes by Ezio Melotti : -- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> argparse: terminal width is not detected properly ___ Python tracker <http://bugs.python.org/issue13042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13046] imp.find_module() should not find unimportable modules
Ezio Melotti added the comment: I'm not sure they should be disallowed. We have ways to set variables and attributes with "invalid" names (like '.something') too. OTOH __import__ fails to import the .something due to the special meaning of the dot, but it imports things like foo-bar.py just fine. Also I'm assuming that with "unimportable" you just mean "with a name that is not a valid identifier" and not other modules that can't be imported for other reasons. -- nosy: +brett.cannon, ezio.melotti, ncoghlan type: -> behavior ___ Python tracker <http://bugs.python.org/issue13046> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13047] imp.find_module("") and imp.find_module(".")
Changes by Ezio Melotti : -- nosy: +brett.cannon, ezio.melotti, ncoghlan ___ Python tracker <http://bugs.python.org/issue13047> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13013] _ctypes.c: refleak
Ezio Melotti added the comment: If the function is public I guess that some external module might use it, and possibly pass a wrong argument that triggers the leak. -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue13013> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13012] Allow keyword argument in str.splitlines()
Ezio Melotti added the comment: I applied my patch, including the changes in Lib/collections/__init__.py, the issue can now be closed. -- assignee: -> mark.dickinson resolution: -> fixed stage: patch review -> committed/rejected ___ Python tracker <http://bugs.python.org/issue13012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13012] Allow keyword argument in str.splitlines()
Changes by Ezio Melotti : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue13012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13054] sys.maxunicode value after PEP-393
New submission from Ezio Melotti : Now that PEP 393 is in and the distinction between narrow and wide doesn't exist anymore, the value of sys.maxunicode should always be 0x10. sys.maxunicode currently uses PyUnicode_GetMax (Objects/unicodeobject.c:196) and still returns either 0x10 if Py_UNICODE_WIDE is defined or 0x if it's not (and that should now mean that it's defined on Linux where wchar_t is 4 bytes, but not on Windows where it's 2 bytes (isn't this backward incompatible? if so it probably deserves another issue)). IIUC the difference between narrow and wide is gone for Python users, but it's still there for C users that use the old API, so changing PyUnicode_GetMax will most likely break their code. I therefore suggest to set sys.maxunicode to 0x10 and to leave PyUnicode_GetMax as is. C users that switch to the new API should stop using PyUnicode_GetMax and it should be added along with the other deprecated functions in PEP 393. If sys.maxunicode becomes a constant, it won't be useful to determine if the build is narrow or wide anymore (that won't actually matter anymore, but this was the main use of sys.maxunicode), but it might still be useful to know the value of the highest codepoint. Therefore I think that sys.maxunicode can still stay around without being deprecated (its documentation should be fixed though). -- assignee: ezio.melotti components: Interpreter Core, Unicode messages: 144568 nosy: ezio.melotti, haypo, lemburg, loewis priority: high severity: normal stage: test needed status: open title: sys.maxunicode value after PEP-393 type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13054] sys.maxunicode value after PEP-393
Ezio Melotti added the comment: Attached initial patch that sets the value of sys.maxunicode to 0x10, adds a test, and document the change in both the sys.rst doc and in the 3.3 whatsnew. The patch doesn't include any deprecation. If we decide to deprecate something the PEP and possibly the code should be updated. -- keywords: +patch Added file: http://bugs.python.org/file23251/issue13054.diff ___ Python tracker <http://bugs.python.org/issue13054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13039] IDLE editor: shell-like behaviour on line starting with ">>>"
Ezio Melotti added the comment: Do you want to work on a patch? -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue13039> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13054] sys.maxunicode value after PEP-393
Ezio Melotti added the comment: Attached a second patch that fixes checks like: if sys.maxunicode == 65535: ... There are a couple of places (e.g. test_bigmem) where I'm not sure what the best fix is, so I added a couple of XXX in the patch. If you have any suggestion please comment either here on in the review page. -- Added file: http://bugs.python.org/file23254/issue13054-2.diff ___ Python tracker <http://bugs.python.org/issue13054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13054] sys.maxunicode value after PEP-393
Ezio Melotti added the comment: I added PyUnicode_GetMax to the list of deprecated functions in PEP 393 in http://hg.python.org/peps/rev/9a154edf18e6. (I'm also adding Antoine to the nosy because he might know something about test_bigmem.) -- nosy: +pitrou stage: test needed -> patch review ___ Python tracker <http://bugs.python.org/issue13054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13055] Distutils tries to handle null versions but fails
Changes by Ezio Melotti : -- stage: -> test needed type: crash -> behavior ___ Python tracker <http://bugs.python.org/issue13055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12933] Update or remove claims that distutils requires external programs
Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue12933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13053] Add Capsule migration documentation to "cporting"
Ezio Melotti added the comment: I think it's fine to include it in 2.7. -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue13053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13052] IDLE: replace ending with '\' causes crash
Ezio Melotti added the comment:
The problem is in Lib/idlelib/ReplaceDialog.py:141:
m = prog.match(chars, col)
if not prog:
return False
new = m.expand(self.replvar.get())
where
prog = re.compile('foo') # i.e. text in the find box
chars = '>>> "foo"\n' # i.e. the text in the IDLE window
col = 5
self.replvar.get() = 'bar\' # i.e. the var with the trailing \
m.expand() searches for groups to expand, like \1 and \2 to refer to the first
and second matching group, and fails with:
Traceback (most recent call last):
File "/home/wolf/dev/py/py3k/Lib/sre_parse.py", line 194, in __next
c = self.string[self.index + 1]
IndexError: string index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "/home/wolf/dev/py/py3k/Lib/re.py", line 278, in _expand
template = sre_parse.parse_template(template, pattern)
File "/home/wolf/dev/py/py3k/Lib/sre_parse.py", line 729, in parse_template
this = sget()
File "/home/wolf/dev/py/py3k/Lib/sre_parse.py", line 210, in get
self.__next()
File "/home/wolf/dev/py/py3k/Lib/sre_parse.py", line 196, in __next
raise error("bogus escape (end of line)")
sre_constants.error: bogus escape (end of line)
Using things like foo\5bar also results in a crash because the group \5 is not
found.
I'm not sure what the expected behavior should be. If numeric/named
backreferences are not supposed to be supported, I guess a re.escape() might
solve the problem. If they are supported the last line should be wrapped in a
try/except that looks for sre_constants.error errors and possibly IndexErrors
too (this might actually be fixed in sre_parse.py).
BTW, I think that "if not prog" in the snippet I pasted should be "if not m".
Pattern objects are always True (I assume prog is always a pattern object).
Do you want to work on a patch?
--
nosy: +ezio.melotti
___
Python tracker
<http://bugs.python.org/issue13052>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13056] test_multibytecodec.py:TestStreamWriter is skipped after PEP393
New submission from Ezio Melotti :
The test at Lib/test/test_multibytecodec.py:178 checks for len('\U00012345') ==
2, and with PEP393 this is always False.
I tried to run the tests with a few changes and they seem to work, but the code
doesn't raise any exception on c.reset():
>8>8>8>8
import io, codecs
s = io.BytesIO()
c = codecs.getwriter('gb18030')(s)
c.write('123'); s.getvalue()
c.write('\U00012345'); s.getvalue()
c.write('\U00012345' + '\uac00\u00ac'); s.getvalue()
c.write('\uac00'); s.getvalue()
c.reset()
s.getvalue()
>8>8>8>8
Result:
>>> import io, codecs
>>> s = io.BytesIO()
>>> c = codecs.getwriter('gb18030')(s)
>>> c.write('123'); s.getvalue()
b'123'
>>> c.write('\U00012345'); s.getvalue()
b'123\x907\x959'
>>> # '\U00012345'[0] is the same of '\U00012345' now
>>> c.write('\U00012345' + '\uac00\u00ac'); s.getvalue()
b'123\x907\x959\x907\x959\x827\xcf5\x810\x851'
>>> c.write('\uac00'); s.getvalue()
b'123\x907\x959\x907\x959\x827\xcf5\x810\x851\x827\xcf5'
>>> c.reset() # is this supposed to raise an error?
>>> s.getvalue()
b'123\x907\x959\x907\x959\x827\xcf5\x810\x851\x827\xcf5'
Victor suggested to wait until multibytecodec gets ported to the new API before
fixing this.
--
components: Tests
messages: 144583
nosy: ezio.melotti, haypo, loewis
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multibytecodec.py:TestStreamWriter is skipped after PEP393
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue13056>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Changes by Ezio Melotti : -- stage: -> test needed ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10521] str methods don't accept non-BMP fillchar on a narrow Unicode build
Ezio Melotti added the comment: It can still be fixed on 2.7/3.2 though. -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue10521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Ezio Melotti added the comment: Py_UNICODE_NEXT has been removed from 3.3 but it's still available and used in 2.7/3.2 (even if it's private). In order to fix #10521 on 2.7/3.2 the _Py_UNICODE_PUT_NEXT macro attached to this patch is required. -- versions: +Python 3.3 -Python 3.2 ___ Python tracker <http://bugs.python.org/issue10542> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12819] PEP 393 - Flexible Unicode String Representation
Changes by Ezio Melotti : -- stage: patch review -> committed/rejected ___ Python tracker <http://bugs.python.org/issue12819> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13064] Port codecs and error handlers to the new Unicode API
Changes by Ezio Melotti : -- nosy: +ezio.melotti stage: -> needs patch type: -> feature request ___ Python tracker <http://bugs.python.org/issue13064> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11489] json.dumps not parsable by json.loads (on Linux only)
Ezio Melotti added the comment:
RFC 4627 doesn't say much about lone surrogates:
A string is a sequence of zero or more Unicode characters [UNICODE].
[...]
All Unicode characters may be placed within the
quotation marks except for the characters that must be escaped:
quotation mark, reverse solidus, and the control characters (U+
through U+001F).
Any character may be escaped. If the character is in the Basic
Multilingual Plane (U+ through U+), then it may be
represented as a six-character sequence: a reverse solidus, followed
by the lowercase letter u, followed by four hexadecimal digits that
encode the character's code point. The hexadecimal letters A though
F can be upper or lowercase. So, for example, a string containing
only a single reverse solidus character may be represented as
"\u005C".
[...]
To escape an extended character that is not in the Basic Multilingual
Plane, the character is represented as a twelve-character sequence,
encoding the UTF-16 surrogate pair. So, for example, a string
containing only the G clef character (U+1D11E) may be represented as
"\uD834\uDD1E".
Raymond> JSON is UTF-8 by definition and it is a useful feature that invalid
UTF-8 won't load.
Even if the input strings are not encodable in UTF-8 because they contain lone
surrogates, they can still be converted to an \u escape, and the resulting
JSON document will be valid UTF-8.
AFAIK json always uses \u, so it doesn't produce invalid UTF-8 documents.
While decoding, both json.loads('"\xed\xa0\x80"') and json.loads('"\ud800"')
result in u'\ud800', but the first is not a valid UTF-8 document because it
contains an invalid UTF-8 byte sequence that represent a lone surrogate,
whereas the second one contains only ASCII bytes and it's therefore valid.
Python 2.7 should probably reject '"\xed\xa0\x80"', but since its UTF-8 codec
is somewhat permissive already, I'm not sure it makes much sense changing the
behavior now. Python 3 doesn't have this problem because it works only with
unicode strings, so you can't pass invalid UTF-8 byte sequences.
OTOH the Unicode standard says that lone surrogates shouldn't be passed around,
so we might decide to replace them with the replacement char U+FFFD, raise an
error, or even provide a way to decide what should be done with them (something
like the errors argument of codecs).
--
___
Python tracker
<http://bugs.python.org/issue11489>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13065] test
Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker <http://bugs.python.org/issue13065> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13066] test
Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker <http://bugs.python.org/issue13066> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13069] test
New submission from Ezio Melotti : Testing issue creation -- hgrepos: 83 messages: 144655 nosy: ezio.melotti priority: normal severity: normal status: open title: test ___ Python tracker <http://bugs.python.org/issue13069> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13069] test
Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13069> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13068] test
Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker <http://bugs.python.org/issue13068> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13067] test
Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker <http://bugs.python.org/issue13067> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue3232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13071] IDLE refuses to open on windows 7
Ezio Melotti added the comment: Try to open cmd (win+r -> type 'cmd' -> press enter), cd in the Python directory and do "python.exe Lib\idlelib\idle.py". If that doesn't work it should give you a traceback. Once you get the traceback copy/paste it here, so we can figure out what's going on. -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue13071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12737] str.title() is overzealous by upcasing combining marks inappropriately
Ezio Melotti added the comment: After PEP 393 the result is still the same (I attached a slightly improved version of the script): titlecase of 'deme un cafe' should be 'Deme Un Cafe' not 'DeMe Un Cafe' titlecase of 'istanbul' should be 'Istanbul' not 'IStanbul' titlecase of 'α στο διαολο' should be 'Α Στο Διαολο' not 'ΑΙ Στο ΔιαΟλο' failed 3 out of 6 tests Martin, do you think that str.title() should follow the Unicode standard? Should string methods work with all the normalizations or just with NFC? -- Added file: http://bugs.python.org/file23271/titletest.py ___ Python tracker <http://bugs.python.org/issue12737> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64
Ezio Melotti added the comment: "patch -p1 < issue-13057.diff" in the directory where configure is should do the trick. -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue13057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12731] python lib re uses obsolete sense of \w in full violation of UTS#18 RL1.2a
Ezio Melotti added the comment: The failing re tests after PEP 393 are: FAIL lib re found non alphanumeric string 'cafe' FAIL lib re found non alphanumeric string 'Ⓚ' FAIL lib re found non alphanumeric string '' FAIL lib re found non alphanumeric string '' FAIL lib re found non alphanumeric string 'connector‿punctuation' FAIL lib re found non alphanumeric string 'Ὰ_Στο_Διάολο' FAIL lib re found non alphanumeric string '𐌰𐍄𐍄𐌰‿𐌿𐌽𐍃𐌰𐍂‿𐌸𐌿‿𐌹𐌽‿𐌷𐌹𐌼𐌹𐌽𐌰𐌼' FAIL lib re found all alphanumeric string '¹²³' FAIL lib re found all alphanumeric string '₁₂₃' FAIL lib re found all alphanumeric string '¼½¾' FAIL lib re found all alphanumeric string '⑶' -- ___ Python tracker <http://bugs.python.org/issue12731> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64
Ezio Melotti added the comment: If that's a Mercurial clone of Python you can try "hg import --no-commit issue-13057.diff". Otherwise you could just edit configure manually -- the attached patch is trivial. You could also install "patch". -- ___ Python tracker <http://bugs.python.org/issue13057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64
Ezio Melotti added the comment: You just have to add: #include just after: #include The + in the diff only means that the line was added and shouldn't be included in the file. -- ___ Python tracker <http://bugs.python.org/issue13057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64
Ezio Melotti added the comment: After the one at line 8620. -- ___ Python tracker <http://bugs.python.org/issue13057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13074] Improve documentation of locale encoding functions
Changes by Ezio Melotti : -- nosy: +ezio.melotti stage: -> needs patch versions: -Python 2.6, Python 3.1, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Ezio Melotti added the comment:
The attached patch changes Tools/unicode/makeunicodedata.py to create a list of
names and codepoints taken from
http://www.unicode.org/Public/6.0.0/ucd/NameAliases.txt and adds it to
Modules/unicodename_db.h.
During the lookup the _getcode function at Modules/unicodedata.c:1055 loops
over the 11 aliases and checks if any of those match.
The patch also includes tests for both unicodedata.lookup and \N{}.
I'm not sure this is the best way to implement this, and someone will probably
want to review and tweak both the approach and the C code, but it works fine:
>>> "\N{LATIN CAPITAL LETTER GHA}"
'Ƣ'
>>> import unicodedata
>>> unicodedata.lookup("LATIN CAPITAL LETTER GHA")
'Ƣ'
>>> "\N{LATIN CAPITAL LETTER OI}"
'Ƣ'
>>> unicodedata.lookup("LATIN CAPITAL LETTER OI")
'Ƣ'
The patch doesn't include changes for NamedSequences.txt.
--
keywords: +patch
nosy: +lemburg, loewis
Added file: http://bugs.python.org/file23273/issue12753.diff
___
Python tracker
<http://bugs.python.org/issue12753>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Changes by Ezio Melotti : -- assignee: -> ezio.melotti stage: needs patch -> patch review ___ Python tracker <http://bugs.python.org/issue12753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13075] PEP-0001 contains dead links
Changes by Ezio Melotti : -- nosy: +ezio.melotti stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue13075> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13079] Wrong datetime format in PEP3101
Changes by Ezio Melotti : -- nosy: +eric.smith, ezio.melotti ___ Python tracker <http://bugs.python.org/issue13079> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Ezio Melotti added the comment:
Leaving named sequences for unicodedata.lookup() only (and not for \N{}) makes
sense.
The list of aliases is so small (11 entries) that I'm not sure using a binary
search for it would bring any advantage. Having a single lookup algorithm that
looks in both tables doesn't work because the aliases lookup must be in
_getcode for \N{...} to work, whereas the lookup of named sequences will happen
in unicodedata_lookup (Modules/unicodedata.c:1187).
I think we can leave the for loop over aliases in _getcode and implement a
separate (and binary) search in unicodedata_lookup for the named sequences.
Does that sound fine?
--
___
Python tracker
<http://bugs.python.org/issue12753>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Ezio Melotti added the comment:
Attached a new patch that adds support for named sequences (still needs some
test and can probably be improved).
> There are certainly advantages to that strategy: you don't have to
> deal with [\N{sequence}] issues.
I assume with [] you mean a regex character class, right?
> If the argument to unicode.lookup() and be any of name, alias, or
> sequence, that seems ok.
With my latest patch, all 3 are supported.
> \N{} should still do aliases, though, since those don't have the
> complication that sequences have.
\N{} will only support names and aliases (maybe this can go in 2.7/3.2 too).
> You may wish unicode.name() to return the alias in preference,
> however. That's what we do. And of course, there is no issue of
> sequences there.
This can be done for 3.3, but I wonder if it might create problems. People
might use unicodedata.name() to get a name and use it elsewhere, and the other
side might not be aware of aliases.
--
Added file: http://bugs.python.org/file23280/issue12753-2.diff
___
Python tracker
<http://bugs.python.org/issue12753>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13086] Update howto/cporting.rst so it talks about 3.x instead of 3.0
Changes by Ezio Melotti : -- nosy: +ezio.melotti stage: -> needs patch versions: -Python 3.1, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13086> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements
Ezio Melotti added the comment:
The patch seems wrong to me:
>>> d = minidom.parseString('AAABBBCCC')
>>> print(d.toprettyxml())
AAA
BBB CCC
Even if the newlines are gone, the indentation before the closing tag is
preserved. Also a newline is added before the text node BBB.
It would be good to check what the XML standard says about the whitespace. I'm
pretty sure HTML has well defined rules about it, but I don't know if that's
the same for XML.
FWIW the link in msg102247 contains a different fix (not sure if it's any
better), and also a link to an article about XML and whitespace:
http://www.oracle.com/technetwork/articles/wang-whitespace-092897.html (the
link seems broken in the page).
--
nosy: +ezio.melotti -BreamoreBoy
stage: committed/rejected -> test needed
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue4147>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Ezio Melotti added the comment:
> The problem with official names is that they have things in them that
> you are not expected in names. Do you really and truly mean to tell
> me you think it is somehow **good** that people are forced to write
>\N{LINE FEED (LF)}
> Rather than the more obvious pair of
>\N{LINE FEED}
>\N{LF}
> ??
Actually Python doesn't seem to support \N{LINE FEED (LF)}, most likely because
that's a Unicode 1 name, and nowadays these codepoints are simply marked as
''.
> If so, then I don't understand that. Nobody in their right
> mind prefers "\N{LINE FEED (LF)}" over "\N{LINE FEED}" -- do they?
They probably don't, but they just write \n anyway. I don't think we need to
support any of these aliases, especially if they are not defined in the Unicode
standard.
I'm also not sure humans use \N{...}: you don't want to write
'R\N{LATIN SMALL LETTER E WITH ACUTE}sum\N{LATIN SMALL LETTER E WITH ACUTE}'
and you would need to look up the exact name somewhere anyway before using it
(unless you know them by heart).
If 'R\xe9sum\xe9' or 'R\u00e9sum\u00e9' are too obscure and/or magic, you can
always print() them and get 'Résumé' (or just write 'Résumé' directly in the
source).
> All of the standards documents *talk* about things like LRO and ZWNJ.
> I guess the standards aren't "readable" then, right? :)
Right, I had to read down till the table with the meanings before figuring out
what they were (and I already forgot it).
> The most persuasive use-case for user-defined names is for private-use
> area code points. These will never have an official name. But it is
> just fine to use them. Don't they deserve a better name, one that
> makes sense within your own program that uses them? Of course they do.
>
> For example, Apple has a bunch of private-use glyphs they use all the time.
> In the 8-bit MacRoman encoding, the byte 0xF0 represents the Apple corporate
> logo/glyph thingie of an apple with a bite taken out of it. (Microsoft
> also has a bunch of these.) If you upgrade MacRoman to Unicode, you will
> find that that 0xF0 maps to code point U+F8FF using the regular converter.
>
> Now what are you supposed to do in your program when you want a named
> character
> there? You certainly do not want to make users put an opaque magic number
> as a Unicode escape. That is always really lame, because the whole reason
> we have \N{...} escapes is so we don't have to put mysterious unreadable magic
> numbers in our code!!
>
> So all you do is
>use charnames ":alias" => {
>"APPLE LOGO" => 0xF8FF,
>};
>
> and now you can use \N{APPLE LOGO} anywhere within that lexical scope. The
> compiler will dutifully resolve it to U+F8FF, since all name lookups happen
> at compile-time. And it cannot leak out of the scope.
This is actually a good use case for \N{..}.
One way to solve that problem is doing:
apples = {
'APPLE': '\uF8FF',
'GREEN APPLE': '\U0001F34F',
'RED APPLE': '\U0001F34E',
}
and then:
print('I like {GREEN APPLE} and {RED APPLE}, but not
{APPLE}.'.format(**apples))
This requires the format call for each string and it's a workaround, but at
least is readable (I hope you don't have too many apples in your strings).
I guess we could add some way to define a global list of names, and that would
probably be enough for most applications. Making it per-module would be more
complicated and maybe not too elegant.
> People who write patterns without whitespace for cognitive chunking (plus
> comments for explanation) are wicked wicked wicked. Frankly I'm surprised
> Python doesn't require it. :)/2
I actually find those *less* readable. If there's something fancy in the
regex, a comment *before* it is welcomed, but having to read a regex divided on
several lines and remove meaningless whitespace and redundant comments just
makes the parsing more difficult for me.
--
___
Python tracker
<http://bugs.python.org/issue12753>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Ezio Melotti added the comment: Attached a new patch with more tests and doc. -- Added file: http://bugs.python.org/file23291/issue12753-3.diff ___ Python tracker <http://bugs.python.org/issue12753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13076] Bad links to 'time' in datetime documentation
Ezio Melotti added the comment: The broken links seem to be only in the "time objects" section, and only in the body of attribute/method directives. The attached patch fixes the issue by using :class:`~datetime.time` explicitly where the links are broken. Georg, is this a bug in Sphinx? -- assignee: docs@python -> ezio.melotti keywords: +patch nosy: +ezio.melotti, georg.brandl stage: needs patch -> patch review Added file: http://bugs.python.org/file23292/issue13076.diff ___ Python tracker <http://bugs.python.org/issue13076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13076] Bad links to 'time' in datetime documentation
Ezio Melotti added the comment: This should be fixed now, thanks for the report. FTR with Sphinx 1.0 all the links to :class:`time` and also :class:`datetime` needed to be fixed because they were pointing to the modules, with 0.6 only the :class:`time` in the body of attribute/method directives were broken. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Ezio Melotti added the comment: > But it still has to happen at compile time, of course, so I don't know > what you could do in Python. Is there any way to change how the compiler > behaves even vaguely along these lines? I think things like "from __future__ import ..." do something similar, but I'm not sure it will work in this case (also because you will have to provide the list of aliases somehow). >> Really? White space makes things harder to read? I thought Pythonistas >> believed the opposite of that. Whitespace is very useful for cognitive >> chunking: you see how things logically group together. > I was surprised at that too ;-). One person's opinion in a specific > context. Don't generaliza. Also don't generalize my opinion regarding *where* whitespace makes thing less readable: I was just talking about regex. What I was trying to say here is best summarized by a quote from Paul Graham's article "Succinctness is Power": """ If you're used to reading novels and newspaper articles, your first experience of reading a math paper can be dismaying. It could take half an hour to read a single page. And yet, I am pretty sure that the notation is not the problem, even though it may feel like it is. The math paper is hard to read because the ideas are hard. If you expressed the same ideas in prose (as mathematicians had to do before they evolved succinct notations), they wouldn't be any easier to read, because the paper would grow to the size of a book. """ Try replacing s/novels and newspaper articles|prose/Python code/g s/single page/single regex/ s/math paper/regex/g. To provide an example, I find: # define a function to capitalize s def my_capitalize(s): """This function capitalizes the argument s and returns it""" the_first_letter = s[0] # 0 means the first char the_rest_of_s = s[1:] # 1: means from the second till the end the_first_letter_uppercased = the_first_letter.upper() # upper makes the string uppercase the_rest_of_s_lowercased = the_rest_of_s.lower() # lower makes the string lowercase s_capitalized = the_first_letter_uppercased + the_rest_of_s_lowercased # + concatenates return s_capitalized less readable than: def my_capitalize(s): return s[0].upper() + s[1:].lower() You could argue that the first is much more explicit and in a way clearer, but overall I think you agree with me that is less readable. Also this clearly depends on how well you know the notation you are reading: if you don't know it very well, you might still prefer the commented/verbose/extended/redundant version. Another important thing to mention, is that notation of regular expressions is fairly simple (especially if you leave out look-arounds and Unicode-related things that are not used too often), but having a similar succinct notation for a whole programming language (like Perl) might not work as well (I'm not picking on Perl here, as you said you can write readable programs if you don't abuse the notation, and the succinctness offered by the language has some advantages, but with Python we prefer more readable, even if we have to be a little more verbose). Another example of a trade-off between verbosity and succinctness is the new string formatting mini-language. > That really isn't right. A cased character is one with the Unicode "Cased" > property, and a lowercase character is one wiht the Unicode "Lowercase" > property. The General Category is actually immaterial here. You might want to take a look and possibly add a comment on #12204 about this. > I've spent all bloody day trying to model Python's islower, isupper, and > istitle > functions, but I get all kinds of errors, both in the definitions and in the > models of the definitions. If by "model" you mean "trying to figure out how they work", it's probably easier to look at the implementation (I assume you know enough C to understand what they do). You can find the code for str.istitle() at http://hg.python.org/cpython/file/default/Objects/unicodeobject.c#l10358 and the actual implementation of some macros like Py_UNICODE_ISTITLE at http://hg.python.org/cpython/file/default/Objects/unicodectype.c. > I really don't understand any of these functions. I'm very sad. I think > they are > wrong, but maybe I am. It is extremely confusing. > Shall I file a separate bug report? If after reading the code and/or the documentation you still think they are broken and/or that they can be improved, then you can open another issue. BTW, instead of writing custom scripts to test things, it might be better to use unittest (see http://docs.python.org/py3k/library/unittest.html#basic-example), or even bett
[issue13071] IDLE refuses to open on windows 7
Ezio Melotti added the comment: Are you using some "unusual" keyboard layout? -- ___ Python tracker <http://bugs.python.org/issue13071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12804] "make test" fails on systems without internet access
Ezio Melotti added the comment:
FWIW there's also support.open_urlresource that can be used to download test
data. open_urlresouce calls requires('urlfetch') and skips the test when the
resource is not enabled. For instance, test_normalization uses it:
try:
testdata = support.open_urlresource(TESTDATAURL, encoding="utf-8",
check=check_version)
except (IOError, HTTPException):
self.skipTest("Could not retrieve " + TESTDATAURL)
self.addCleanup(testdata.close)
This also saves the file on the disk and reuses it when the test is run again,
so the connection is actually used once and only if available.
--
nosy: +ezio.melotti
___
Python tracker
<http://bugs.python.org/issue12804>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12458] Tracebacks should contain the first line of continuation lines
Ezio Melotti added the comment:
This is an interesting proposal.
The line number comes from Python/traceback.c:120:
tb->tb_lineno = PyFrame_GetLineNumber(frame);
and this function is defined in Objects/frameobject.c:35:
int PyFrame_GetLineNumber(PyFrameObject *f) {
if (f->f_trace)
return f->f_lineno;
else
return PyCode_Addr2Line(f->f_code, f->f_lasti);
}
and documented as "Return the line number that frame is currently executing.",
so that would explain why it's pointing to the last line.
I'm not sure if there's an easy way to get the line where the beginning of the
expression is, but if you find a way to get it, we could try to use it in
PyFrame_GetLineNumber and see how it works.
--
nosy: +ezio.melotti, georg.brandl, ncoghlan
stage: -> test needed
versions: +Python 3.3 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue12458>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6632] Include more fullwidth chars in the decimal codec
Changes by Ezio Melotti : -- nosy: +tchrist ___ Python tracker <http://bugs.python.org/issue6632> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13094] Need Programming FAQ entry for the behavior of closures
Ezio Melotti added the comment: To understand better what's going on, try to change the value of 'each' after the 3 prints and then call again the 3 methods: you will see that they now return the new value of each. This is because the lambdas refer to global 'each' (that at the end of the loop is set to 'baz'). If you do setattr(x, each, lambda each=each: each), the each will be local to the lambda, and it will then work as expected. An entry in the FAQ would be useful, I thought it was there already but apparently it's not (I'm pretty sure I saw this already somewhere in the doc, but I can't seem to find where). -- assignee: docs@python -> components: +None -Documentation nosy: +ezio.melotti stage: needs patch -> type: behavior -> versions: -Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13094> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13094] Need Programming FAQ entry for the behavior of closures
Ezio Melotti added the comment: Maybe with a different name is less confusing: lambda return_value=each: return_value This copies the value of 'each' in a variable called 'return_value' that is local to the lambda. Since the copy happens when the lambdas are defined, 'return_value' has then the right value. -- ___ Python tracker <http://bugs.python.org/issue13094> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Ezio Melotti added the comment: The patch is pretty much complete, it just needs a review (I left some comments on the review page). One thing that can be added is some compression for the names of the named sequences. I'm not sure I can reuse the same compression used for the other names easily. Does the size of the db really matters? Are the new names using too much extra space? -- keywords: +needs review ___ Python tracker <http://bugs.python.org/issue12753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13095] Support for splitting lists/tuples into chunks
Ezio Melotti added the comment: This sounds like the grouper() recipe of itertools. You could try to convince Raymond and see if he wants to include it in itertools. -- nosy: +ezio.melotti, rhettinger versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue13095> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
