[issue13073] message_body argument of HTTPConnection.endheaders is undocumented

[Ben Hayden]

Ben Hayden  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 

___
___
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 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 

___
___
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 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 

___
___
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]

Georg Brandl  added the comment:

No, it's not, it's how Sphinx works. Use :class:`.time` to refer to the 
datetime class.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13089] parsetok.c: memory leak

[Stefan Krah]

New submission from Stefan Krah :

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13090] posix_read: memory leak

[Stefan Krah]

New submission from Stefan Krah :

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13091] ctypes: memory leak

[Stefan Krah]

New submission from Stefan Krah :

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 

___
___
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]

Roundup Robot  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 

___
___
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

[Stefan Krah]

New submission from Stefan Krah :

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 

___
___
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 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 

___
___
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 Krah  added the comment:

Patch looks good to me (and it fixes the problem).

--

___
Python tracker 

___
___
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

[Lance Hepler]

Changes by Lance Hepler :


--
nosy: +nlhepler

___
Python tracker 

___
___
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 Kenigsberg  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 .

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 

___
___
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 Kenigsberg  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 

___
___
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]

Éric Araujo  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 

___
___
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]

Éric Araujo  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13089] parsetok.c: memory leak

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

___
___
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]

Changes by Meador Inge :


--
components: +ctypes
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

___
Python tracker 

___
___
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()

[Stefan Krah]

New submission from Stefan Krah :

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13090] posix_read: memory leak

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +haypo

___
Python tracker 

___
___
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

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +haypo

___
Python tracker 

___
___
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]

Roundup Robot  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 

___
___
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]

Charles-François Natali  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 

___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]

Charles-François Natali  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 

___
___
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]

R. David Murray  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 

___
___
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

[lesmana]

Changes by lesmana :


--
nosy: +lesmana

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13084] test_signal failure

[Charles-François Natali]

Changes by Charles-François Natali :


--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
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]

Tom Christiansen  added the comment:

Ezio Melotti  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 ''.

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} ? lc($1) : ucfirst(lc($1

[issue5001] Remove assertion-based checking in multiprocessing

[Vlad Riscutia]

Vlad Riscutia  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 

___
___
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]

Antoine Pitrou  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 

___
___
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 Vawda  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 

___
___
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]

Terry J. Reedy  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 

___
___
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]

Amaury Forgeot d'Arc  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 

___
___
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 Vawda  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 

___
___
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]

Nick Coghlan  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 

___
___
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]

Antoine Pitrou  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 

___
___
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 Vawda  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 

___
___
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]

Antoine Pitrou  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 

___
___
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]

Dan Stromberg  added the comment:

On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda  wrote:

>
> Nadeem Vawda  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 

___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.
 -- Dan Stromberg
___
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]

Meador Inge  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 

___
___
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 Vawda  added the comment:

Oh, neat. I'll take a look at that when I get a chance.

--
assignee:  -> nadeem.vawda

___
Python tracker 

___
___
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]

Larry Hastings  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 

___
___
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]

Larry Hastings  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 

___
___
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]

Vlad Riscutia  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 

___
___
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]

Senthil Kumaran  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 

___
___
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]

Meador Inge  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 

___
___
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]

Meador Inge  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 

___
___
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]

Nick Coghlan  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 

___
___
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]

Meador Inge  added the comment:

Fixed a few more nits pointed out in review.

--
Added file: http://bugs.python.org/file23304/issue12943-6.patch

___
Python tracker 

___
___
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]

Nick Coghlan  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 

___
___
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]

Tom Christiansen  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.

[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace

[Ezio Melotti]

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 
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 

[issue13071] IDLE refuses to open on windows 7

[jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal]

jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal  added 
the comment:

Traceback (most recent call last):
  File "C:\Python32\Lib\idlelib/idle.py", line 11, in 
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 

___
___
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]

jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal  added 
the comment:

That is the traceback given when I run idle.py through windows command prompt

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

[Mark Hammond]

Mark Hammond  added the comment:

This is biting people (including me :) so I'm going to try hard to get this 
fixed.  One user on the python-win32 mailing list resorts to rebuilding every 
3rd party module he uses with this patch to get things working again (although 
apps which use only builtin modules or pywin32 modules - which already hacks 
this basic functionality in - don't see the problem.)

I'm attaching a different patch that should have the same default effect as 
Christoph's, but also allows the behaviour to be overridden.  Actually 
overriding it is quite difficult as distutils isn't setup to easily allow such 
compiler customizations - but at least it *is* possible.  To test this out I 
hacked both the pywin32 and py2erxe build processes to use those customizations 
and it works fine and allows them both to customize the behaviour to meet 
various modules' requirements.

Finally, this whole thing is still fundamentally broken for extensions which 
need a manifest (eg, to reference the common controls or the 
requestedExecutionLevel cruft).  These extension will still need to include the 
CRT reference in their manifest and thus will need a copy of the CRT next to 
each of them.  I *think* this also means they basically get a private copy of 
the CRT - they are not sharing the CRT with Python, which means they are at 
risk of hitting problems such as trying to share FILE * objects.  In practice, 
this means such modules are probably better of just embedding the CRT 
statically.  This is the route I've taken for one pywin32 module so the module 
can have a manifest and still work without a complete, private copy of the CRT 
needing to live next to it.  But even with that problem I think this patch 
should land.

It would be great if someone can review and test this version of the patch and 
I'll check it in.

--
versions: +Python 3.3, Python 3.4 -Python 2.6
Added file: 
http://bugs.python.org/file23305/bug-7833-overridable-manifest-settings.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com