Re: [Python-Dev] test_codecs failing
Walter Dörwald wrote: Raymond Hettinger wrote: 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): [...] 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 Fixed. But the question remains: Why does a StreamWriter have a read() method? It inherits that method from the underlying stream - just as all other methods and attributes that the stream defines and which are not overridden by the StreamWriter methods. This approach was taken to make it possible to user StreamWriter (and StreamReader) instance as drop-in replacement in situations where the application normally expects a file-like object. Note that a file opened in write mode also exposes a read() method. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 08 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org 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/dist/src/Lib rfc822.py,1.78,1.79
@@ -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)
and the module documentation says:
Each line contains a trailing newline. The blank line terminating
the headers is not contained in the list.
which is no longer true (unless I'm missing something here)
/F
___
Python-Dev mailing list
Python-Dev@python.org
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: python/dist/src/Lib rfc822.py,1.78,1.79
On Tue, 8 Feb 2005 10:10:49 +0100, Fredrik Lundh [EMAIL PROTECTED] 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)
and the module documentation says:
Each line contains a trailing newline. The blank line terminating
the headers is not contained in the list.
which is no longer true (unless I'm missing something here)
This would have been caught if there was a unit test validating what
the documentation says. Why aren't there unit tests for this code? I
think we need to raise the bar for wholistic improvements to a
module: first write a unit test if there isn't already one (and if
there is one, make sure that it tests all documented behavior), *then*
refactor. Yes, this would be less fun. It's not supposed to be fun.
It's supposed to avoid breaking code.
Raymond, please roll back that change until this is taken care of.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
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: python/dist/src/Lib rfc822.py,1.78,1.79
On Tue, 2005-02-08 at 10:35, Guido van Rossum wrote: This would have been caught if there was a unit test validating what the documentation says. Why aren't there unit tests for this code? I think we need to raise the bar for wholistic improvements to a module: first write a unit test if there isn't already one (and if there is one, make sure that it tests all documented behavior), *then* refactor. Yes, this would be less fun. It's not supposed to be fun. It's supposed to avoid breaking code. +1. This module is used in so many place, you really have to take the documented interface seriously (not that you shouldn't otherwise, of course). I suspect even the undocumented current semantics are relied on in many place. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
Maybe some ambitious PSF activitst could contact Roskind and Steve Kirsch and see if they know who at Disney to talk to... Or maybe the Disney guys who were at PyCon last year could help. Jeremy On Tue, 8 Feb 2005 15:37:50 -0500, Tim Peters [EMAIL PROTECTED] wrote: [Matthias Klose] A Debian user pointed out (http://bugs.debian.org/293932), that the current license for the Python profiler is not conforming to the DFSG (Debian free software guidelines). http://www.python.org/doc/current/lib/node829.html states This permission is explicitly restricted to the copying and modification of the software to remain in Python, compiled Python, or other languages (such as C) wherein the modified or derived code is exclusively imported into a Python module. ... - Does somebody knows about the history of this license, why it is more restricted than the Python license? Simply because that's the license Jim Roskind slapped on it when he contributed this code 10 years ago. I imagine (but don't know) that Guido looked at it, thought hmm -- shouldn't be a problem for Python's users, and so accepted it. - Is there a chance to change the license for these two modules (profile.py, pstats.py)? Not unless some remnant of InfoSeek Corp can be found, since they're the copyright holder (their work, their license). Alas, Jim Roskind hasn't been seen in the Python world this century. OTOH, if InfoSeek has vanished, it's unlikely they'll be suing anyone. Given how Python-specific profile.py and pstats.py are, it's hard for me to imagine anyone wanting to make a derivative that isn't imported into a Python module. In that respect it seems like a license clause that forbids you to run the software while the tip of your tongue is licking the back of your own neck. Still, if that matters, perhaps Debian will need to leave these modules out. Bold ahem users will still be able to grab them from any number of other places. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.5 and 2.4.1 release plans
Anthony Baxter wrote: I'm currently thinking about a 2.4.1 around the 23td of Feb - Martin and Fred, does this work for you? Yes. I will need to test whether my replacement of VB scripts in the installer with native DLLs works even on W95; I'm confident to complete this next week (already have the W95 machine installed). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.3.5, final
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 [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgppflY2beoBL.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
