[ python-Bugs-1190599 ] dir() docs show incorrect output
Bugs item #1190599, was opened at 2005-04-26 23:20 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190599&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Chase (stillflame) >Assigned to: Michael Hudson (mwh) Summary: dir() docs show incorrect output Initial Comment: on the web at http://docs.python.org/tut/node8.html under "6.3 The dir() Function", the following text reports incorrectly what the dir() call would return: >>> a = [1, 2, 3, 4, 5] >>> import fibo, sys >>> fib = fibo.fib >>> dir() ['__builtins__', '__doc__', '__file__', '__name__', 'fib', 'fib2'] it should have 'a' and 'fibo', but not 'fib2'. -- >Comment By: Michael Hudson (mwh) Date: 2005-04-27 11:00 Message: Logged In: YES user_id=6656 Fixed in rev 1.270 of Doc/tut.tex. Thanks for the report! -- Comment By: George Yoshida (quiver) Date: 2005-04-27 04:36 Message: Logged In: YES user_id=671362 A minor nit. > it should have 'a' and 'fibo', 'sys' is also missing from the list. >>> dir() ['__builtins__', '__doc__', '__file__', '__name__', 'a', 'fib', 'fibo', ' sys'] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190599&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-640110 ] email.Header misparses mixed headers
Bugs item #640110, was opened at 2002-11-18 15:33
Message generated for change (Comment added) made by kalinda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Anders Hammarquist (iko)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Header misparses mixed headers
Initial Comment:
email.Header.decode_header() misparses headers with
both encoded an unencoded words. This example from RFC2047
=?ISO-8859-1?Q?Andr=E9?= Pirard <[EMAIL PROTECTED]>
gets parsed as
AndréPirard <[EMAIL PROTECTED]>
where there should obviously be a space between André
and Pirard. RFC2047 says to ignore spaces between
encoded words (but not between encoded and unencoded
words, though it doesn't explicitly say so from what I
could find, and obviously not between unencoded words).
Also, I see it's trying to handle continuation lines,
but it only does it if there are encoded words in the
continuation line. It barfs badly on this test case:
'Re: =?mac-iceland?q?r=8Aksm=9Arg=8Cs?= baz\n foo bar
=?mac-iceland?q?r=8Aksm=9Arg=8Cs?='
I think I'll just do a patch...
/Anders
P.S. It seems at least remotely related to Bug#552957
--
Comment By: jonny reichwald (kalinda)
Date: 2005-04-27 14:23
Message:
Logged In: YES
user_id=661399
I am using python 2.4 and still have this problem. To be
more exact, line 73 in Header.py still strips the parts.
Is there a reason for this not being fixed?
--
Comment By: Anders Hammarquist (iko)
Date: 2003-03-06 17:43
Message:
Logged In: YES
user_id=14
Looks OK.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-06 17:21
Message:
Logged In: YES
user_id=12800
Try current cvs.
--
Comment By: Anders Hammarquist (iko)
Date: 2003-03-06 15:15
Message:
Logged In: YES
user_id=14
The first bug is still there... With version 1.19 from CVS I
get this with my example:
>>> print
unicode(Header.make_header(Header.decode_header('=?ISO-8859-1?Q?Andr=E9?=
Pirard <[EMAIL PROTECTED]>'))).encode('latin-1')
AndréPirard <[EMAIL PROTECTED]>
(The problem is that whitespaces get stripped of on line 91:
unenc = parts.pop(0).strip()
before we know whether they are significant or not.
The continuation line bug seems to be fixed however.
/Anders
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-06 07:50
Message:
Logged In: YES
user_id=12800
The first bug above has already been fixed in email 2.5
(python 2.3 cvs). The second pointed to a real bug, now
fixed I believe.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1191043 ] bz2 RuntimeError when decompressing file
Bugs item #1191043, was opened at 2005-04-27 10:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris AtLee (catlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: bz2 RuntimeError when decompressing file
Initial Comment:
The following code:
echo -n Testing123 | bzip2 > test.bz2
python -c "import bz2; lines =
bz2.BZ2File('test.bz2').readlines()"
produces this output:
Traceback (most recent call last):
File "", line 1, in ?
RuntimeError: wrong sequence of bz2 library commands used
Tested on Python 2.4.1 (debian unstable - April 1
2005), and Python 2.3.5 (debian unstable - May 26 2005)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1191104 ] Warning ``error`` filter action is ignored.
Bugs item #1191104, was opened at 2005-04-27 17:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191104&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivan Vilata i Balaguer (ivilata)
Assigned to: Nobody/Anonymous (nobody)
Summary: Warning ``error`` filter action is ignored.
Initial Comment:
Hi all. It seems that setting the ``error`` action on
a warning message once it has already been triggered
does not allow it to be triggered again. As usual, the
code is clearer than the explanation::
import warnings
def do_warn():
warnings.warn("A warning.", DeprecationWarning)
do_warn()
warnings.filterwarnings('error',
category=DeprecationWarning)
do_warn()
warnings.filterwarnings('always',
category=DeprecationWarning)
do_warn()
The output of this program is::
nowarn.py:4: DeprecationWarning: A warning.
warnings.warn("A warning.", DeprecationWarning)
There is no exception raised, though the filter was
instructed to turn the warning into an error. Take
note that using ``always`` has similar results.
Does it work in that way on purpose? I find it quite
counterintuitive, IMHO. If this behaviour is intended,
what would be the way to turn the second warning into
an exception?
Thanks!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191104&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1190689 ] logging module '.' behavior
Feature Requests item #1190689, was opened at 2005-04-26 20:19
Message generated for change (Comment added) made by cxdunn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Dunn (cxdunn)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module '.' behavior
Initial Comment:
I would like a trailing '.' to be ignored in names
passed to getLogger(), like a trainling '/' in a Unix path.
In module 'foo':
logfoo = getLogger('.foo.')
# logger '"" should be the parent of ".foo"
Elsewhere, controlled by the user of that module:
import foo
logdefault = getLogger('.')
hdlr = StreamHandler()
fmtr = Formatter("%(name)s:%(msg)s")
hdlr.setFormatter(fmtr)
logdefault.addHandler(hdlr)
Given this change, I would also like the name of the
default logger to be displayed as '.', or even "",
rather than 'root'. The current behavior is odd:
logfoo.info("Foo message")
displays
.foo:Foo message
buf
logdefault.info("Default message")
displays
root:Default message
I NEVER mentioned the word "root" anywhere! And I don't
think it's very descriptive.
I would rather see ANY of these:
:Default message
.:Default message
default:Default message
logging:Default message
These changes would make the system more intuitive.
-cxdunn
--
>Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-27 15:37
Message:
Logged In: YES
user_id=1267419
Novices always ask, "Why did it print 'root'? Where did that
come from?
After discussing this with some other "logging" module
users, I think we've come up with a very good idea, which
would maintain BACKWARDS COMPATIBILITY.
Essentially, treat the logging module as a shell and the
logger name as a path. Specifically,
* Let the global logging functions operate on the "current
worrking logger", which by default is "." (Let "root" be an
alias for ".")
* Change getLogger() so that it works on both absolute and
relative logger paths. (Since the default current logger is
"root", we maintain backwards compatibility.)
* Change the format function so that %(name)s shows the
relative path, if the absolute path starts with the current
working logger name.
* Add a format keyword, %(absname)s, which prints the
absolute logger path.
* Add another format keyword, %(logger)s, which prints what
most people expect to see: the absolute logger name, sans
the leading dot. (The "root" or "." logger would display as
"", exactly the way it is usually accessed.)
* Add global functions, change_current_logger() and
get_current_logger().
* Add global function, alias(). Always create an alias for
"root" to "."
Examples::
from logging import *
log = getLogger() #or getLogger(".") or getLogger("root")
h1 = StreamHandler()
f1 = Formatter("[%(name)s]%(message)s")
h1.setFormatter(f1)
log.addHandler(h1)
h2 = StreamHandler()
f2 = Formatter("[%(absname)s]%(message)s")
h2.setFormatter(f2)
log.addHandler(h2)
h3 = StreamHandler()
f3 = Formatter("[%(logger)s]%(message)s")
h3.setFormatter(f3)
log.addHandler(h3)
log.error("First message")
# ...
child = getLogger("child") # or getLogger(".child")
child.error("Bad news")
This should print:
[root]First message
[.]First message
[]First message
[child]Bad news
[.child]Bad news
[child]Bad news
This would create tremendous flexibility, add some clarity
to the meaning of the "root" logger, and still maintain
complete backwards compatibility.
I am willing to make the changes myself, including
UnitTests, if there is agreement that they would be adopted.
(Note that String.before() and String.after() would make the
coding a little easier/clearer, but that's a different
feature request.)
-cxdunn
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1191420 ] cStringIO has reset(), but StringIO does not
Feature Requests item #1191420, was opened at 2005-04-27 20:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191420&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher Dunn (cxdunn) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO has reset(), but StringIO does not Initial Comment: from cStringIO import StringIO s = StringIO() s.reset() from StringIO import StringIO s = StringIO() s.reset() # error! reset() is not critical, since it just does the same thing as seek(0), but cStringIO and StringIO are supposed to be interchangeable. -cxdunn -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191420&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1191458 ] [AST] Failing tests
Bugs item #1191458, was opened at 2005-04-27 20:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1190010 ] [AST] assignment to None allowed
Bugs item #1190010, was opened at 2005-04-25 23:07 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190010&group_id=5470 Category: Parser/Compiler Group: AST >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] assignment to None allowed Initial Comment: ``None = 42`` should raise a SyntaxError. Detected by test_compile. -- >Comment By: Brett Cannon (bcannon) Date: 2005-04-27 20:33 Message: Logged In: YES user_id=357491 Fixed in rev. 1.1.2.62 . One less failure in test_compile. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190010&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1191420 ] cStringIO has reset(), but StringIO does not
Feature Requests item #1191420, was opened at 2005-04-27 20:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191420&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Christopher Dunn (cxdunn) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO has reset(), but StringIO does not Initial Comment: from cStringIO import StringIO s = StringIO() s.reset() from StringIO import StringIO s = StringIO() s.reset() # error! reset() is not critical, since it just does the same thing as seek(0), but cStringIO and StringIO are supposed to be interchangeable. -cxdunn -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-27 23:57 Message: Logged In: YES user_id=80475 On the surface, it would seem like a good idea; however, reset() was a mistake that should not be propagated. The API should be as file-like as possible. Since there is no file.reset(), there should not be a StringO.reset(). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191420&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1190701 ] Add 'before' and 'after' methods to Strings
Feature Requests item #1190701, was opened at 2005-04-26 20:35
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190701&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Dunn (cxdunn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 'before' and 'after' methods to Strings
Initial Comment:
GNU String used to have two very useful methods,
'before' and 'after'. These are so useful I keep them
defined in an __init__.py file. (Unfortunately, I do
not know how to make them methods, instead of global
functions.)
Usage:
>>> "root.sub".before(".")
'root'
>>> "root.sub1.sub2".after("root.sub1")
'.sub2'
They work like s.split(word)[0], and s.split(word)[-1],
but they are so intuitive they ought to be part of the
interface.
I'm not sure whether they should raise exceptions on
failure, or simply return the whole string.
-cxdunn
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 00:15
Message:
Logged In: YES
user_id=80475
I'm -1 on expanding the string API for something so easily
coded with existing primitives:
>>> s = "root.sub"
>>> t = "."
>>> s[:s.find(t)]
'root'
>>> s = "root.sub1.sub2"
>>> t = "root.sub1"
>>> s[s.find(sep)+len(sep):]
'sub1.sub2'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190701&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1190689 ] logging module '.' behavior
Feature Requests item #1190689, was opened at 2005-04-26 20:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Dunn (cxdunn)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging module '.' behavior
Initial Comment:
I would like a trailing '.' to be ignored in names
passed to getLogger(), like a trainling '/' in a Unix path.
In module 'foo':
logfoo = getLogger('.foo.')
# logger '"" should be the parent of ".foo"
Elsewhere, controlled by the user of that module:
import foo
logdefault = getLogger('.')
hdlr = StreamHandler()
fmtr = Formatter("%(name)s:%(msg)s")
hdlr.setFormatter(fmtr)
logdefault.addHandler(hdlr)
Given this change, I would also like the name of the
default logger to be displayed as '.', or even "",
rather than 'root'. The current behavior is odd:
logfoo.info("Foo message")
displays
.foo:Foo message
buf
logdefault.info("Default message")
displays
root:Default message
I NEVER mentioned the word "root" anywhere! And I don't
think it's very descriptive.
I would rather see ANY of these:
:Default message
.:Default message
default:Default message
logging:Default message
These changes would make the system more intuitive.
-cxdunn
--
Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-27 15:37
Message:
Logged In: YES
user_id=1267419
Novices always ask, "Why did it print 'root'? Where did that
come from?
After discussing this with some other "logging" module
users, I think we've come up with a very good idea, which
would maintain BACKWARDS COMPATIBILITY.
Essentially, treat the logging module as a shell and the
logger name as a path. Specifically,
* Let the global logging functions operate on the "current
worrking logger", which by default is "." (Let "root" be an
alias for ".")
* Change getLogger() so that it works on both absolute and
relative logger paths. (Since the default current logger is
"root", we maintain backwards compatibility.)
* Change the format function so that %(name)s shows the
relative path, if the absolute path starts with the current
working logger name.
* Add a format keyword, %(absname)s, which prints the
absolute logger path.
* Add another format keyword, %(logger)s, which prints what
most people expect to see: the absolute logger name, sans
the leading dot. (The "root" or "." logger would display as
"", exactly the way it is usually accessed.)
* Add global functions, change_current_logger() and
get_current_logger().
* Add global function, alias(). Always create an alias for
"root" to "."
Examples::
from logging import *
log = getLogger() #or getLogger(".") or getLogger("root")
h1 = StreamHandler()
f1 = Formatter("[%(name)s]%(message)s")
h1.setFormatter(f1)
log.addHandler(h1)
h2 = StreamHandler()
f2 = Formatter("[%(absname)s]%(message)s")
h2.setFormatter(f2)
log.addHandler(h2)
h3 = StreamHandler()
f3 = Formatter("[%(logger)s]%(message)s")
h3.setFormatter(f3)
log.addHandler(h3)
log.error("First message")
# ...
child = getLogger("child") # or getLogger(".child")
child.error("Bad news")
This should print:
[root]First message
[.]First message
[]First message
[child]Bad news
[.child]Bad news
[child]Bad news
This would create tremendous flexibility, add some clarity
to the meaning of the "root" logger, and still maintain
complete backwards compatibility.
I am willing to make the changes myself, including
UnitTests, if there is agreement that they would be adopted.
(Note that String.before() and String.after() would make the
coding a little easier/clearer, but that's a different
feature request.)
-cxdunn
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1190033 ] The array module and the buffer interface
Feature Requests item #1190033, was opened at 2005-04-26 01:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: The array module and the buffer interface Initial Comment: It would be terribly convenient if array objects were willing to take any object supporting the buffer interface as initialization or extension via a.fromstring(). They currently offer the buffer interface for other objects to read/write once the array has been created, but they do not accept buffers during creation or extension (except for the typecode 'c'). -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 00:20 Message: Logged In: YES user_id=80475 Do you have a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1190033 ] The array module and the buffer interface
Feature Requests item #1190033, was opened at 2005-04-25 23:59 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: The array module and the buffer interface Initial Comment: It would be terribly convenient if array objects were willing to take any object supporting the buffer interface as initialization or extension via a.fromstring(). They currently offer the buffer interface for other objects to read/write once the array has been created, but they do not accept buffers during creation or extension (except for the typecode 'c'). -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-27 23:37 Message: Logged In: YES user_id=341410 Not right now, but I could probably have one for you tomorrow. You want doc updates and tests too? -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-27 22:20 Message: Logged In: YES user_id=80475 Do you have a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1190701 ] Add 'before' and 'after' methods to Strings
Feature Requests item #1190701, was opened at 2005-04-26 20:35
Message generated for change (Comment added) made by cxdunn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190701&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Dunn (cxdunn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 'before' and 'after' methods to Strings
Initial Comment:
GNU String used to have two very useful methods,
'before' and 'after'. These are so useful I keep them
defined in an __init__.py file. (Unfortunately, I do
not know how to make them methods, instead of global
functions.)
Usage:
>>> "root.sub".before(".")
'root'
>>> "root.sub1.sub2".after("root.sub1")
'.sub2'
They work like s.split(word)[0], and s.split(word)[-1],
but they are so intuitive they ought to be part of the
interface.
I'm not sure whether they should raise exceptions on
failure, or simply return the whole string.
-cxdunn
--
>Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 01:40
Message:
Logged In: YES
user_id=1267419
Your examples prove my point:
>>> s = "root.sub"
>>> t = "fubar"
>>> s[:s.find(t)]
'root.su'
>>> s = "root.sub1.sub2"
>>> t = "fubar"
>>> s[s.find(sep)+len(sep):]
'.sub1.sub2'
string.find() is the wrong way.
I can live with string.split():
>>> "root.sub1.sub2"
>>> t = '.'
>>> s.split(t)[0]
'root'
>>> s.split(t)[-1]
'sub2'
>>> t = "fubar"
>>> s.split(t)[0]
'root.sub1.sub2'
>>> s.split(t)[-1]
'root.sub1.sub2'
This is not terrible, but the desired behavior is really
more like strip/rstrip::
def before( s, first ):
"""Find first inside string s and return everything
before that.
>>> before('xyz.pdq.abc', '.')
'xyz'
>>> before('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(first)[0]
def after( s, first ):
"""Find first inside string s and return everything
after that.
>>> after('xyz.pdq.abc', '.')
'pdq.abc'
>>> after('xyz.pdq', 'xyz.')
'pdq'
>>> after('xyz.pdq.abc', 'fubar')
''
"""
return first.join(s.split(first)[1:])
def rbefore( s, last ):
"""Find last inside string s, from the right,
and return everything before that.
>>> rbefore('xyz.pdq.abc', '.')
'xyz.pdq'
>>> rbefore('xyz.pdq.abc', 'fubar')
''
"""
return last.join(s.split(last)[:-1])
def rafter( s, last ):
"""Find last inside string s, from the right
and return everything after that.
>>> rafter('xyz.pdq.abc', '.')
'abc'
>>> rafter('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(last)[-1]
It's a question of elegance. These are very useful,
infuitive functions, and I cannot add them to string myself.
And as you've seen, it's easy to create bugs when you try to
do this on the fly.
Reconsider? If not, I'll just post it in the Cookbook, to
point out the dangers of relying on string.find.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 00:15
Message:
Logged In: YES
user_id=80475
I'm -1 on expanding the string API for something so easily
coded with existing primitives:
>>> s = "root.sub"
>>> t = "."
>>> s[:s.find(t)]
'root'
>>> s = "root.sub1.sub2"
>>> t = "root.sub1"
>>> s[s.find(sep)+len(sep):]
'sub1.sub2'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190701&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1190701 ] Add 'before' and 'after' methods to Strings
Feature Requests item #1190701, was opened at 2005-04-26 20:35
Message generated for change (Comment added) made by cxdunn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190701&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Dunn (cxdunn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 'before' and 'after' methods to Strings
Initial Comment:
GNU String used to have two very useful methods,
'before' and 'after'. These are so useful I keep them
defined in an __init__.py file. (Unfortunately, I do
not know how to make them methods, instead of global
functions.)
Usage:
>>> "root.sub".before(".")
'root'
>>> "root.sub1.sub2".after("root.sub1")
'.sub2'
They work like s.split(word)[0], and s.split(word)[-1],
but they are so intuitive they ought to be part of the
interface.
I'm not sure whether they should raise exceptions on
failure, or simply return the whole string.
-cxdunn
--
>Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 01:50
Message:
Logged In: YES
user_id=1267419
Your examples prove my point::
>>> s = "Monty.Python"
>>> t = "fubar"
>>> s[:s.find(t)]
'Monty.Pytho'
>>> s[s.find(t)+len(t):]
'y.Python'
Of course, this would work:
>>> s.split(t)[0]
'Monty.Python'
>>> s.split(t)[-1]
'Monty.Python'
That is not terrible, but the behavior I want is actually
more like strip()/rstrip()::
def before( s, first ):
"""Find first inside string s and return everything
before that.
>>> before('xyz.pdq.abc', '.')
'xyz'
>>> before('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(first)[0]
def after( s, first ):
"""Find first inside string s and return everything
after that.
>>> after('xyz.pdq.abc', '.')
'pdq.abc'
>>> after('xyz.pdq', 'xyz.')
'pdq'
>>> after('xyz.pdq.abc', 'fubar')
''
"""
return first.join(s.split(first)[1:])
def rbefore( s, last ):
"""Find last inside string s, from the right,
and return everything before that.
>>> rbefore('xyz.pdq.abc', '.')
'xyz.pdq'
>>> rbefore('xyz.pdq.abc', 'fubar')
''
"""
return last.join(s.split(last)[:-1])
def rafter( s, last ):
"""Find last inside string s, from the right
and return everything after that.
>>> rafter('xyz.pdq.abc', '.')
'abc'
>>> rafter('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(last)[-1]
Besides, it's a question of elegance. These are very useful
little functions,
which look wonderful as methods of string, and the
on-the-fly solutions are
prone to error. Reconsider?
If not, I'll just post it to the Cookbook (without your name
-- I'm not trying
to embarrass anyone) to point out the danger of relying on
string.find().
-cxdunn
--
Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 01:40
Message:
Logged In: YES
user_id=1267419
Your examples prove my point:
>>> s = "root.sub"
>>> t = "fubar"
>>> s[:s.find(t)]
'root.su'
>>> s = "root.sub1.sub2"
>>> t = "fubar"
>>> s[s.find(sep)+len(sep):]
'.sub1.sub2'
string.find() is the wrong way.
I can live with string.split():
>>> "root.sub1.sub2"
>>> t = '.'
>>> s.split(t)[0]
'root'
>>> s.split(t)[-1]
'sub2'
>>> t = "fubar"
>>> s.split(t)[0]
'root.sub1.sub2'
>>> s.split(t)[-1]
'root.sub1.sub2'
This is not terrible, but the desired behavior is really
more like strip/rstrip::
def before( s, first ):
"""Find first inside string s and return everything
before that.
>>> before('xyz.pdq.abc', '.')
'xyz'
>>> before('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(first)[0]
def after( s, first ):
"""Find first inside string s and return everything
after that.
>>> after('xyz.pdq.abc', '.')
'pdq.abc'
>>> after('xyz.pdq', 'xyz.')
'pdq'
>>> after('xyz.pdq.abc', 'fubar')
''
"""
return first.join(s.split(first)[1:])
def rbefore( s, last ):
"""Find last inside string s, from the right,
and return everything before that.
>>> rbefore('xyz.pdq.abc', '.')
'xyz.pdq'
>>> rbefore('xyz.pdq.abc', 'fubar')
''
"""
return last.join(s.split(last)[:-1])
def rafter( s, last ):
"""Find last inside string s, from the right
and return everything after that.
>>> rafter('xyz.pdq.abc', '.')
'abc'
>>> rafter('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(last)[-1]
It's a question of elegance. These are very useful,
infuitive functions, and I cannot add them to string myself.
And as you've seen, it's easy to create bugs when you try to
do this on the fly.
Reconsider? If not, I'll just post it in the Cookbook, to
point out the dangers of relying on string.find.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-
[ python-Feature Requests-1190701 ] Add 'before' and 'after' methods to Strings
Feature Requests item #1190701, was opened at 2005-04-26 20:35
Message generated for change (Comment added) made by cxdunn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190701&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Dunn (cxdunn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 'before' and 'after' methods to Strings
Initial Comment:
GNU String used to have two very useful methods,
'before' and 'after'. These are so useful I keep them
defined in an __init__.py file. (Unfortunately, I do
not know how to make them methods, instead of global
functions.)
Usage:
>>> "root.sub".before(".")
'root'
>>> "root.sub1.sub2".after("root.sub1")
'.sub2'
They work like s.split(word)[0], and s.split(word)[-1],
but they are so intuitive they ought to be part of the
interface.
I'm not sure whether they should raise exceptions on
failure, or simply return the whole string.
-cxdunn
--
>Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 01:54
Message:
Logged In: YES
user_id=1267419
Sorry for the double-post. I thought I'd lost it and
re-typed the whole thing. Read the top one only -- less buggy.
--
Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 01:50
Message:
Logged In: YES
user_id=1267419
Your examples prove my point::
>>> s = "Monty.Python"
>>> t = "fubar"
>>> s[:s.find(t)]
'Monty.Pytho'
>>> s[s.find(t)+len(t):]
'y.Python'
Of course, this would work:
>>> s.split(t)[0]
'Monty.Python'
>>> s.split(t)[-1]
'Monty.Python'
That is not terrible, but the behavior I want is actually
more like strip()/rstrip()::
def before( s, first ):
"""Find first inside string s and return everything
before that.
>>> before('xyz.pdq.abc', '.')
'xyz'
>>> before('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(first)[0]
def after( s, first ):
"""Find first inside string s and return everything
after that.
>>> after('xyz.pdq.abc', '.')
'pdq.abc'
>>> after('xyz.pdq', 'xyz.')
'pdq'
>>> after('xyz.pdq.abc', 'fubar')
''
"""
return first.join(s.split(first)[1:])
def rbefore( s, last ):
"""Find last inside string s, from the right,
and return everything before that.
>>> rbefore('xyz.pdq.abc', '.')
'xyz.pdq'
>>> rbefore('xyz.pdq.abc', 'fubar')
''
"""
return last.join(s.split(last)[:-1])
def rafter( s, last ):
"""Find last inside string s, from the right
and return everything after that.
>>> rafter('xyz.pdq.abc', '.')
'abc'
>>> rafter('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(last)[-1]
Besides, it's a question of elegance. These are very useful
little functions,
which look wonderful as methods of string, and the
on-the-fly solutions are
prone to error. Reconsider?
If not, I'll just post it to the Cookbook (without your name
-- I'm not trying
to embarrass anyone) to point out the danger of relying on
string.find().
-cxdunn
--
Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 01:40
Message:
Logged In: YES
user_id=1267419
Your examples prove my point:
>>> s = "root.sub"
>>> t = "fubar"
>>> s[:s.find(t)]
'root.su'
>>> s = "root.sub1.sub2"
>>> t = "fubar"
>>> s[s.find(sep)+len(sep):]
'.sub1.sub2'
string.find() is the wrong way.
I can live with string.split():
>>> "root.sub1.sub2"
>>> t = '.'
>>> s.split(t)[0]
'root'
>>> s.split(t)[-1]
'sub2'
>>> t = "fubar"
>>> s.split(t)[0]
'root.sub1.sub2'
>>> s.split(t)[-1]
'root.sub1.sub2'
This is not terrible, but the desired behavior is really
more like strip/rstrip::
def before( s, first ):
"""Find first inside string s and return everything
before that.
>>> before('xyz.pdq.abc', '.')
'xyz'
>>> before('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(first)[0]
def after( s, first ):
"""Find first inside string s and return everything
after that.
>>> after('xyz.pdq.abc', '.')
'pdq.abc'
>>> after('xyz.pdq', 'xyz.')
'pdq'
>>> after('xyz.pdq.abc', 'fubar')
''
"""
return first.join(s.split(first)[1:])
def rbefore( s, last ):
"""Find last inside string s, from the right,
and return everything before that.
>>> rbefore('xyz.pdq.abc', '.')
'xyz.pdq'
>>> rbefore('xyz.pdq.abc', 'fubar')
''
"""
return last.join(s.split(last)[:-1])
def rafter( s, last ):
"""Find last inside string s, from the right
and return everything after that.
>>> rafter('xyz.pdq.abc', '.')
'abc'
>>> rafter('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(last)[-1]
It's a question of elegance. These are very useful,
infuitive functions, and I cannot add them to string myself.
And as you've seen, it's
[ python-Feature Requests-1190701 ] Add 'before' and 'after' methods to Strings
Feature Requests item #1190701, was opened at 2005-04-26 20:35
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190701&group_id=5470
Category: Python Library
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Christopher Dunn (cxdunn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 'before' and 'after' methods to Strings
Initial Comment:
GNU String used to have two very useful methods,
'before' and 'after'. These are so useful I keep them
defined in an __init__.py file. (Unfortunately, I do
not know how to make them methods, instead of global
functions.)
Usage:
>>> "root.sub".before(".")
'root'
>>> "root.sub1.sub2".after("root.sub1")
'.sub2'
They work like s.split(word)[0], and s.split(word)[-1],
but they are so intuitive they ought to be part of the
interface.
I'm not sure whether they should raise exceptions on
failure, or simply return the whole string.
-cxdunn
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 01:58
Message:
Logged In: YES
user_id=80475
You read too much into a simplified example. Test the
find() result for -1 and be done with it. Go ahead with a
cookbook recipe if you think that no one else is bright
enough to write their own.
--
Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 01:54
Message:
Logged In: YES
user_id=1267419
Sorry for the double-post. I thought I'd lost it and
re-typed the whole thing. Read the top one only -- less buggy.
--
Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 01:50
Message:
Logged In: YES
user_id=1267419
Your examples prove my point::
>>> s = "Monty.Python"
>>> t = "fubar"
>>> s[:s.find(t)]
'Monty.Pytho'
>>> s[s.find(t)+len(t):]
'y.Python'
Of course, this would work:
>>> s.split(t)[0]
'Monty.Python'
>>> s.split(t)[-1]
'Monty.Python'
That is not terrible, but the behavior I want is actually
more like strip()/rstrip()::
def before( s, first ):
"""Find first inside string s and return everything
before that.
>>> before('xyz.pdq.abc', '.')
'xyz'
>>> before('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(first)[0]
def after( s, first ):
"""Find first inside string s and return everything
after that.
>>> after('xyz.pdq.abc', '.')
'pdq.abc'
>>> after('xyz.pdq', 'xyz.')
'pdq'
>>> after('xyz.pdq.abc', 'fubar')
''
"""
return first.join(s.split(first)[1:])
def rbefore( s, last ):
"""Find last inside string s, from the right,
and return everything before that.
>>> rbefore('xyz.pdq.abc', '.')
'xyz.pdq'
>>> rbefore('xyz.pdq.abc', 'fubar')
''
"""
return last.join(s.split(last)[:-1])
def rafter( s, last ):
"""Find last inside string s, from the right
and return everything after that.
>>> rafter('xyz.pdq.abc', '.')
'abc'
>>> rafter('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(last)[-1]
Besides, it's a question of elegance. These are very useful
little functions,
which look wonderful as methods of string, and the
on-the-fly solutions are
prone to error. Reconsider?
If not, I'll just post it to the Cookbook (without your name
-- I'm not trying
to embarrass anyone) to point out the danger of relying on
string.find().
-cxdunn
--
Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 01:40
Message:
Logged In: YES
user_id=1267419
Your examples prove my point:
>>> s = "root.sub"
>>> t = "fubar"
>>> s[:s.find(t)]
'root.su'
>>> s = "root.sub1.sub2"
>>> t = "fubar"
>>> s[s.find(sep)+len(sep):]
'.sub1.sub2'
string.find() is the wrong way.
I can live with string.split():
>>> "root.sub1.sub2"
>>> t = '.'
>>> s.split(t)[0]
'root'
>>> s.split(t)[-1]
'sub2'
>>> t = "fubar"
>>> s.split(t)[0]
'root.sub1.sub2'
>>> s.split(t)[-1]
'root.sub1.sub2'
This is not terrible, but the desired behavior is really
more like strip/rstrip::
def before( s, first ):
"""Find first inside string s and return everything
before that.
>>> before('xyz.pdq.abc', '.')
'xyz'
>>> before('xyz.pdq.abc', 'fubar')
'xyz.pdq.abc'
"""
return s.split(first)[0]
def after( s, first ):
"""Find first inside string s and return everything
after that.
>>> after('xyz.pdq.abc', '.')
'pdq.abc'
>>> after('xyz.pdq', 'xyz.')
'pdq'
>>> after('xyz.pdq.abc', 'fubar')
''
"""
return first.join(s.split(first)[1:])
def rbefore( s, last ):
"""Find last inside string s, from the right,
and return everything before that.
>>> rbefore('xyz.pdq.abc', '.')
'xyz.pdq'
>>> rbefore('xyz.pdq.abc', 'fubar')
''
"""
return last.join(s.split(last)[:
[ python-Bugs-1190596 ] calendar._firstweekday is too hard-wired
Bugs item #1190596, was opened at 2005-04-26 17:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190596&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: calendar._firstweekday is too hard-wired Initial Comment: Long-running applications which need to make use of the 'calendar' module may need to present calendars to different users using the users' preferred settings. Currently, the two functions which rely on the locale-specific setting are too inflexible: they assume that the module-level global should always govern. The attached patch adds defaulted arguments to these functions, and uses the module-level global only where the caller does not pass in a value. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 01:59 Message: Logged In: YES user_id=80475 The attachment didn't make it. Please try again and make sure to check-off the upload box. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190596&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
