Mailman 3 February 2005 - Python-Dev

[Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39
by Tim Peters Feb. 10, 2005

Feb. 10, 2005

[fdrake(a)users.sourceforge.net] > Modified Files: > xmlrpclib.py > Log Message: > accept datetime.datetime instances when marshalling; > dateTime.iso8601 elements still unmarshal into xmlrpclib.DateTime objects > > Index: xmlrpclib.py ... > + if datetime and isinstance(value, datetime.datetime): > + self.value = value.strftime("%Y%m%dT%H:%M:%S") > + return ... [and similarly later] ... Fred, is there a reason to avoid datetime.datetime's .isoformat() method here? Like so: >>> import datetime >>> print datetime.datetime(2005, 2, 10, 14, 0, 8).isoformat() 2005-02-10T14:00:08 A possible downside is that you'll also get fractional seconds if the instance records a non-zero .microseconds value.

3 6

Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
by BJörn Lindqvist Feb. 10, 2005

Feb. 10, 2005

I'd like to help develop Python for fun and profit and I've heard that posting patch reviews to python-dev is a good way to contribute. So here goes: PATCH REVIEW: [ 1098732 ] Skip Montanaro has written a patch which makes it so that you can inspect variable values in tracebacks. IMHO, it is a brilliant idea and can make debugging quite alot easier. However, I'm not so fond of the way that he has implemented it, it needs work. He basically outputs all names in all stackframes all the way up to the top which makes the traceback look way to cluttered. He has also implemented it as a hook to sys.excepthook, I would ike it to be the default way in which tracebacks are printed, or atleast ctivated by a command line switch to Python. What does everyone else think? Does Skip's idea have any merit? http://sourceforge.net/tracker/index.php?func=detail&aid=1098732&group_id=5… -- mvh Björn

10 15

Patches for cookielib bugs, for 2.4.1
by John J Lee Feb. 10, 2005

Feb. 10, 2005

Hope these can get in before 2.4.1. All include unit tests. http://python.org/sf/1117339 cookielib and cookies with special names http://python.org/sf/1117454 cookielib.LWPCookieJar incorrectly loads value-less cookies http://python.org/sf/1117398 cookielib LWPCookieJar and MozillaCookieJar exceptions John

1 0

Clarification sought about including a multidimensional array object into Python core
by Travis Oliphant Feb. 10, 2005

Feb. 10, 2005

There has recently been some much-needed discussion on the numpy-discussions list run by sourceforge regarding the state of the multidimensional array objects available for Python. It is desired by many that there be a single multidimensional array object in the Python core to facilitate data transfer and interfacing between multiple packages. I am a co-author of the current PEP regarding inclusion of the multidimensional array object into the core. However, that PEP is sorely outdated. Currently there are two multidimensional array objects that are in use in the Python community: Numeric --- original arrayobject created by Jim Hugunin and many others. Has been developed and used for 10 years. An upgrade that adds the features of numarray but maintains the same basic structure of Numeric called Numeric3 is in development and will be ready for more wide-spread use in a couple of weeks. Numarray --- in development for about 3 years. It was billed by some as a replacement for Numeric,. While introducing some new features, it still has not covered the full feature set that Numeric had making it impossible for all Numeric users to use it. In addition, it is still unacceptably slow for many operations that Numeric does well. Scientific users will always have to install more packages in order to use Python for their purposes. However, there is still the desire that the basic array object would be common among all Python users. To assist in writing a new PEP, we need clarification from Guido and others involved regarding 1) What specifically about Numeric prevented it from being acceptable as an addition to the Python core. 2) Are there any fixed requirements (other than coding style) before an arrayobject would be accepted into the Python core. Thanks for your comments. I think they will help the discussion currently taking place. -Travis Oliphant

8 17

[Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.340, 2.341
by Michael Hudson Feb. 9, 2005

Feb. 9, 2005

rhettinger(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Python > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26507/Python > > Modified Files: > compile.c > Log Message: > Transform "x in (1,2,3)" to "x in frozenset([1,2,3])". > > Inspired by Skip's idea to recognize the throw-away nature of sequences > in this context and to transform their type to one with better performance. This breaks code: >>> [] in (1,) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: list objects are unhashable (and so breaks test_email -- is noone else running the test suite?). It's a cute idea, but IMHO violates the principle of least surprise too much. Cheers, mwh -- ZAPHOD: Who are you? ROOSTA: A friend. ZAPHOD: Oh yeah? Anyone's friend in particular, or just generally well-disposed to people? -- HHGttG, Episode 7

1 0

update copyright date in PC/python_nt.rc?
by Trent Mick Feb. 9, 2005

Feb. 9, 2005

Howdy, The copyright date was updated to 2005 in Python/getcopyright.c. Should the same be done in PC/python_nt.rc? Or perhaps, is there any reason python_nt.rc should NOT be updated? Cheers, Trent -- Trent Mick trentm(a)activestate.com

2 2

RELEASED Python 2.3.5, final
by Anthony Baxter Feb. 9, 2005

Feb. 9, 2005

On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.3.5 (final). Python 2.3.5 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs squished in this release. Python 2.3.5 contains an important security fix for SimpleXMLRPCServer - for more, see the announcement of PSF-2005-001 at: http://www.python.org/security/PSF-2005-001/ Python 2.3.5 is the last planned release in the Python 2.3 series, and is being released for those people who still need to run Python 2.3. Python 2.4 is a newer release, and should be preferred if possible. From here, bugfix releases are switching to the Python 2.4 branch - 2.4.1 will be the next Python release. For more information on Python 2.3.5, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.3.5 Highlights of this new release include: - Bug fixes. According to the release notes, more than 50 bugs have been fixed, including a couple of bugs that could cause Python to crash. Highlights of the previous major Python release (2.3) are available from the Python 2.3 page, at http://www.python.org/2.3/highlights.html Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

1 0

2.3.5 and 2.4.1 release plans
by Anthony Baxter Feb. 8, 2005

Feb. 8, 2005

Ok, so here's the state of play: 2.3.5 is currently aimed for next Tuesday, but there's an outstanding issue - the new copy code appears to have broken something, see www.python.org/sf/1114776 for the gory details. I'm completely out of time this weekend to look into it too closely - if someone has 1/2 an hour and wants to do some triage on the bug, I'd appreciate it, a great deal. I'm currently thinking about a 2.4.1 around the 23td of Feb - Martin and Fred, does this work for you? There's a bunch of backporting that should probably happen for that - I will try to get some time to do this in the next week or so. -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

4 4

Re: python/dist/src/Lib rfc822.py,1.78,1.79
by Fredrik Lundh Feb. 8, 2005

Feb. 8, 2005

rhettinger(a)users.sourceforge.net wrote: > @@ -399,9 +393,8 @@ > del self[name] # Won't fail if it doesn't exist > self.dict[name.lower()] = value > text = name + ": " + value > - lines = text.split("\n") > - for line in lines: > - self.headers.append(line + "\n") > + self.headers.extend(text.splitlines(True)) > + self.headers.append('\n') and you're 100% sure that the change in how things are stored in headers won't affect any existing code? (the docstring says that headers contain a list of lines, which is no longer true) </F>

3 3

test_codecs failing
by Raymond Hettinger Feb. 8, 2005

Feb. 8, 2005

The most recent test_codecs check-in (1.19) is failing on a MSCV6.0 compilation running on WinMe: ---------------------------------------------------------------------- Ran 35 tests in 1.430s FAILED (failures=1) Traceback (most recent call last): File "\py25\lib\test\test_codecs.py", line 786, in ? test_main() File "\py25\lib\test\test_codecs.py", line 781, in test_main BasicStrTest File "C:\PY25\lib\test\test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "C:\PY25\lib\test\test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "\py25\lib\test\test_codecs.py", line 165, in test_badbom self.assertRaises(UnicodeError, f.read) AssertionError: UnicodeError not raised C:\pydev>python Python 2.5a0 (#46, Feb 7 2005, 21:37:18) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. Raymond

3 2