Re: [Python-Dev] textwrap wordsep_re
On Mon, Feb 21, 2005, Karl Chen wrote:
>
> A slightly tweaked wordsep_re:
> textwrap.TextWrapper.wordsep_re = \
> re.compile(r'(\s+|' # any whitespace
>r'[^\s\w]*\w+[a-zA-Z]-(?=[a-zA-Z]\w+)|' # hyphenated words
>r'(?<=[\w\!\"\'\&\.\,\?])-{2,}(?=\w))') # em-dash
> print textwrap.fill('aa 2005-02-21', 18)
> behaves better:
> aa
> 2005-02-21
>
> What do you think about changing the default wordsep_re?
Please post a patch to SF. If you're not familiar with the process,
take a look at http://www.python.org/dev/dev_intro.html
Another thing: I don't know whether you'll get this in direct e-mail;
it's considered a bit rude for python-dev to use munged addresses.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR
___
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] UserString
> Really? I do this kind of thing all the time: > > import os > import errno > try: > os.makedirs(dn) > except OSError, e: > if e.errno <> errno.EEXIST: > raise You have a lot more faith in the errno module than I do. Are you sure the same error codes work on all platforms where Python works? It's also not exactly readable (except for old Unix hacks). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] UserString
On Tue, 22 Feb 2005 08:16:52 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Really? I do this kind of thing all the time: > > > > import os > > import errno > > try: > > os.makedirs(dn) > > except OSError, e: > > if e.errno <> errno.EEXIST: > > raise > > You have a lot more faith in the errno module than I do. Are you sure > the same error codes work on all platforms where Python works? It's > also not exactly readable (except for old Unix hacks). Agreed. In general, I often wish in production code (especially in not-100% Python systems) that Python did a better job of at the very least documenting what kinds of exceptions were raised by what function calls. Otherwise you end up with what are effectively blanket try/except statements way too often for my taste. --da ___ 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] Re: Prospective Peephole Transformation
Fredrik Lundh wrote: it could be worth expanding them to "if x == 1 or x == 2 or x == 3:" though... C:\>timeit -s "a = 1" "if a in (1, 2, 3): pass" 1000 loops, best of 3: 0.11 usec per loop C:\>timeit -s "a = 1" "if a == 1 or a == 2 or a == 3: pass" 1000 loops, best of 3: 0.0691 usec per loop C:\>timeit -s "a = 2" "if a == 1 or a == 2 or a == 3: pass" 1000 loops, best of 3: 0.123 usec per loop C:\>timeit -s "a = 2" "if a in (1, 2, 3): pass" 1000 loops, best of 3: 0.143 usec per loop C:\>timeit -s "a = 3" "if a == 1 or a == 2 or a == 3: pass" 1000 loops, best of 3: 0.187 usec per loop C:\>timeit -s "a = 3" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.197 usec per loop C:\>timeit -s "a = 4" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.225 usec per loop C:\>timeit -s "a = 4" "if a == 1 or a == 2 or a == 3: pass" 1000 loops, best of 3: 0.161 usec per loop Out of curiousity I ran /F's tests on my FreeBSD 4.8 box with a recent checkout: $ ./python Lib/timeit.py -s "a = 1" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.247 usec per loop $ ./python Lib/timeit.py -s "a = 1" "if a == 1 or a == 2 or a == 3: pass" 100 loops, best of 3: 0.225 usec per loop $ ./python Lib/timeit.py -s "a = 2" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.343 usec per loop $ ./python Lib/timeit.py -s "a = 2" "if a == 1 or a == 2 or a == 3: pass" 100 loops, best of 3: 0.353 usec per loop $ ./python Lib/timeit.py -s "a = 3" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.415 usec per loop $ ./python Lib/timeit.py -s "a = 3" "if a == 1 or a == 2 or a == 3: pass" 100 loops, best of 3: 0.457 usec per loop $ ./python Lib/timeit.py -s "a = 4" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.467 usec per loop $ ./python Lib/timeit.py -s "a = 4" "if a == 1 or a == 2 or a == 3: pass" 100 loops, best of 3: 0.488 usec per loop I then applied this patch: --- Objects/tupleobject.c.orig Fri Jun 11 05:28:08 2004 +++ Objects/tupleobject.c Tue Feb 22 22:10:18 2005 @@ -298,6 +298,11 @@ int i, cmp; for (i = 0, cmp = 0 ; cmp == 0 && i < a->ob_size; ++i) + cmp = (PyTuple_GET_ITEM(a, i) == el); + if (cmp) + return cmp; + + for (i = 0, cmp = 0 ; cmp == 0 && i < a->ob_size; ++i) cmp = PyObject_RichCompareBool(el, PyTuple_GET_ITEM(a, i), Py_EQ); return cmp; Re-running the tests yielded: $ ./python Lib/timeit.py -s "a = 1" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.234 usec per loop $ ./python Lib/timeit.py -s "a = 1" "if a == 1 or a == 2 or a == 3: pass" 100 loops, best of 3: 0.228 usec per loop $ ./python Lib/timeit.py -s "a = 2" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.239 usec per loop $ ./python Lib/timeit.py -s "a = 2" "if a == 1 or a == 2 or a == 3: pass" 100 loops, best of 3: 0.36 usec per loop $ ./python Lib/timeit.py -s "a = 3" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.241 usec per loop $ ./python Lib/timeit.py -s "a = 3" "if a == 1 or a == 2 or a == 3: pass" 100 loops, best of 3: 0.469 usec per loop $ ./python Lib/timeit.py -s "a = 4" "if a in (1, 2, 3): pass" 100 loops, best of 3: 0.475 usec per loop $ ./python Lib/timeit.py -s "a = 4" "if a == 1 or a == 2 or a == 3: pass" 100 loops, best of 3: 0.489 usec per loop - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ 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] textwrap.py wordsep_re
Hi,
textwrap.fill() is awesome.
Except when the string to wrap contains dates -- which I would
like not to be filled. In general I think wordsep_re can be
smarter about what it decides are hyphenated words.
For example, this code:
print textwrap.fill('aa 2005-02-21', 18)
produces:
aa 2005-
02-21
A slightly tweaked wordsep_re:
textwrap.TextWrapper.wordsep_re =\
re.compile(r'(\s+|' # any whitespace
r'[^\s\w]*\w+[a-zA-Z]-(?=[a-zA-Z]\w+)|' # hyphenated words
r'(?<=[\w\!\"\'\&\.\,\?])-{2,}(?=\w))') # em-dash
print textwrap.fill('aa 2005-02-21', 18)
behaves better:
aa
2005-02-21
What do you think about changing the default wordsep_re?
--
Karl 2005-02-21 03:32
___
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] UserString
On Tuesday 22 February 2005 03:01 am, Guido wrote: > > BTW, there's *still* no sign from a PEP 246 rewrite. Maybe someone > could offer Clark a hand? (Last time I inquired he was recovering from > a week of illness.) Last summer Alex, Clark, Phillip and I swapped a few emails about reviving the 245/246 drive and submitting a plan for a PSF grant. I was pushing the effort and then had to lamely drop out due to a new job. This is good grant material for someone which leads to my question, when will the next cycle of PSF grants happen? I'm not volunteering and I won't have the bandwidth to participate, but if there are other starving souls out there willing to do the heavy lifting to help Alex it could get done quickly within the PSFs own framework for advancing the language. -Michel ___ 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] UserString
>> if e.errno <> errno.EEXIST: >> raise > >You have a lot more faith in the errno module than I do. Are you sure >the same error codes work on all platforms where Python works? It's >also not exactly readable (except for old Unix hacks). On the other hand, LBYL in this context can result in race conditions and security vulnerabilities. "os.makedirs" is already a composite of many system calls, so all bets are off anyway, but for simpler operations that result in an atomic system call, this is important. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ 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] Re: [Python-checkins] python/dist/src/Python compile.c, 2.344, 2.345
[EMAIL PROTECTED] > Modified Files: >compile.c > Log Message: > Teach the peepholer to fold unary operations on constants. > > Afterwards, -0.5 loads in a single step and no longer requires a runtime > UNARY_NEGATIVE operation. Aargh. The compiler already folded in a leading minus for ints, and exempting floats from this was deliberate. Stick this in a file: import math print math.atan2(-0.0, -0.0) If you run that directly, a decent 754-conforming libm will display an approximation to -pi (-3.14...; this is the required result in C99 if its optional 754 support is implemented, and even MSVC has done this all along). But if you import the same module from a .pyc or .pyo, now on the HEAD it prints 0.0 instead. In 2.4 it still prints -pi. I often say that all behavior in the presence of infinities, NaNs, and signed zeroes is undefined in CPython, and that's strictly true (just _try_ to find reassuring words about any of those cases in the Python docs ). But it's still the case that we (meaning mostly me) strive to preserve sensible 754 semantics when it's reasonably possible to do so. Not even gonzo-optimizing Fortran compilers will convert -0.0 to 0.0 anymore, precisely because it's not semantically neutral. In this case, it's marshal that drops the sign bit of a float 0 on the floor, so surprises result if and only if you run from a precompiled Python module now. I don't think you need to revert the whole patch, but -0.0 must be left alone (or marshal taught to preserve the sign of a float 0.0 -- but then you have the problem of _detecting_ the sign of a float 0.0, and nothing in standard C89 can do so). Even in 754-land, it's OK to fold in the sign for non-zero float literals (-x is always unexceptional in 754 unless x is a signaling NaN, and there are no signaling NaN literals; and the sign bit of any finite float except zero is already preserved by marshal). ___ 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] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 308 open (+10) / 2755 closed ( +1) / 3063 total (+11)
Bugs: 838 open (+15) / 4834 closed ( +5) / 5672 total (+20)
RFE : 168 open ( +0) / 148 closed ( +4) / 316 total ( +4)
New / Reopened Patches
__
do not add directory of sys.argv[0] into sys.path (2004-05-02)
http://python.org/sf/946373 reopened by wrobell
isapi.samples.advanced.py fix (2005-02-17)
http://python.org/sf/1126187 opened by Philippe Kirsanov
more __contains__ tests (2005-02-17)
http://python.org/sf/1141428 opened by Jim Jewett
Fix to allow urllib2 digest auth to talk to livejournal.com (2005-02-18)
http://python.org/sf/1143695 opened by Benno Rice
Add IEEE Float support to wave.py (2005-02-19)
http://python.org/sf/1144504 opened by Ben Schwartz
cgitb: make more usable for 'binary-only' sw (new patch) (2005-02-19)
http://python.org/sf/1144549 opened by Reinhold Birkenfeld
allow UNIX mmap size to default to current file size (new) (2005-02-19)
http://python.org/sf/1144555 opened by Reinhold Birkenfeld
Make OpenerDirector instances pickle-able (2005-02-20)
http://python.org/sf/1144636 opened by John J Lee
webbrowser.Netscape.open bug fix (2005-02-20)
http://python.org/sf/1144816 opened by Pernici Mario
Replace store/load pair with a single new opcode (2005-02-20)
http://python.org/sf/1144842 opened by Raymond Hettinger
Remove some invariant conditions and assert in ceval (2005-02-20)
http://python.org/sf/1145039 opened by Neal Norwitz
Patches Closed
__
date.strptime and time.strptime as well (2005-02-04)
http://python.org/sf/1116362 closed by josh-sf
New / Reopened Bugs
___
attempting to use urllib2 on some URLs fails starting on 2.4 (2005-02-16)
http://python.org/sf/1123695 opened by Stephan Sokolow
descrintro describes __new__ and __init__ behavior wrong (2005-02-15)
http://python.org/sf/1123716 opened by Steven Bethard
gensuitemodule.processfile fails (2005-02-16)
http://python.org/sf/1123727 opened by Jurjen N.E. Bos
PyDateTime_FromDateAndTime documented as PyDate_FromDateAndT (2005-02-16)
CLOSED http://python.org/sf/1124278 opened by smilechaser
Function's __name__ no longer accessible in restricted mode (2005-02-16)
CLOSED http://python.org/sf/1124295 opened by Tres Seaver
Python24.dll crashes, EXAMPLE ATTACHED (2005-02-12)
CLOSED http://python.org/sf/1121201 reopened by complex
IDLE line wrapping (2005-02-16)
CLOSED http://python.org/sf/1124503 opened by Chris Rebert
test_os fails on 2.4 (2005-02-17)
CLOSED http://python.org/sf/1124513 reopened by doerwalter
test_os fails on 2.4 (2005-02-16)
CLOSED http://python.org/sf/1124513 opened by Brett Cannon
test_subprocess is far too slow (2005-02-17)
http://python.org/sf/1124637 opened by Michael Hudson
Math mode not well handled in \documentclass{howto} (2005-02-17)
http://python.org/sf/1124692 opened by Daniele Varrazzo
GetStdHandle in interactive GUI (2005-02-17)
http://python.org/sf/1124861 opened by davids
subprocess.py Errors with IDLE (2005-02-17)
http://python.org/sf/1126208 opened by Kurt B. Kaiser
subprocesss module retains older license header (2005-02-17)
http://python.org/sf/1138653 opened by Tres Seaver
Python syntax is not so XML friendly! (2005-02-18)
CLOSED http://python.org/sf/1143855 opened by Colbert Philippe
inspect.getsource() breakage in 2.4 (2005-02-18)
http://python.org/sf/1143895 opened by Armin Rigo
future warning in commets (2005-02-18)
http://python.org/sf/1144057 opened by Grzegorz Makarewicz
reload() is broken for C extension objects (2005-02-19)
http://python.org/sf/1144263 opened by Matthew G. Knepley
htmllib quote parse error within a
