Re: [Python-Dev] String concatenation
Tres Seaver wrote:
- -1. The feature exists to allow adherence to PEP-8, "Limit all lines to
a maximum of 79 characters.", without requiring runtime concatenation
costs. I use it frequently when assembling and testing message strings,
for instance.
removing it is a bad idea for the reasons already given, but requiring
parentheses could help.
that is, the following would result in a warning or an error:
L = ["first", "second" "third"]
but the following wouldn't:
L = ["first", ("second" "third")]
T = ("This is a line of text.\n"
"This is another line of text.\n")
etc.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] String concatenation
On Sat, 23 Aug 2008, Fredrik Lundh wrote:
removing it is a bad idea for the reasons already given, but requiring
parentheses could help.
that is, the following would result in a warning or an error:
L = ["first", "second" "third"]
but the following wouldn't:
L = ["first", ("second" "third")]
T = ("This is a line of text.\n"
"This is another line of text.\n")
This would avoid accidentally leaving out commas in list construction, but
tuple construction would still have the same problem. And it's still a
change in the language which would probably affect lots of existing code.
I doubt if there is any problem-free way of trying to address this issue
by changing the language.
One suggestion to help minimize problems when writing code would be always
to put the optional trailing comma:
[
'a',
'b',
'c',
]
which is also a revision-control-friendly practice, and in the tuple
constuction context avoids the possibility of removing an item from a
two-tuple and ending up with not a one-tuple but instead just the item
itself.
Isaac Morland CSCF Web Guru
DC 2554C, x36650WWW Software Specialist
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] String concatenation
>Isaac Morland wrote: This would avoid accidentally leaving out commas in list construction, but tuple construction would still have the same problem. Tuple construction already has a "no comma, no tuple" problem. That problem remains, but as soon as you add a comma, you'll get the same protection as you get for lists. > And it's still a change in the language which would probably affect > lots of existing code. Having read and written tons of existing code, I'm not so sure about that. A tool that wraps backslash-escaped blocks in parentheses would take care of most cases. What's left after that is probably ambiguous to a human reader anyway. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "error: None" when building extensions under 2.6
when I'm trying to build extensions under Python 2.6 on Windows XP, the build process terminates with single line that says: error: None which is about as useless as an error message can be. Googling for this brings up a few hits which all seem to involve setuptools (and none of the hits contain any answers), but I'm using straightforward distutils stuff that has worked without a glitch since 1.5.2. Has anyone else seen this for 2.6? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Committer guidelines
Brett Cannon wrote: > On Sat, Aug 23, 2008 at 1:50 PM, Benjamin Peterson > <[EMAIL PROTECTED]> wrote: >> On Sat, Aug 23, 2008 at 3:48 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >>> I don't think Victor has commit privileges, which would mean you >>> should have had another committer review this first before committing. >> Ah. Ok. >> >> Can we make a wiki page for rules like this? I feel like I'm poking >> around it a dark room which is actually a monster's mouth. :) > > This commit review thing is new to all of us; never been done while I > have been around. It's just that committing a non-committers patch > without a second opinion is just like any other external patch we > accept, and thus lacks the extra protection that having a second > committer sign off it gives us during the rc phase. > > And yes, I will write up a doc on all of this after we hit final. My > current plan is that once we release final to spark a conversation > about our workflow and then write up a doc that lists what is expected > for each step in the life of an issue. In the meantime, I put some (very) rough notes based on what we did for the betas and are doing for the release candidates up on the wiki: http://wiki.python.org/moin/PythonCommitterGuidelines Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] current problems that should be fixed before release (2.6)
Below are the problems I found that have not been fixed at r65995 on trunk (2.6). There will be a separate mail for the 3.0 problems. I've done the following: * built in debug and opt mode (gcc 4.1.2) fixing the important warnings * run all the tests in both modes * run all the tests (except test_logging and test_ssl) under valgrind 3.3.1 fixing the problems * run failmalloc (1.0) on startup for the first 4000 allocations fixing most problems * run pychecker 0.8.18 over the stdlib (Lib/*.py, Lib/[bcdelhjmswx]*/*.py) Can someone run purify on windows over 2.6? Can someone (else) compare performance of 2.5, 2.6, and 3.0? pychecker reported problems: Lib/gzip.py:114: Using property (filename) in classic class GzipFile may not work Lib/io.py:1394: No module attribute (device_encoding) found - device_encoding access is protected, but I don't see where it can be set Lib/sched.py:122: Using property (queue) in classic class scheduler may not work Lib/tempfile.py:535: Using property (closed) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:539: Using property (encoding) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:553: Using property (mode) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:557: Using property (name) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:561: Using property (newlines) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:580: Using property (softspace) in classic class SpooledTemporaryFile may not work Lib/multiprocessing/connection.py:95: No global (PipeListener) found Lib/multiprocessing/connection.py:132: No global (PipeClient) found - both of the Pipe classes are defined only for windows. I don't see a similar def for Unix. Lib/multiprocessing/connection.py:378: No global (AuthenticationError) found I haven't looked into the property complaint to see how bad it is. test_bsddb3 is failing on several 2.6 buildbots. test_bsddb3 leaks 80 references. Results of valgrind 3.3.1 on Ubuntu 6.10 amd64, gcc 4.1.2 (prerelease): Uninitialized memory reads: No problems in python code. Though it's possible there are errors in ctypes. I'm ignoring those reports due to a problem in dlopen. Wild memory writes: No problems in python code. Memory leaks: No major problems. However, it seems that there are a bunch of little leaks when forking a process. I haven't determined if these are real problems or not. There is one memory leak in ctypes (sorry no real useful information): 44 bytes in 1 blocks are definitely lost in loss record 43 of 191 malloc (vg_replace_malloc.c:207) resize (callproc.c:1733) It seems to always leak 44 bytes n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
