[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Ezio Melotti ezio.melo...@gmail.com 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
'control'.
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 rep...@bugs.python.org
http://bugs.python.org/issue12753
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13073] message_body argument of HTTPConnection.endheaders is undocumented
Ben Hayden hayden...@gmail.com added the comment: I added in docs for the method from the actual method docstring from the http.client module. -- keywords: +patch nosy: +beardedp Added file: http://bugs.python.org/file23290/issue13073.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13073 ___ ___ 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 ezio.melo...@gmail.com added the comment: Attached a new patch with more tests and doc. -- Added file: http://bugs.python.org/file23291/issue12753-3.diff ___ Python tracker rep...@bugs.python.org 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 ezio.melo...@gmail.com 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 rep...@bugs.python.org 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
Georg Brandl ge...@python.org added the comment: No, it's not, it's how Sphinx works. Use :class:`.time` to refer to the datetime class. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13089] parsetok.c: memory leak
New submission from Stefan Krah stefan-use...@bytereef.org: Seen in test_mailbox: ==31621== 6 bytes in 2 blocks are definitely lost in loss record 27 of 10,370 ==31621==at 0x4C2154B: malloc (vg_replace_malloc.c:236) ==31621==by 0x5271A5: parsetok (parsetok.c:179) ==31621==by 0x526E8A: PyParser_ParseStringFlagsFilenameEx (parsetok.c:67) ==31621==by 0x4BC385: PyParser_ASTFromString (pythonrun.c:1898) ==31621==by 0x4BC1E1: Py_CompileStringExFlags (pythonrun.c:1842) ==31621==by 0x478AB8: builtin_compile (bltinmodule.c:626) ==31621==by 0x5759F3: PyCFunction_Call (methodobject.c:84) ==31621==by 0x48F2CF: ext_do_call (ceval.c:4292) ==31621==by 0x489992: PyEval_EvalFrameEx (ceval.c:2646) ==31621==by 0x48E67B: fast_function (ceval.c:4068) ==31621==by 0x48E3C7: call_function (ceval.c:4001) ==31621==by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) -- components: Interpreter Core messages: 144763 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: parsetok.c: memory leak type: resource usage versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13089 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13090] posix_read: memory leak
New submission from Stefan Krah stefan-use...@bytereef.org: Seen in test_multiprocessing: ==31662== 37 bytes in 1 blocks are definitely lost in loss record 629 of 10,548 ==31662==at 0x4C2154B: malloc (vg_replace_malloc.c:236) ==31662==by 0x53BBE9: PyBytes_FromStringAndSize (bytesobject.c:98) ==31662==by 0x4E2363: posix_read (posixmodule.c:6980) ==31662==by 0x5759D8: PyCFunction_Call (methodobject.c:81) ==31662==by 0x48E294: call_function (ceval.c:3980) ==31662==by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) ==31662==by 0x48C54F: PyEval_EvalCodeEx (ceval.c:3355) ==31662==by 0x48E786: fast_function (ceval.c:4078) ==31662==by 0x48E3C7: call_function (ceval.c:4001) ==31662==by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) ==31662==by 0x48C54F: PyEval_EvalCodeEx (ceval.c:3355) ==31662==by 0x48E786: fast_function (ceval.c:4078) -- components: Extension Modules messages: 144764 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: posix_read: memory leak type: resource usage versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13090 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13091] ctypes: memory leak
New submission from Stefan Krah stefan-use...@bytereef.org: Seen in test_multiprocessing: ==31662== 44 bytes in 1 blocks are definitely lost in loss record 687 of 10,548 ==31662==at 0x4C2154B: malloc (vg_replace_malloc.c:236) ==31662==by 0x41CC27: PyMem_Malloc (object.c:1699) ==31662==by 0x127D9F51: resize (callproc.c:1664) ==31662==by 0x5759D8: PyCFunction_Call (methodobject.c:81) ==31662==by 0x48E294: call_function (ceval.c:3980) ==31662==by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) ==31662==by 0x48E67B: fast_function (ceval.c:4068) ==31662==by 0x48E3C7: call_function (ceval.c:4001) ==31662==by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) ==31662==by 0x48C54F: PyEval_EvalCodeEx (ceval.c:3355) ==31662==by 0x48E786: fast_function (ceval.c:4078) ==31662==by 0x48E3C7: call_function (ceval.c:4001) -- components: Extension Modules messages: 144765 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: ctypes: memory leak type: resource usage versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13091 ___ ___ 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
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 854e31d80151 by Ezio Melotti in branch '2.7': #13076: fix links to datetime.time. http://hg.python.org/cpython/rev/854e31d80151 New changeset 95689ed69097 by Ezio Melotti in branch '3.2': #13076: fix links to datetime.time and datetime.datetime. http://hg.python.org/cpython/rev/95689ed69097 New changeset 175cd2a51ea9 by Ezio Melotti in branch 'default': #13076: merge with 3.2. http://hg.python.org/cpython/rev/175cd2a51ea9 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13092] pep-393: memory leaks #2
New submission from Stefan Krah stefan-use...@bytereef.org: I found a couple of additional leaks related to the PEP-393 changes. -- components: Interpreter Core files: pep-393-leaks-2.diff keywords: patch messages: 144767 nosy: loewis, skrah priority: normal severity: normal stage: patch review status: open title: pep-393: memory leaks #2 type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file23293/pep-393-leaks-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13092 ___ ___ 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 ezio.melo...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue13076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13084] test_signal failure
Stefan Krah stefan-use...@bytereef.org added the comment: Patch looks good to me (and it fixes the problem). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13084 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7689] Pickling of classes with a metaclass and copy_reg
Changes by Lance Hepler nlhep...@gmail.com: -- nosy: +nlhepler ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7689 ___ ___ 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
Dan Kenigsberg dan...@redhat.com added the comment: Oh dear. Thanks, Enzio, for pointing out that former patch is wrong. It is also quite naive, since the whole NATURE of toprettyprint() is to add whitespace to Text nodes. Tomas Lee's http://bugs.python.org/file11832/minidom-toprettyxml-01.patch made an effort to touch only simple Text nodes, that are confined within a single elem/elem. I did not expect http://bugs.python.org/file23286/minidom-Text-toprettyxml.patch to get in so quickly, after the former one spent several years on queue. However now is time to fix it, possible by my second patch. -- Added file: http://bugs.python.org/file23294/minidom-Text-toprettyxml-02.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4147 ___ ___ 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
Dan Kenigsberg dan...@redhat.com added the comment: btw, http://www.w3.org/TR/xml/#sec-white-space is a bit vague on how should a parser deal with whitespace, and seems to allow non-preservation of text nodes. Preserving simple text nodes is allowed, too, and is more polite to applications reading the prettyxml. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4147 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12804] make test should not enable the urlfetch resource
Éric Araujo mer...@netwok.org added the comment: I don’t have a flaky connection, I have none at all; until this change I could always run just use “make test” for all Python versions. OTOH, I agree with your point that testing networking facilities in the standard test suite makes sense, as most people probably have network access. If it is easy to detect network availability programmatically, we could just use the skip system. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12804 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3902] Packages containing only extension modules have to contain __init__.py
Éric Araujo mer...@netwok.org added the comment: We’re working on a patch on the core-mentorship list. -- components: +Distutils nosy: +alexis stage: needs patch - patch review versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13089] parsetok.c: memory leak
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13089 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13091] ctypes: memory leak
Changes by Meador Inge mead...@gmail.com: -- components: +ctypes nosy: +amaury.forgeotdarc, belopolsky, meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13091 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13093] Redundant code in PyUnicode_EncodeDecimal()
New submission from Stefan Krah stefan-use...@bytereef.org:
I can't see what this code is supposed to accomplish (see patch):
while (collend end) {
if ((0 *collend *collend 256) ||
!Py_UNICODE_ISSPACE(*collend) ||
Py_UNICODE_TODECIMAL(*collend))
break;
}
Since 'collend' and 'end' don't change in the loop, it would be
infinite if the 'if' condition evaluated to false. But the 'if'
condition is always true.
--
components: Interpreter Core
files: encode_decimal_redundant_code.diff
keywords: needs review, patch
messages: 144774
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Redundant code in PyUnicode_EncodeDecimal()
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23295/encode_decimal_redundant_code.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13093
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13090] posix_read: memory leak
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13090 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13092] pep-393: memory leaks #2
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13084] test_signal failure
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset e4f4272479d0 by Charles-François Natali in branch 'default': Issue #13084: Fix a test_signal failure: the delivery order is only defined for http://hg.python.org/cpython/rev/e4f4272479d0 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13084 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13001] test_socket.testRecvmsgTrunc failure on FreeBSD 7.2 buildbot
Charles-François Natali neolo...@free.fr added the comment:
@requires_freebsd_version should be factorized with
@requires_linux_version.
Patches attached.
Can we workaround FreeBSD ( 8) bug in C/Python?
Not really.
Or should we remove the function on FreeBSD 8?
There's really no reason to do that (and it's really a minor bug).
--
Added file: http://bugs.python.org/file23296/freebsd_msgtrunc-1.diff
Added file: http://bugs.python.org/file23297/requires_unix_version.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13001
___diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
--- a/Lib/test/test_socket.py
+++ b/Lib/test/test_socket.py
@@ -1659,6 +1659,9 @@
def _testRecvmsgShorter(self):
self.sendToServer(MSG)
+# FreeBSD 8 doesn't always set the MSG_TRUNC flag when a truncated
+# datagram is received (issue #13001).
+@support.requires_freebsd_version(8)
def testRecvmsgTrunc(self):
# Receive part of message, check for truncation indicators.
msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
@@ -1668,6 +1671,7 @@
self.assertEqual(ancdata, [])
self.checkFlags(flags, eor=False)
+@support.requires_freebsd_version(8)
def _testRecvmsgTrunc(self):
self.sendToServer(MSG)
diff --git a/Lib/test/support.py b/Lib/test/support.py
--- a/Lib/test/support.py
+++ b/Lib/test/support.py
@@ -44,8 +44,8 @@
Error, TestFailed, ResourceDenied, import_module,
verbose, use_resources, max_memuse, record_original_stdout,
get_original_stdout, unload, unlink, rmtree, forget,
-is_resource_enabled, requires, requires_linux_version,
-requires_mac_ver, find_unused_port, bind_port,
+is_resource_enabled, requires, requires_freebsd_version,
+requires_linux_version, requires_mac_ver, find_unused_port,
bind_port,
IPV6_ENABLED, is_jython, TESTFN, HOST, SAVEDCWD, temp_cwd,
findfile, create_empty_file, sortdict, check_syntax_error,
open_urlresource,
check_warnings, CleanImport, EnvironmentVarGuard,
TransientResource,
@@ -312,17 +312,17 @@
msg = Use of the %r resource not enabled % resource
raise ResourceDenied(msg)
-def requires_linux_version(*min_version):
-Decorator raising SkipTest if the OS is Linux and the kernel version is
-less than min_version.
+def _requires_unix_version(sysname, min_version):
+Decorator raising SkipTest if the OS is `sysname` and the version is
less
+than `min_version`.
-For example, @requires_linux_version(2, 6, 35) raises SkipTest if the Linux
-kernel version is less than 2.6.35.
+For example, @_requires_unix_version('FreeBSD', (7, 2)) raises SkipTest if
+the FreeBSD version is less than 7.2.
def decorator(func):
@functools.wraps(func)
def wrapper(*args, **kw):
-if sys.platform == 'linux':
+if platform.system() == sysname:
version_txt = platform.release().split('-', 1)[0]
try:
version = tuple(map(int, version_txt.split('.')))
@@ -332,13 +332,29 @@
if version min_version:
min_version_txt = '.'.join(map(str, min_version))
raise unittest.SkipTest(
-Linux kernel %s or higher required, not %s
-% (min_version_txt, version_txt))
-return func(*args, **kw)
-wrapper.min_version = min_version
+%s version %s or higher required, not %s
+% (sysname, min_version_txt, version_txt))
return wrapper
return decorator
+def requires_freebsd_version(*min_version):
+Decorator raising SkipTest if the OS is FreeBSD and the FreeBSD version
is
+less than `min_version`.
+
+For example, @requires_freebsd_version(7, 2) raises SkipTest if the FreeBSD
+version is less than 7.2.
+
+return _requires_unix_version('FreeBSD', min_version)
+
+def requires_linux_version(*min_version):
+Decorator raising SkipTest if the OS is Linux and the Linux version is
+less than `min_version`.
+
+For example, @requires_linux_version(2, 6, 32) raises SkipTest if the Linux
+version is less than 2.6.32.
+
+return _requires_unix_version('Linux', min_version)
+
def requires_mac_ver(*min_version):
Decorator raising SkipTest if the OS is Mac OS X and the OS X
version if less than min_version.
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Charles-François Natali neolo...@free.fr added the comment: So, Victor, what do you think of the last version? This patch has been lingering for quite some time, and it's really a cool feature. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10141 ___ ___ 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
R. David Murray rdmur...@bitdance.com added the comment: Heh, you happened to post your patch at a time when I wanted something to do as a break from something I didn't want to do...and I *thought* I understood the problem, after reading the various links. But clearly I didn't. We don't have someone who has stepped forward to be xml maintainer, so I just went ahead and committed it. I should find time to look at your new patch some time today, or perhaps Ezio will have time. (Clearly minidom doesn't have enough tests.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4147 ___ ___ 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
Changes by lesmana lesm...@gmx.de: -- nosy: +lesmana ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12458 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13084] test_signal failure
Changes by Charles-François Natali neolo...@free.fr: -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13084 ___ ___ 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
Tom Christiansen tchr...@perl.com added the comment:
Ezio Melotti rep...@bugs.python.org wrote
on Sun, 02 Oct 2011 06:46:26 -:
Actually Python doesn't seem to support \N{LINE FEED (LF)}, most likely bec=
ause that's a Unicode 1 name, and nowadays these codepoints are simply mark=
ed as 'control'.
Yes, but there are a lot of them, 65 of them in fact. I do not care to
see people being forced to use literal control characters or inscrutable
magic numbers. It really bothers me that you have all these defined code
points with properties and all that have no name. People do use these.
Some of them a lot. I don't mind \n and such -- and in fact, prefer them
even -- but I feel I should not have scratch my head over character \033, \0177,
and brethren. The C0 and C1 standards are not just inventions, so we use
them. Far better than one should write \N{ESCAPE} for \033 or \N{DELETE}
for \0177, don't you think?
If so, then I don't understand that. Nobody in their right=20
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.
If you look at Names.txt, there are significant aliases there for
the C0/C1 stuff. My bottom line is that I don't like to be forced
to use magic numbers. I prefer to name my abstactions. It is more
readable and more maintainble that way.
There are still holes of course. Code point 128 has no name even in C1.
But something is better than nothing. Plus at least in Perl we *can* give
things names if we want, per the APPLE LOGO example for U+F8FF. So nothing
needs to remain nameless. Why, you can even name your Kanji if you want,
using whatever Romanization you prefer. I think the private-use case
example is really motivating, but I have no idea how to do this for Python
because there is no lexical scope. I suppose you could attach it to the
module, but that still doesn't really work because of how things get evaluated.
With a Perl compile-time use, we can change the compiler's ideas about
things, like adding function prototypes and even extending the base types:
% perl -Mbigrat -le 'print 1/2 + 2/3 * 4/5'
31/30
% perl -Mbignum -le 'print 21-is_odd'
1
% perl -Mbignum -le 'print 18-is_odd'
0
% perl -Mbignum -le 'print substr(2**5000, -3)'
376
% perl -Mbignum -le 'print substr(2**5000-1, -3)'
375
% perl -Mbignum -le 'print length(2**5000)'
1506
% perl -Mbignum -le 'print length(10**5000)'
5001
% perl -Mbignum -le 'print ref 10**5000'
Math::BigInt
% perl -Mbigrat -le 'print ref 1/3'
Math::BigRat
I recognize that redefining what sort of object the compiler treats some
of its constants as is never going to happen in Python, but we actually
did manage that with charnames without having to subclass our strings:
the hook for \N{...} doesn't require object games like the ones above.
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?
The run-time looks of Python's unicodedata.lookup (like Perl's
charnames::viacode) and unicodedata.name (like Perl's charnames::viacode
on the ord) could be managed with a hook, but the compile-time lookups
of \N{...} I don't see any way around. But I don't know anything about
Python's internals, so don't even know what is or is not possible.
I do note that if you could extend \N{...} the way we do with charname
aliases for private-use characters, the user could load something that
did the C0 and C1 control if they wanted to. I just don't know how to
do that early enough that the Python compiler would see it. Your import
happens at run-time or at compile-time? This would be some sort of
compile-time binding of constants.
d=20
Python doesn't require it. :)/2
I actually find those *less* readable. If there's something fancy in the r=
egex, 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.
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.
Inomorewantaregexwithoutwhitespacethananyothercodeortext. :)
I do grant you that chatty comments may be a separate matter.
White space in patterns is also good when you have successive patterns
across multiple lines that have parts that are the same and parts that
are different, as in most of these, which is from a function to render
an English headline/book/movie/etc title into its proper casing:
# put into lowercase if on our stop list, else titlecase
s/ ( \pL [\pL']* ) /$stoplist{$1} ?
[issue5001] Remove assertion-based checking in multiprocessing
Vlad Riscutia riscutiav...@gmail.com added the comment: I attached a patch which replaces all asserts with checks that raise exceptions. I used my judgement in determining exception types but I might have been off in some places. Also, this patch replaces ALL asserts. It is possible that some of the internal functions should be kept using asserts but I am not familiar enough with the module to say which. I figured I'd better do the whole thing than reviewers can say where lines should be reverted to asserts. -- keywords: +patch nosy: +vladris Added file: http://bugs.python.org/file23298/issue5001.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5001] Remove assertion-based checking in multiprocessing
Antoine Pitrou pit...@free.fr added the comment: Thank you. I've attached some comments, click on the review link to read them. -- assignee: jnoller - nosy: +pitrou -BreamoreBoy stage: needs patch - patch review versions: +Python 3.3 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1625] bz2.BZ2File doesn't support multiple streams
Nadeem Vawda nadeem.va...@gmail.com added the comment: This is all fine and well, but this is clearly a bug and not a feature. No, it is not at all clear that this is a bug. I agree that this is a desirable capability to have, but nowhere does the module claim to support multi-stream files. Nor is it an inherent feature of the underlying bzip2 library that we are failing to expose to users. [...] python 2.x users will never be able to extract multiple-stream bz2 files. Incorrect. It is perfectly possible to extract a multi-stream bz2 file in 2.x - you just need to open it with open() and decompress the data using BZ2Decompressor (pretty much the same way that 3.3's BZ2File does it). If there is really a large demand for these facilities in 2.x, I would be willing to port 3.3's BZ2File implementation to 2.x and make it available on PyPI. But this patch is not going in to the 2.7 stdlib; it is simply not the sort of behavior change that is acceptable in a bugfix release. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1625 ___ ___ 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
Terry J. Reedy tjre...@udel.edu added the comment: Really? White space makes things harder to read? I thought Pythonistas believed the opposite of that. I was surprised at that too ;-). One person's opinion in a specific context. Don't generaliza. English titling rules only capitalize the first word in hyphenated words, which is why it's Anti‐intellectual not Anti-Intellectual. Except that I can imagine someone using the latter as a noun to make the work more officious or something. There are no official English titling rules and as you noted, publishers vary. I agree that str.title should do something sensible based on Unicode, with the improvements you mentioned. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13091] ctypes: memory leak
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: How did you obtain this? the resize() function is not called by test_multiprocessing. And are you sure that it's not some kind of reference leak? (this pointer is tied to a CDataObject; its tp_alloc should free the memory) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13091 ___ ___ 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
Nadeem Vawda nadeem.va...@gmail.com added the comment: Change reverted. make test should run a comprehensive test of Python's facilities Fair enough. If it is easy to detect network availability programmatically, we could just use the skip system. +1. I don't know if there is a reasonable way to do this, but if so, that would be the best solution. -- stage: - needs patch title: make test should not enable the urlfetch resource - make test fails on systems without internet access ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12804 ___ ___ 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
Nick Coghlan ncogh...@gmail.com added the comment: Mostly looks good - couple of minor comments in Reitveld. As far as the patch flow goes, the 2.x and 3.x branches are actually handled independently (they're too divergent for merging to make sense). So 2.7 and 3.2 will be independent commits, then the changes will be merged into default from the 3.2 branch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13053 ___ ___ 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
Antoine Pitrou pit...@free.fr added the comment: If it is easy to detect network availability programmatically, we could just use the skip system. +1. I don't know if there is a reasonable way to do this, but if so, that would be the best solution. Actually, the skip system is already supposed to work for that if used properly (see test.support.transient_internet()). However, perhaps it actually doesn't work in all situations. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12804 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Nadeem Vawda nadeem.va...@gmail.com added the comment: Thanks for investigating the Windows situation. - liblzma can't be compiled by Visual Studio: too many C99 isms, mostly variables declared in the middle of a block. It's doable for sure, but it's a lot of work. I don't think that creating our own MSVC-friendly fork of liblzma is really an option. Over and above the work of porting it in the first place (and all the opportunities for bugs to creep in along the way), we'd also have to worry about keeping up to date with upstream changes. I believe we currently do something similar with libffi (for ctypes), and the impression I've gotten is that it's caused a lot of trouble. - The way recommended by XZ is to use a precompiled liblzma.dll; Then it should be easy to build an extension module, but its would be the first time that we distribute an extension module which needs a non-system DLL. Is it enough to copy it next to _lzma.pyd? Is there some work to do in the installer? I would guess that this is sufficient, but my knowledge of how Windows DLLs work is minimal. Could someone with more platform knowledge weigh in on whether this would work (and if there are any problems it might cause)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12911] Expose a private accumulator C API
Antoine Pitrou pit...@free.fr added the comment: New patch implementing Martin's suggested optimization (only instantiate the large list when necessary). -- Added file: http://bugs.python.org/file23299/accu3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12911 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Dan Stromberg strom...@gmail.com added the comment: On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda rep...@bugs.python.org wrote: Nadeem Vawda nadeem.va...@gmail.com added the comment: Thanks for investigating the Windows situation. - liblzma can't be compiled by Visual Studio: too many C99 isms, mostly variables declared in the middle of a block. It's doable for sure, but it's a lot of work. I don't think that creating our own MSVC-friendly fork of liblzma is really an option. Over and above the work of porting it in the first place (and all the opportunities for bugs to creep in along the way), we'd also have to worry about keeping up to date with upstream changes. I believe we currently do something similar with libffi (for ctypes), and the impression I've gotten is that it's caused a lot of trouble. It's much better to contribute patches upstream. - The way recommended by XZ is to use a precompiled liblzma.dll; Then it should be easy to build an extension module, but its would be the first time that we distribute an extension module which needs a non-system DLL. Is it enough to copy it next to _lzma.pyd? Is there some work to do in the installer? I would guess that this is sufficient, but my knowledge of how Windows DLLs work is minimal. Could someone with more platform knowledge weigh in on whether this would work (and if there are any problems it might cause)? I've not done much with windows dll's, but I've heard they're pretty similar to AIX shared libraries which I've done some work with. AIX shared libraries don't deal with versioning well - if you have two version of the same library on a system, you have to pop them into two different loader domains, or suffer unresolved externals at runtime. Then your applications are in of the two loader domains, and if they're in the wrong one, you again suffer unresolved externals at runtime. -- Added file: http://bugs.python.org/file23300/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___brdiv class=gmail_quoteOn Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/span wrote:brblockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex; div class=imbr Nadeem Vawda lt;a href=mailto:nadeem.va...@gmail.com;nadeem.va...@gmail.com/agt; added the comment:br br /divThanks for investigating the Windows situation.br div class=imbr gt; - liblzma can#39;t be compiled by Visual Studio: too many C99 isms, mostlybr gt; variables declared in the middle of a block.  It#39;s doable for sure, but it#39;s abr gt; lot of work.br br /divI don#39;t think that creating our own MSVC-friendly fork of liblzma is really anbr option. Over and above the work of porting it in the first place (and all thebr opportunities for bugs to creep in along the way), we#39;d also have to worry aboutbr keeping up to date with upstream changes. I believe we currently do somethingbr similar with libffi (for ctypes), and the impression I#39;ve gotten is that it#39;sbr caused a lot of trouble./blockquotedivbr/divdivIt#39;s much better to contribute patches upstream./divdiv /divblockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex; div class=im gt; - The way recommended by XZ is to use a precompiled liblzma.dll; Then itbr gt; should be easy to build an extension module, but its would be the first timebr gt; that we distribute an extension module which needs a non-system DLL.  Is itbr gt; enough to copy it next to _lzma.pyd?  Is there some work to do in thebr gt; installer?br br /divI would guess that this is sufficient, but my knowledge of how Windows DLLs workbr is minimal. Could someone with more platform knowledge weigh in on whether thisbr would work (and if there are any problems it might cause)?/blockquotedivbr/divdivI#39;ve not done much with windows dll#39;s, but I#39;ve heard they#39;re pretty similar to AIX shared libraries which I#39;ve done some work with.  AIX shared libraries don#39;t deal with versioning well - if you have two version of the same library on a system, you have to pop them into two different loader domains, or suffer unresolved externals at runtime.  Then your applications are in of the two loader domains, and if they#39;re in the wrong one, you again suffer unresolved externals at runtime./div div /div/div-- brDan Strombergbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13091] ctypes: memory leak
Meador Inge mead...@gmail.com added the comment: I can reproduce this with: valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full --suppressions=Misc/valgrind-python.supp ./python -m test test_ctypes Where as: valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full --suppressions=Misc/valgrind-python.supp ./python -m test test_multiprocessing turns up nothing in 'ctypes.resize'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13091 ___ ___ 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
Nadeem Vawda nadeem.va...@gmail.com added the comment: Oh, neat. I'll take a look at that when I get a chance. -- assignee: - nadeem.vawda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12804 ___ ___ 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
Larry Hastings la...@hastings.org added the comment: Attached is r2 of the patch, incorporating Nick's suggestions. Base revision hasn't changed. -- Added file: http://bugs.python.org/file23301/larry.cporting.capsules.r2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13053 ___ ___ 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
Larry Hastings la...@hastings.org added the comment: In case you're curious, here's how I tested capsulethunk.h. I added the file to Python 2.7 (hg head), 3.0.0 (tarball), and 3.1.0 (tarball). For 2.7 ad 3.0.0 I quickly hacked four files to use the Capsule API instead of CObjects: * Python/compile.c * Python/getargs.c * Modules/_ctypes/callproc.c * Modules/_ctypes/cfield.c (For 3.1 I simply included the file in those four files, as they already use the Capsule API.) I then built and ran regrtest.py. While developing capsulethunk.h, I had a more thorough test suite; sadly that's on a laptop that is shut off, and I'm on vacation across the Atlantic and can't get at it. But everything was working fine last I checked ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13053 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5001] Remove assertion-based checking in multiprocessing
Vlad Riscutia riscutiav...@gmail.com added the comment: Thanks for the quick review! I attached second iteration addressing feedback + changed all occurrences of checks like type(x) is y to isinstance(x, y). I would appreciate a second look because this patch has many small changes and even though I ran full test suit which passed, I'm afraid I made a typo somewhere :) -- Added file: http://bugs.python.org/file23302/issue5001_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13073] message_body argument of HTTPConnection.endheaders is undocumented
Senthil Kumaran sent...@uthcode.com added the comment: This is fixed the following changesets. changeset a3f2dba93743 changeset 1ed413b52af3 changeset 277688052c5a Thanks for the patch, Ben Hayden. -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13091] ctypes: memory leak
Meador Inge mead...@gmail.com added the comment:
this pointer is tied to a CDataObject; its tp_alloc should free the
memory
The free in 'PyCData_clear' is conditional:
if ((self-b_needsfree)
((size_t)dict-size sizeof(self-b_value)))
PyMem_Free(self-b_ptr);
As written, 'PyCData_clear' has no way of knowing that memory has been
{m,re}alloc'd in 'resize'. So in some cases memory will leak. Here is
a small reproduction case extracted from 'test_varsize_struct.py'.
from ctypes import *
class X(Structure):
_fields_ = [(item, c_int),
(array, c_int * 1)]
x = X()
x.item = 42
x.array[0] = 100
new_size = sizeof(X) + sizeof(c_int) * 5
resize(x, new_size)
One potential fix is:
diff --git a/Modules/_ctypes/_ctypes.c b/Modules/_ctypes/_ctypes.c
--- a/Modules/_ctypes/_ctypes.c
+++ b/Modules/_ctypes/_ctypes.c
@@ -2440,7 +2440,7 @@ PyCData_clear(CDataObject *self)
assert(dict); /* Cannot be NULL for CDataObject instances */
Py_CLEAR(self-b_objects);
if ((self-b_needsfree)
- ((size_t)dict-size sizeof(self-b_value)))
+ (self-b_ptr != (char *)self-b_value))
PyMem_Free(self-b_ptr);
self-b_ptr = NULL;
Py_CLEAR(self-b_base);
I need to think about that more, though.
--
versions: +Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13091
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Meador Inge mead...@gmail.com added the comment: Here is a first cut at a patch. There is one slight deviation from the original spec: some nice error checking for when the generator's frame is already gone (or the supplied object isn't a generator iterator). The attached patch returns empty mappings for these cases. I can easily add the error checks, but in what cases is it useful to know *exactly* why a mapping could not be created? Having an empty mapping for all invalid cases is simpler and seems more robust. -- keywords: +patch stage: needs patch - patch review Added file: http://bugs.python.org/file23303/issue13062.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Nick Coghlan ncogh...@gmail.com added the comment:
Because a generator can legitimately have no locals:
def gen():
... yield 1
...
g = gen()
g.gi_frame.f_locals
{}
Errors should be reported as exceptions - AttributeError or TypeError if
there's no gi_frame and then ValueError or RuntimeError if gi_frame is None.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12943] tokenize: add python -m tokenize support back
Meador Inge mead...@gmail.com added the comment: Fixed a few more nits pointed out in review. -- Added file: http://bugs.python.org/file23304/issue12943-6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Nick Coghlan ncogh...@gmail.com added the comment: The function case is simpler - AttributeError or TypeError if there's no __closure__ attribute, empty mapping if there's no closure. I've also changed my mind on the no frame generator case - since that mapping will evolve over time as the generator executes anyway, the empty mapping accurately reflects the no locals currently defined that applies when the generator either hasn't been started yet or has finished. People can use getgeneratorstate() to find that information if they need to know. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13062 ___ ___ 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
Tom Christiansen tchr...@perl.com added the comment: Really? White space makes things harder to read? I thought Pythonistas believed the opposite of that. I was surprised at that too ;-). One person's opinion in a specific context. Don't generalize. The example I initially showed probably wasn't the best for that. Mostly I was trying to demonstrate how useful it is to have user-defined properties is all. But I have no asked for that (I have asked for properties, though). English titling rules only capitalize the first word in hyphenated words, which is why it's Anti‐intellectual not Anti-Intellectual. Except that I can imagine someone using the latter as a noun to make the work more officious or something. If Good-Looking looks more officous than Good-looking, I bet GOOD-LOOKING is better still. :) There are no official English titling rules and as you noted, publishers vary. If there aren't any rules, then how come all book and movie titles always look the same? :) I don't think anyone would argue with these two: 1. Capitalize the first word, the last word, and the word right after a colon (or semicolon). 2. Capitalize all intervening words except for articles (a, an, the) and short prepositions. Those are the basic rules. The main problem is that short isn't well defined--and indeed, there are even places where preposition isn't well defined either. English has sentence casing (only the first word) and headline casing (most of them). It's problematic that computer people call capitalizing each word titlecasing, since in English, this is never correct. http://www.chicagomanualofstyle.org/CMS_FAQ/CapitalizationTitles/CapitalizationTitles23.html Although Chicago style lowercases prepositions (but see CMOS 8.157 for exceptions), some style guides uppercase them. Ask your editor for a style guide. I myself usually fall back to the Chicago Manual of Style or the Oxford Guide to Style. I don't think I do anything neither of them says to do. But I completely agree that this should *not* be in the titlecase() function. I think the docs for the function might perhaps say something about how it does not mean correct English headline case when it says titlecase, but that's largely just nitpicking. I agree that str.title should do something sensible based on Unicode, with the improvements you mentioned. One of the goals of Unicode is that casing not be language dependent. And they almost got there, too. The Turkic I is the most notable exception. Did you know there is a problem with all the case stuff in Python? It was clearly put in before they had realized that they needed to have things other the Lu/Lt/Ll have casing properties. That's why there is a difference betwen GC=Ll and the Lowercase property. str.islower() Return true if all cased characters in the string are lowercase and there is at least one cased character, false otherwise. Cased characters are those with general category property being one of “Lu”, “Ll”, or “Lt” and lowercase characters are those with general category property “Ll”. http://docs.python.org/release/3.2/library/stdtypes.html 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. 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.Under both 2.7 and 3.2, I get all these bugs: ᶜ not islower() but has at least one cased character with all cased characters lowercase! ᴰ not islower() but has at least one cased character with all cased characters lowercase! ⓚ not islower() but has at least one cased character with all cased characters lowercase! ͅ not islower() but has at least one cased character with all cased characters lowercase! Ⅷ not isupper() but has at least one cased character with all cased characters uppercase! Ⅷ not istitle() but should be ⅷ not islower() but has at least one cased character with all cased characters lowercase! 2ⁿᵈ not islower() but has at least one cased character with all cased characters lowercase! 2ᴺᴰ not islower() but has at least one cased character with all cased characters lowercase! Ὰͅ isupper() but fails to have at least one cased character with all cased characters uppercase! ThisIsInTitleCaseYouKnow not istitle() but should be Mᶜ isupper() but fails to have at least one cased character with all cased characters uppercase! ᶜM isupper() but fails to have at least one cased character with all cased characters uppercase! ᶜM istitle() but should not be MᶜKINLEY isupper() but fails to have at least one cased character with all cased characters uppercase! I really don't understand.BTW,
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Ezio Melotti ezio.melo...@gmail.com 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 better write a patch for Lib/test/test_unicode.py. Using unittest has the advantage that is then easy to integrate those tests within our test suite, but on the other hand as soon as something fails the failure is returned without evaluating the following assertions in the method. This as the
[issue13071] IDLE refuses to open on windows 7
jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal christopherdar...@gmail.com added the comment: Traceback (most recent call last): File C:\Python32\Lib\idlelib/idle.py, line 11, in module idlelib.PyShell.main() File C:\Python32\Lib\idlelib\PyShell.py,line 1377, in main shell = flist.open_shell() File C:\Python32\Lib\idlelib\PyShell.py, line 273, in open_shell self.pyshell = PyShell(self) File C:\Python32\Lib\idlelib\Pyshell.py, line 802, in __init__ OutputWindow.__init__(self,flist, none, none) File C:\Python32\Lib\idlelib\OutputWindow.py, line 16, in __init__ EditorWindow.__init__(self,*args) File C:\Python32\Lib\idlelib\EditorWindow.py, line 145, in __init__ self.aply_bindings() File C:\Python32\Lib\idlelib\EditorWindow.py, line 985, in apply_bindings text.event_add(event, *keylist) File C:\Python32\Lib\idlelib\MultiCall.py, line 359, in event_add widget.event_add(self, virtual, seq) File C:\Python32\Lib\tkinter\__init__.py, line 1353, in event_add self.tk.call(args) _tkinter.TclError: bad event type or keysym Alt -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13071 ___ ___ 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
jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal christopherdar...@gmail.com added the comment: That is the traceback given when I run idle.py through windows command prompt -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13071 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
