Re: [Python-Dev] LZW support in tarfile ?
Michael Foord wrote: > Antoine Pitrou wrote: > > Tarek Ziadé gmail.com> writes: > > > >> But I was wondering if we should we add a LZW support in tarinfo, > >> besides gzip and bzip2 ? > >> > >> Although this compression standard doesn't seem very used these days, > >> > > > > It would be more useful to add LZMA / xz support. > > I don't think compress is used anymore, except perhaps on old legacy > > systems. > > On my Linux system, I have lots of .gz, .bz2 and .lzma files, but > > absolutely no > > .Z file. > > I've seen the occasional .Z file in recent years, but never that I > recall for a Python package. On my unix filesystem (which has files stretching back over 20 years) I find only two .Z files, one dated 1989 and one 2002. I think you can safely say that compress is gone! The worst you are doing by removing compress support is getting the user of some ancient platform to download one of the binaries here first. http://www.gzip.org/#exe > As plugging in external compression tools is less likely to work > cross-platform wouldn't it be both easier and better to deprecate (and > not replace) the compress support. Agreed. -- Nick Craig-Wood -- http://www.craig-wood.com/nick ___ 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] LZW support in tarfile ?
Ok thanks for all the feedback, I'll remove compress support Tarek On Mon, May 18, 2009 at 10:06 AM, Nick Craig-Wood wrote: > Michael Foord wrote: >> Antoine Pitrou wrote: >> > Tarek Ziadé gmail.com> writes: >> > >> >> But I was wondering if we should we add a LZW support in tarinfo, >> >> besides gzip and bzip2 ? >> >> >> >> Although this compression standard doesn't seem very used these days, >> >> >> > >> > It would be more useful to add LZMA / xz support. >> > I don't think compress is used anymore, except perhaps on old legacy >> > systems. >> > On my Linux system, I have lots of .gz, .bz2 and .lzma files, but >> > absolutely no >> > .Z file. >> >> I've seen the occasional .Z file in recent years, but never that I >> recall for a Python package. > > On my unix filesystem (which has files stretching back over 20 years) > I find only two .Z files, one dated 1989 and one 2002. I think you > can safely say that compress is gone! > > The worst you are doing by removing compress support is getting the > user of some ancient platform to download one of the binaries here > first. > > http://www.gzip.org/#exe > >> As plugging in external compression tools is less likely to work >> cross-platform wouldn't it be both easier and better to deprecate (and >> not replace) the compress support. > > Agreed. > > -- > Nick Craig-Wood -- http://www.craig-wood.com/nick > ___ > 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/ziade.tarek%40gmail.com > -- Tarek Ziadé | http://ziade.org ___ 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] PEP 384: Defining a Stable ABI
Martin v. Löwis wrote: It also might make it easier for alternate implementations to support the same API so some modules could work cross implementation - but I suspect that's a non-goal of this PEP :). Indeed :-) I'm also skeptical that this would actually allow cross-implementation modules to happen. The list of functions that an alternate implementation would have to provide is fairly long. Just in case you're unaware of it; the company I work for has an open source project called Ironclad. I was unaware indeed; thanks for pointing this out. IIUC, it's not just an API emulation, but also an ABI emulation. Correct. In particular we have had to address the issue of the GIL and extensions (IronPython has no GIL) and reference counting (which IronPython also doesn't) use. I think this somewhat strengthens the point I was trying to make: An alternate implementation that tries to be API compatible has to consider so many things that it is questionable whether making Py_INCREF/DECREF functions would be any simplification. It would actually have been helpful for us, but I understand that it would be a big performance hit. The Ironclad garbage collection mechanism is described here: http://www.voidspace.org.uk/python/weblog/arch_d7_2009_01_24.shtml#e1055 We artificially inflate the refcount of all objects that Ironclad creates to 2 and hold a reference to them on the .NET side to make them ineligible for garbage collection. Because we can't always know when objects have been decreffed back down to 1, there are some circumstances when we have to scan all the objects we are holding onto. If their refcount is only 1 then we no longer need to hold a reference them. When nothing is using them on the IronPython side either normal .NET garbage collection kicks in and the IronPython proxy object has a destructor that calls back into Ironclad and uses the CPython dealloc method. So I just ask: a) Would it help IronClad if it could restrict itself to PEP 384 compatible modules? b) Would further restrictions in the PEP help that cause? I've forwarded these questions to the lead developer of Ironclad (William Reade) along with a link to the PEP. He isn't on Python-dev so I may have to be a proxy for him in discussion. His initial response was "looks pretty sweet". Michael Regards, Martin -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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
