[issue4541] Add str method for removing leading or trailing substrings
New submission from Zach Hirsch <[EMAIL PROTECTED]>: I've found that having a way to strip a leading substring from a string is convienent. I've also gotten bitten by the fact that str.strip takes a sequence of characters to remove from the beginning -- not a full string. I've attached a patch that implements lstrips, rstrips, and strips on str, unicode, and as methods in the string module. I'm not particularly attached to the names. Please consider this patch for inclusion in Python. Thanks! -- components: Library (Lib) files: lstrips-67529.patch keywords: patch messages: 76953 nosy: zhirsch severity: normal status: open title: Add str method for removing leading or trailing substrings type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file12232/lstrips-67529.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4541> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4541] Add str method for removing leading or trailing substrings
Zach Hirsch <[EMAIL PROTECTED]> added the comment:
Thanks for taking a look.
Yea, it's pretty easy to write it in Python, but I've found that I've
needed it in quite a few things that I've worked on, so I thought it
might be useful in Python itself.
I've updated the patch to fix the reference leak.
I could imagine someone wanting to strip the same string from both
sides, e.g. "-- hello --".strips('--').strip() == "hello". It might also
be a good idea to include str.strips for parallelism with str.strip.
Added file: http://bugs.python.org/file12236/lstrips-67529.2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4541>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4541] Add str method for removing leading or trailing substrings
Zach Hirsch <[EMAIL PROTECTED]> added the comment: Sounds good to me, except for one thing: define "sensible". To me, lstrips seems sensible, since it's a recurring pattern that I've used in multiple locations. But perhaps my sense of sensibility is warped :) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4541> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Zach Hirsch added the comment: Without msvc9compiler_stripruntimes.diff, or a patch like it, it doesn't seem possible to use pywin32 (or other binary extensions) with Python-2.6+ installed "just for me" (i.e., without the VC90 runtime installed globally). Using the python-2.6.1 MSI installed "just for me" and the pywin32-212 installer, I get the following error when trying to import win32api: Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import win32api Traceback (most recent call last): File "", line 1, in ImportError: DLL load failed: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. Removing the manifest from all the .pyd files installed by pywin32 allows me to import win32api without issue. -- nosy: +zhirsch ___ Python tracker <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2889] curses for windows (alternative patch)
Zach Hirsch added the comment: Here's a patch against the head of trunk that adds vcproj files for _curses and _curses_panel, modifies (slightly) the test suite and _cursesmodule.c (again, slightly) to get Python to work with pdcurses on windows. I also added a blurb to PCbuild\readme.txt. With this, test_curses.py passes and I'm able to run all the curses demos that come with Python's source. -- keywords: +patch nosy: +zhirsch Added file: http://bugs.python.org/file12862/python-pdcurses.patch ___ Python tracker <http://bugs.python.org/issue2889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5447] future unicode literals and r'\u'
Zach Hirsch added the comment: I've hit this, too, and it's annoyed me. So here's a patch against trunk that should fix it. The idea is: whenever unicode_literals are turned on (or the -U command line flag is passed), to convert r"\u" to "\u005c\u0075" and r"\U" to "\u005c\u0055" for every string literal in the source file before passing the string to PyUnicode_DecodeRawUnicodeEscape. -- keywords: +patch message_count: 2.0 -> 3.0 nosy: +zhirsch nosy_count: 2.0 -> 3.0 Added file: http://bugs.python.org/file13280/raw-unicode-literals.patch ___ Python tracker <http://bugs.python.org/issue5447> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2889] curses for windows (alternative patch)
Zach Hirsch added the comment: > * test_curses: I'd be happier to see the 'if' statement as sys.platform > != 'win32' and (not term or term == 'unknown') -- easier to read. OK, fixed. > * test_curses: does putp() make PDCurses crash, or is it not available? > If the latter, I'd prefer to see 'if hasattr(curses, "putp"): '.Same for the tparm() test. They're stubs in pdcurses that always return an error. I'm not sure which is better in this case -- make them available through the curses module but always raise an exception on Windows, or make them unavailable and have it be an AttributeError if something tries to call them on Windows. > * Given that you include term.h and IRIX included term.h, I wonder if we > should make _cursesmodule.c include term.h on all platforms that have it, and then fix the resulting breakage claimed by the comment (if any). Yea, it was actually really easy to resolve the conflicts. I've done that, and tested the result on Linux and OS X 10.4. > * Is setupterm() a no-up on Windows? Maybe the function just shouldn't > be defined on Windows, then, so that user code can check for the function's existence. PDCurses does the same thing for setupterm as it does for putp/tparm (and a number of other unsupported functions) -- always returns an error. However, the curses module keeps track of whether it's been initialized based on whether setupterm has been called, so I think it makes sense to keep setupterm available but not call PDCurses's setupterm function on Windows. -- message_count: 4.0 -> 5.0 Added file: http://bugs.python.org/file13282/python-pdcurses-2.patch ___ Python tracker <http://bugs.python.org/issue2889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2622] Import errors in email.message.py
Zach Hirsch added the comment: I'm not sure if this is the same problem, but it seems related. I can get the same ImportError without involving py2exe or modulefinder: Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> import email.message >>> sys.modules = sys.modules.copy() >>> msg = email.message.Message() >>> msg['From'] = 'f...@bar.com' >>> msg.as_string() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/email/message.py", line 128, in as_string from email.Generator import Generator File "/usr/lib/python2.5/email/__init__.py", line 80, in __getattr__ mod = sys.modules[self.__name__] KeyError: 'email.generator' If the "sys.modules = sys.modules.copy()" line is left out, everything works as expected. -- nosy: +zhirsch ___ Python tracker <http://bugs.python.org/issue2622> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
