[Python-Dev] issue 8832: Add a context manager to dom.minidom
I haven't had any comment on this patch, are there any objections? http://bugs.python.org/issue8832 K ___ 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] issue 8832: Add a context manager to dom.minidom
On 09/06/10 05:58, Kristján Valur Jónsson wrote: I haven‘t had any comment on this patch, are there any objections? http://bugs.python.org/issue8832 Sounds good to me. One of the nice things about the context management protocol is that it doesn't interfere with any code that isn't explicitly written to take advantage of it. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Reintroduce or drop completly hex, bz2, rot13, ... codecs
There are two opposite issues in the bug tracker:
#7475: codecs missing: base64 bz2 hex zlib ...
-> reintroduce the codecs removed from Python3
#8838: Remove codecs.readbuffer_encode()
-> remove the last part of the removed codecs
If I understood correctly, the question is: should codecs module only contain
encoding codecs, or contain also other kind of codecs.
Encoding codec API is now strict (encode: str->bytes, decode: bytes->str),
it's not possible to reuse str.encode() or bytes.decode() for the other
codecs. Marc-Andre Lemburg proposed to add .tranform() and .untranform()
methods to str, bytes and bytearray types. If I understood correctly, it would
look like:
>>> b'abc'.transform("hex")
'616263'
>>> '616263'.untranform("hex")
b'abc'
I suppose that each codec will have a different list of accepted input and
output types. Example:
bz2: encode:bytes->bytes, decode:bytes->bytes
rot13: encode:str->str, decode:str->str
hex: encode:bytes->str, decode: str->bytes
And so "abc".encode("bz2") would raise a TypeError.
--
In my opinion, we should not mix codecs of different kinds (compression,
cipher, etc.) because the input and output types are different. It would have
more sense to create a standard API for each kind of codec. Existing examples
of standard APIs in Python: hashlib, shutil.make_archive(), database API, etc.
--
Victor Stinner
http://www.haypocalc.com/
___
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] Future of 2.x.
Is there is any plan for a 2.8 release? If not, I will go through the tracker and close outstanding backport requests of 3.x features to 2.x. -- Alexandre ___ 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] Future of 2.x.
2010/6/8 Alexandre Vassalotti : > Is there is any plan for a 2.8 release? If not, I will go through the > tracker and close outstanding backport requests of 3.x features to > 2.x. Not from the core development team. -- Regards, Benjamin ___ 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] Future of 2.x.
On Wed, Jun 9, 2010 at 9:28 AM, Alexandre Vassalotti wrote: > Is there is any plan for a 2.8 release? If not, I will go through the > tracker and close outstanding backport requests of 3.x features to You mean, simply mark them as Wont-Fix and close. I doubt, if this is desirable action to take. Even thought they are new features, it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. This is just my opinion. -- Senthil ___ 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] Future of 2.x.
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran wrote: > it would still be a good idea to > introduce some of them in minor releases in 2.7. I know, this > deviating from the process, but it could be an option considering that > 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] Future of 2.x.
On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote: > On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran wrote: > > it would still be a good idea to > > introduce some of them in minor releases in 2.7. I know, this > > deviating from the process, but it could be an option considering that > > 2.7 is the last of 2.x release. > > I disagree. > > If there are going to be features going into *any* post 2.7.0 version, > there's no reason not to increment the revision number to 2.8, > > Since there's also a well-advertised decision that 2.7 will be the > last 2.x, such a 2.8 isn't planned. But there's no reason to violate > the no-features-in-bugfix-releases policy. We've seen violations > cause trouble and confusion, but we've not seen it be successful. > > The policy wasn't arbitrary; let's stick to it. It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Rationale: it's almost certain that if the existing Python core maintainers won't evolve Python 2.X past 2.7, some other group will, and losing existing context for that would kinda suck. - C ___ 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
