[issue4015] [patch] make installed scripts executable on windows
Per added the comment: On POSIX the interpreter will be read from the first line of a file. On Windows the interpreter will be read from the Registry HKEY_CLASSES_ROOT\. . So the correct way to associate a interpreter to a file is to invent a file-extension for every interpreter. Like /usr/bin/python /usr/bin/python3 and /usr/bin/python3.1 on POSIX, there should be .py .py3 and .py31 on Windows! I attached a example-registry-patch to register extensions for 2.5, 2.6 and 3.1 . If you want to use it, you need to adjust the paths! I propose to change all Python-Windows-installer to install versioned extensions. If you want a switcher application, it should read the first line of the script and match it against ".*/python(.*)$". So the default POSIX "#!/usr/bin/python3.1" can be kept unchanged. With that rexex the app-path can be read from "HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\\InstallPath\". BTW. It would be nice if Python would call itself "Python 3.1" instead of "python" in the "Open with..."-list! The current naming is problematic if you install more than one Python version. -- nosy: +phobie Added file: http://bugs.python.org/file17481/hklm_python_extensions.reg ___ Python tracker <http://bugs.python.org/issue4015> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12013] file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found
Per Rosengren added the comment: On Linux: >nm -C /lib/libc.so.6 |grep ' inet_aton' 000cbce0 W inet_aton This means that when Python is build with GCC (like on linux), inet_aton is in system libc. If you build with GCC in solaris, inet_aton will be taken from the GCC lib dir. You need to put that GCC lib dir in your LD_LIBRARY_PATH when you run Python. -- nosy: +Per.Rosengren ___ Python tracker <http://bugs.python.org/issue12013> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Changes by Per Cederqvist : -- nosy: +ceder ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3810] os.chdir() et al: is the path str or bytes?
New submission from Per Cederqvist <[EMAIL PROTECTED]>: The documentation at http://docs.python.org/dev/3.0/library/os.html#os.chdir doesn't specify if the path argument to os.chdir() should be a str or a bytes, or if maybe both are acceptable. This is true for most of the file-manipulating functions in the os module. os.listdir() talks about Unicode objects. It should probably talk about bytes and str instead. -- assignee: georg.brandl components: Documentation messages: 72820 nosy: ceder, georg.brandl severity: normal status: open title: os.chdir() et al: is the path str or bytes? versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3810> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2315] TimedRotatingFileHandler does not account for daylight savings time
New submission from Per Cederqvist <[EMAIL PROTECTED]>: If TimedRotatingFileHandler is instructed to roll over the log at midnight or on a certain weekday, it needs to consider when daylight savings time starts and ends. The current code just blindly adds self.interval to self.rolloverAt, totally ignoring that sometimes it should add 23 or 25 hours instead of 24 hours. (I suspect that the implementation would be simpler if you use the datetime module, rather than attempt to patch the existing code.) -- components: Library (Lib) messages: 63622 nosy: ceder severity: normal status: open title: TimedRotatingFileHandler does not account for daylight savings time type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2315> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2316] TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval
New submission from Per Cederqvist <[EMAIL PROTECTED]>: If nothing is logged during an interval, the TimedRotatingFileHandler will give bad names to future log files. The enclosed example program sets up a logger that rotates the log every second. It then logs a few messages with sleep of 1, 2, 4, 1 and 1 seconds between the messages. The log files will have names that increase with one second per log file, but the content for the last file will be generated a different second. An example run produced the message 2008-03-17 09:16:06: 1 sec later in a log file named badlogdir/logfile.2008-03-17_09-16-02. This problem was likely introduced in revision 42066. The root cause is that self.rolloverAt is increased by self.interval in doRollover - but if nothing was logged for a while, it should be increased by a multiple of self.interval. -- messages: 63624 nosy: ceder severity: normal status: open title: TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2316> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2316] TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval
Per Cederqvist <[EMAIL PROTECTED]> added the comment: The attached program will generate log messages with a timestamp that are logged into a file with an unexpected extension. To run: mkdir badlogdir python badlogger.py Running the program takes about 9 seconds. Added file: http://bugs.python.org/file9687/badlogger.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2316> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2316] TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval
Changes by Per Cederqvist <[EMAIL PROTECTED]>: -- components: +Library (Lib) type: -> behavior versions: +Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2316> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2317] TimedRotatingFileHandler logic for removing files wrong
New submission from Per Cederqvist <[EMAIL PROTECTED]>: There are three issues with log file removal in the TimedRotatingFileHandler class: - Removal will stop working in the year 2100, as the code assumes that timestamps start with ".20". - If you run an application with backupCount set to a high number, and then restarts it with a lower number, the code will still not remove as many log files as you expect. It will never remove more than one file when it rotates the log. - It assumes that no other files matches baseFilename + ".20*", so make sure that you don't log to both "log" and "log.20th.century.fox" in the same directory! Suggested fix: use os.listdir() instead of glob.glob(), filter all file names using a proper regexp, sort the result, and use a while loop to remove files until the result is small enough. To reduce the risk of accidentally removing an unrelated file, the filter regexp should be based on the logging interval, just as the filename is. My suggested fix means that old files may not be removed if you change the interval. I think that is an acceptable behavior, but it should probably be documented to avoid future bug reports on this subject. :-) -- components: Library (Lib) messages: 63626 nosy: ceder severity: normal status: open title: TimedRotatingFileHandler logic for removing files wrong type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2317> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2318] TimedRotatingFileHandler: rotate every month, or every year
New submission from Per Cederqvist <[EMAIL PROTECTED]>: In my curent project, I would like to rotate log files on the 1st of every month. The TimedRotatingFileHandler class cannot do this, even though it tries to be very generic. I imagine that other projects would like to rotate the log file every year. That can also not be done. -- components: Library (Lib) messages: 63627 nosy: ceder severity: normal status: open title: TimedRotatingFileHandler: rotate every month, or every year type: feature request __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2318> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14507] Segfault with starmap and izip combo
New submission from Per Myren : The following code crashes with a segfault on Python 2.7.2: from operator import add from itertools import izip, starmap a = b = [1] for i in xrange(10): a = starmap(add, izip(a, b)) list(a) It also crashes with Python 3.2.2: from operator import add from itertools import starmap a = b = [1] for i in range(10): a = starmap(add, zip(a, b)) list(a) -- components: Library (Lib) messages: 157576 nosy: progrper priority: normal severity: normal status: open title: Segfault with starmap and izip combo type: crash versions: Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue14507> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25144] 3.5 Win install fails with "TARGETDIR"
Per Fryking added the comment: Got the same issue with the 3.6 installer from python.org The thing is that I can't elevate the priviliges to be administrator. So I'm stuck. Uploading the log. Running windows 7 -- nosy: +Per Fryking Added file: https://bugs.python.org/file47278/Python 3.6.3 (32-bit)_20171120135800.log ___ Python tracker <https://bugs.python.org/issue25144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34870] Core dump when Python VSCode debugger is attached
New submission from Per Lundberg :
My code has recently started triggering a core dump in the Python executable
when the VSCode debugger is attached. This doesn't happen right away; it seems
to happen more or less _after_ the program is done executing (I just placed a
breakpoint and stepped it through).
The program in question is this:
https://github.com/hiboxsystems/trac-to-gitlab/blob/master/migrate.py
To help in the debugging of this, I installed python2.7-dbg and gdb-python2 on
my Debian machine, and re-ran the script using this version. Here is the GDB
output when analyzing the backtrace:
$ gdb /usr/bin/python2.7-dbg core
GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python2.7-dbg...done.
[New LWP 19749]
[New LWP 19744]
[New LWP 19747]
[New LWP 19754]
[New LWP 19751]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/python2.7-dbg -m ptvsd --host localhost --port
43959 migrate.py --only'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 PyEval_EvalFrameEx (f=0x7f815c002310, throwflag=0) at ../Python/ceval.c:3347
3347if (tstate->frame->f_exc_type != NULL)
[Current thread is 1 (Thread 0x7f815bfff700 (LWP 19749))]
The python backtrace looks like this:
(gdb) py-bt
Traceback (most recent call first):
File "/usr/lib/python2.7/threading.py", line 371, in wait
self._acquire_restore(saved_state)
File "/usr/lib/python2.7/Queue.py", line 177, in get
self.not_empty.wait(remaining)
File
"/home/per/.vscode/extensions/ms-python.python-2018.8.0/pythonFiles/experimental/ptvsd/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py",
line 458, in _on_run
cmd = self.cmdQueue.get(1, 0.1)
File
"/home/per/.vscode/extensions/ms-python.python-2018.8.0/pythonFiles/experimental/ptvsd/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py",
line 319, in run
self._on_run()
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
self.__bootstrap_inner()
And the C-level backtrace:
(gdb) bt
#0 PyEval_EvalFrameEx (f=Frame 0x7f815c002310, for file
/usr/lib/python2.7/threading.py, line 371, in wait (), throwflag=0)
at ../Python/ceval.c:3347
#1 0x5624534af42c in PyEval_EvalCodeEx (co=0x7f816216e7d0,
globals={'current_thread': None, '_BoundedSemaphore': None,
'currentThread': None, '_Timer': None, '_format_exc': None, 'Semaphore': None,
'_deque': None, 'activeCount': None, '_profile_hook': None, '_sleep': None,
'_trace_hook': None, 'ThreadError': None, '_enumerate': None,
'_start_new_thread': None, 'BoundedSemaphore': None, '_shutdown': None,
'__all__': None, '_original_start_new_thread': None, '_Event': None,
'active_count': None, '__package__': None, '_Condition': None, '_RLock': None,
'_test': None, 'local': None, '__doc__': None, 'Condition': None, '_Verbose':
None, '_DummyThread': None, 'Thread': None, 'warnings': None, '__builtins__':
{'bytearray': None, 'IndexError': None, 'all': None, 'help': None, 'vars':
None, 'SyntaxError': None, 'unicode': None, 'UnicodeDecodeError': None,
'memoryview': None, 'isinstance': None, 'copyright': None, 'NameError': None,
'BytesWarning': None, 'dict': None, 'input': None, 'oct': None, 'bin': None,
'SystemExit': None, 'StandardError': No
ne, 'format': None, 'repr': None, 'sor...(truncated), locals=0x0,
args=0x562454463068, argcount=2,
kws=0x562454463078, kwcount=0, defs=0x7f8162116408, defcount=1,
cl
[issue7010] Rounding when converting float tuple to str
New submission from Per Rosengren : When a floating point value is stored, the actual value stored is something at most some small number eps larger or smaller than the original value. Python knows this, so if it stores 0.1, and then prints the stored value, it rounds off decimals less significant than eps. For some reason, if it prints a tuple with the same value, it doesn't do the rounding properly. This behavior is incorrect, and very annoying for instance when printing manually entered constants in tuples. '''Shows that floats in tuples are not rounded like floats. >>> print(.1) 0.1 >>> print((.1,)) (0.10001,) ''' import doctest doctest.testmod(verbose=True) -- components: Interpreter Core messages: 93193 nosy: scientist47 severity: normal status: open title: Rounding when converting float tuple to str type: behavior versions: Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/issue7010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7010] Rounding when converting float tuple to str
Per Rosengren added the comment: I tried Python 3.1, and it does indeed not have this issue. Thanks for swift response! -- ___ Python tracker <http://bugs.python.org/issue7010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22544] Inconsistent cmath.log behaviour
Per Brodtkorb added the comment: This is not only a problem for division. It also applies to multiplication as exemplified here: >>> complex(0,inf)+1 # expect 1 + infj Out[16]: (1+infj) >>> (complex(0,inf)+1)*1 # expect 1 + infj Out[17]: (nan+infj) >>> complex(inf, 0) + 1j # expect inf + 1j Out[18]: (inf+1j) >>> (complex(inf, 0)+1j)*1 # expect inf + 1j Out[19]: (inf, nanj) -- nosy: +pbrod versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue22544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: Not meaning to sound petty, but wouldn't it be common etiquette to retain some original copyright notice from original code intact..? -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: Ah, I thought that he had reused most of the original C code in _lzmamodule.c not replaced by python code, but I see that not being the case now (only slight fragments;). Oh well, I thought that I'd still earned a note with some slight credit at least, but I guess I won't go postal or anything in lack of either.. :p -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: I've (finally) finalized the api and prepared pyliblzma to be ready for inclusion now. The code can be found in the 'py3k' branch referred to earlier. Someone else (don't remember who:p) volunteered for writing the PEP earlier, so I leave it up to that person to write the PEP, I won't be able to get around to do so myself in the near future.. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: All fixed now. :) -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: Here's a patch with the latest code generated against py3k branch, it comes with Doc/library/lzma.rst as well now. -- keywords: +patch Added file: http://bugs.python.org/file19405/py3k-lzmamodule.patch ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: here's Lib/test/teststring.lzma, required by the test suite. -- Added file: http://bugs.python.org/file19406/teststring.lzma ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: here's Lib/test/teststring.xz, required by the test suite. -- Added file: http://bugs.python.org/file19407/teststring.xz ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: I've uploaded a new version of the patch to http://codereview.appspot.com/2724043/ now. I'd be okay on doing maintenance directly against the CPython repository btw. :) -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: LZMAFile, LZMACompressor & LZMADecompressor are all inspired by and written to be as similar to bz2's for easier use & maintenance. I must admit that I haven't really put much thought into alternate ways to implement them beyond monkey see, monkey do.. ;) LZMAOptions is a bit awkwardly written, but it doesn't serve documentation purposes only, it also exposes these values for max, min etc. to python (ie. as used by it's regression tests) and are also used when processing various compression options passed. IMO it does serve a useful purpose, but certainly wouldn't hurt from being rewritten in some better way... -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: Hehe, don't feel guily on my part at least, I had already implemented it like this long before. :p I guess I could rewrite it following these suggestions, but I probably won't be able to finish it in time for 3.2 beta. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11817] berkeley db 5.1 support
New submission from Per Øyvind Karlsen : This patch adds support for berkeley db <= 5.1. -- components: Extension Modules files: Python-2.7.1-berkeley-db-5.1.patch keywords: patch messages: 133442 nosy: proyvind priority: normal severity: normal status: open title: berkeley db 5.1 support versions: Python 2.7 Added file: http://bugs.python.org/file21601/Python-2.7.1-berkeley-db-5.1.patch ___ Python tracker <http://bugs.python.org/issue11817> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11817] berkeley db 5.1 support
Per Øyvind Karlsen added the comment: forgot some additional config checks in setup.py in previous patch.. -- ___ Python tracker <http://bugs.python.org/issue11817> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11817] berkeley db 5.1 support
Per Øyvind Karlsen added the comment: sloppysloppy... fix previous patch -- Added file: http://bugs.python.org/file21602/Python-2.7.1-berkeley-db-5.1.patch ___ Python tracker <http://bugs.python.org/issue11817> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] add xz compression support to distutils
New submission from Per Øyvind Karlsen : Here's a patch that adds support for xz compression: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/python/current/SOURCES/Python-2.6.1-distutils-xz-support.patch?view=log -- assignee: tarek components: Distutils messages: 83072 nosy: proyvind, tarek severity: normal status: open title: add xz compression support to distutils type: feature request versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5411> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] add xz compression support to distutils
Per Øyvind Karlsen added the comment: hmm, I'm unsure about how this should be done.. I guess such a test would belong in Lib/distutils/test_dist.py, but I'm uncertain about how it should be done, ie. should it be a test for doing 'bdist', 'bdist_rpm' and 'sdist' for each of the formats supported? I cannot seem to find any tests for the currently supported formats and such tests would introduce dependencies on the tools used to compress with these formats.. -- message_count: 2.0 -> 3.0 ___ Python tracker <http://bugs.python.org/issue5411> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5689] please support lzma compression as an extension and in the tarfile module
Per Øyvind Karlsen added the comment: I'm the author of the pyliblzma module, and if desired, I'd be happy to help out adapting pyliblzma for inclusion with python. Most of it's code is based on bz2module.c, so it shouldn't be very far away from being good 'nuff. What I see as required is: * clean out use of C99 types etc. * clean up the LZMAOptions class (this is the biggest difference from the bz2 module, as the filter supports a wide range of various options, everything related such as parsing, api documentation etc. was placed in it's own class, I've yet to receive any feedback on this decission or find any remote equivalents out there to draw inspiration from;) * While most of the liblzma API has been implemented, support for multiple/alternate filters still remains to be implemented. When done it will also cause some breakage with the current pyliblzma API. I plan on doing these things sooner or later anyways, it's pretty much just a matter of motivation and priorities standing in the way, actual interest from others would certainly have a positive effect on this. ;) For other alternatives to the LGPL liblzma, you really don't have any, keep in mind that LZMA is "merely" the algorithm, while xz (and LZMA_alone, used for '.lzma', now obsolete, but still supported) are the actual format you want support for. The LZMA SDK does not provide any compatibility for this. -- nosy: +proyvind ___ Python tracker <http://bugs.python.org/issue5689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5689] please support lzma compression as an extension and in the tarfile module
Per Øyvind Karlsen added the comment: ps: pylzma uses the LZMA SDK, which is not what you want. pyliblzma (not the same module;) OTOH uses liblzma, which is the library used by xz/lzma utils You'll find it available at http://launchpad.net/pyliblzma -- ___ Python tracker <http://bugs.python.org/issue5689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: Ooops, I kinda should've commented on this issue here in stead, rather than in issue5689, so I'll just copy-paste it here as well: I'm the author of the pyliblzma module, and if desired, I'd be happy to help out adapting pyliblzma for inclusion with python. Most of it's code is based on bz2module.c, so it shouldn't be very far away from being good 'nuff. What I see as required is: * clean out use of C99 types etc. * clean up the LZMAOptions class (this is the biggest difference from the bz2 module, as the filter supports a wide range of various options, everything related such as parsing, api documentation etc. was placed in it's own class, I've yet to receive any feedback on this decission or find any remote equivalents out there to draw inspiration from;) * While most of the liblzma API has been implemented, support for multiple/alternate filters still remains to be implemented. When done it will also cause some breakage with the current pyliblzma API. I plan on doing these things sooner or later anyways, it's pretty much just a matter of motivation and priorities standing in the way, actual interest from others would certainly have a positive effect on this. ;) For other alternatives to the LGPL liblzma, you really don't have any, keep in mind that LZMA is "merely" the algorithm, while xz (and LZMA_alone, used for '.lzma', now obsolete, but still supported) are the actual format you want support for. The LZMA SDK does not provide any compatibility for this. -- nosy: +proyvind ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: ah, you're right, I forgot that the license for the library had changed as well (motivated by attempt of pleasing BSD people IIRC;), in the past the library was LGPL while only the 'xz' util was public domain.. For my code, feel free to use your own/any other license you'd like or even public domain (if the license of bz2module.c that much of it's derived from permits of course)! I guess everyone should be happy now then. :) Btw. for review, I think the code already available should be pretty much good 'nuff for an initial review. Some feedback on things not derived from bz2module.c would be nice, especially the LZMAOptions class would be nice as it's where most of the remaining work required for adding additional filters support. Would kinda blow if I did the work using an approach that would be dismissed as utterly rubbish. ;) Oh well, it's out there available for anyone already, I probably won't(/shouldn't;) have time for it in a month at least, do as you please meanwhile. :) -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5689] please support lzma compression as an extension and in the tarfile module
Per Øyvind Karlsen added the comment: if you're already looking at issue6715, then I don't get why you're asking.. ;) quoting from msg106433: "For my code, feel free to use your own/any other license you'd like or even public domain (if the license of bz2module.c that much of it's derived from permits of course)!" The reason why I picked LGPLv3 in the past was simply just because liblzma at the time was licensed under it, so I just picked the same for simplicity. I've actually already dual-licensed it under the python license in addition on the project page though, but I just forgot updating the module's metadata as well before I released 0.5.3 last month.. Martin: For LGPL (or even GPL for that matter, disregarding linking restrictions) libraries you don't have to distribute the sources of those libraries at all (they're already made available by others, so that would be quite overly redundant, uh?;). LGPL actually doesn't even care at all about the license of your software as long as you only dynamically link against it. I don't really get what the issue would be even if liblzma were still LGPL, it doesn't prohibit you from distributing a dynamically linked library along with python either if necessary (which of course would be of convenience on win32..).. tsktsk, discussions about python module for xz compression should anyways be kept at issue6715 as this one is about the tarfile module ;p -- ___ Python tracker <http://bugs.python.org/issue5689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: Yeah, I guess I anyways can just break the current API right away to make it compatible with future changes, I've already figured since long ago how it should look like. It's not like I have to implement the actual functionality to ensure compatibility, no-op works like charm. ;) -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen added the comment: I've ported pyliblzma to py3k now and also implemented the missing functionality I mentioned earlier, for anyone interested in my progress the branch is found at: https://code.launchpad.net/~proyvind/pyliblzma/py3k I need to fix some memory leakages (side effect of the new PyUnicode/Pybytes change I'm not 100% with yet;) and some various memory errors reported by valgrind etc. though, but things are starting to look quite nice already. :) -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
