[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai added the comment: Okay. Verified as working. Thank you! -- ___ Python tracker <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
New submission from Anand B Pillai <[EMAIL PROTECTED]>: Python has great in-built support for all sorts of text compression including bzip, gzip, tarfile and other general purpose modules like zlib etc. Of these, I have a gripe with gzip - it does not provide a simple way of compressing/uncompressing a string like the other modules to (namely bzip, zlib) at the module level. It is relatively easy to perform gzip de-compression using the GzipFile class and StringIO objects, but compression is not that straight-forward. It would be great for the gzip module to have "compress" and "uncompress" functions at the module level without having to go through GzipFile every-time. I think being able to send gzip compressed strings directly would be useful for applications which require to send gzip data over the wire without having to write to files and read-back. -- components: Library (Lib) messages: 70578 nosy: pythonhacker severity: normal status: open title: Provide compress/uncompress functions on the gzip module type: feature request versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Uploading a file containing two functions which can be used to provide compress/uncompress on gzip. This is not a patch to gzip.py, but a stand-alone file. It this looks fine, I will make a patch. Added file: http://bugs.python.org/file11035/gzip_patch.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3492] Zlib compress/decompress functions returning bytearray
New submission from Anand B Pillai <[EMAIL PROTECTED]>: >>> import zlib >>> s='This is a string' >>> sc=zlib.compress(s) >>> sc bytearray(b'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\x92\xa2\xcc\xbct\x00/\xc2\x05\xcd') >>> zlib.decompress(sc) bytearray(b'This is a string') >>> This is wrong behavior as compress functions should return byte ,not a bytearray. Same for decompress. -- components: Library (Lib) messages: 70625 nosy: pythonhacker severity: normal status: open title: Zlib compress/decompress functions returning bytearray type: behavior versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Thanks. The file I uploaded was not an actual patch but just how the functions would appear in the gzip module, to illustrate the code. I can make an actual patch to gzip.py with docstrings, unit-tests and taking care of your other comments. Do you think this will be in time for Python 3.0 ? I can do this right away. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai <[EMAIL PROTECTED]> added the comment: I have uploaded the actual patch file which can be applied against the gzip.py module. I did not modify the _test() function since it is written for testing file compression. I can modify test_gzip.py if this patch is accepted. -- keywords: +patch Added file: http://bugs.python.org/file11044/gzip.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3492] Zlib compress/decompress functions returning bytearray
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Hi, I have a patch ready for this to be applied to zlibmodule.c. The patch is attached. I have tested it and it is working fine. -- keywords: +patch Added file: http://bugs.python.org/file11047/zlibmodule.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3492] Zlib compress/decompress functions returning bytearray
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Uploading svn diff for zlibmodule.c. Btw, how do I add unit tests for a fix ? You want me to create a simple test file and upload it here, or is there a standard procedure for this ? Please advise. Added file: http://bugs.python.org/file11049/zlibmodule_svn_diff.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Uploading the svn diff. Added file: http://bugs.python.org/file11050/gzip_svn_diff.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3492] Zlib compress/decompress functions returning bytearray
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Ok. I added two tests for checking the type of the returned object for zlib.compress and zlib.decompress in test_zlib.py in the py3k branch. Btw, my code uses assertEqual(type(...), bytes). Is this the proper way of type checking in py3k ? I could not see any formal type for "bytes" type in the types module. Attaching the svn diff for test_zlib.py . Added file: http://bugs.python.org/file11051/test_zlib_svn_diff.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Added test case in test_gzip.py. Attaching svn diff of the same. Added file: http://bugs.python.org/file11052/test_gzip_svn_diff.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3492] Zlib compress/decompress functions returning bytearray
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Any updates ? The py3k list is also very silent since the week-end...Thanks! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3492] Zlib compress/decompress functions returning bytearray
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Thanks. Will this make into beta3 ? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3492] Zlib compress/decompress functions returning bytearray
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Does py3k list/barry have this bug in their radar for rc2 ? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3492] Zlib compress/decompress functions returning bytearray
Anand B Pillai <[EMAIL PROTECTED]> added the comment: On Thu, Sep 4, 2008 at 4:59 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: > > Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > > Two remarks: > 1. Some functions in Modules/zipimport.c (get_data) will now receive > PyBytes, but zipimporter_get_source handle them as PyByteArray. Does > zipimport still work at all with this patch? > > 2. There are other places where PyString_FromString was (incorrectly > IMO) replaced with PyByteArray_FromString: > - Modules/_dbmmodule.c > - Modules/mmapmodule.c > - Modules/ossaudiodev.c > - Modules/zipimport.c (as noted above) > - PC/winreg.c > - Python/marshal.c Hmmm...but AFAIK zlib changes only affect zipimport directly. I wonder whether these other instances have bugs reported and are being tracked for the release. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3492] Zlib compress/decompress functions returning bytearray
Anand B Pillai <[EMAIL PROTECTED]> added the comment: Hi Gregory, Let me know if I can help out some way in testing the #3797 patches on various platforms. Regards, --Anand ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7150] datetime operations spanning MINYEAR give bad results
Anand B Pillai added the comment: Can someone update this issue ? Is the 2nd patch tested... ? -- ___ Python tracker <http://bugs.python.org/issue7150> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8319] HTMLparser does not handle call to handle_data when a tag contains no data.
Changes by Anand B Pillai : -- nosy: +pythonhacker ___ Python tracker <http://bugs.python.org/issue8319> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2582] Unpickling of range objects fail in Py3k
New submission from Anand B Pillai <[EMAIL PROTECTED]>: Unpickling of range objects is throwing an exception in Python 3.0 -- components: Interpreter Core, Library (Lib) files: bugdemo.py messages: 65157 nosy: pythonhacker severity: normal status: open title: Unpickling of range objects fail in Py3k versions: Python 3.0 Added file: http://bugs.python.org/file9981/bugdemo.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2582> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai added the comment: Can we include this for the next release ? -- ___ Python tracker <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7150] datetime operations spanning MINYEAR give bad results
Anand B Pillai added the comment: The issue is present in Python 3.0 and 2.5 as well. Python 2.5.1 (r251:54863, Jul 17 2008, 13:21:31) [GCC 4.3.1 20080708 (Red Hat 4.3.1-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> t0=datetime.datetime(1,1,1) >>> d1,d2,d3=map(datetime.timedelta, range(1,4)) >>> t0-d1 Traceback (most recent call last): File "", line 1, in OverflowError: date value out of range >>> t0-d2 datetime.datetime(1, 0, 255, 0, 0) I think this is bug in datetime for all Python versions -- nosy: +pythonhacker ___ Python tracker <http://bugs.python.org/issue7150> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7191] Odd behaviour with zlib.decompressobj optional parameter "wbits"
New submission from Anand B Pillai :
>>> import zlib
>>> help(zlib.decompressobj)
Help on built-in function decompressobj in module zlib:
decompressobj(...)
decompressobj([wbits]) -- Return a decompressor object.
Optional arg wbits is the window buffer size.
I experimented with this parameter and by trial and
error found out that it accepts only values from 8 to
15 inclusive.
>>> z=zlib.decompressobj(1)
Traceback (most recent call last):
File "", line 1, in
ValueError: Invalid initialization option
>>> z=zlib.decompressobj(7)
Traceback (most recent call last):
File "", line 1, in
ValueError: Invalid initialization option
>>> z=zlib.decompressobj(16)
Traceback (most recent call last):
File "", line 1, in
ValueError: Invalid initialization option
>>> z1=zlib.decompressobj(8)
>>> z2=zlib.decompressobj(15)
Now to the odd part. Let us create another decompressobj without any
parameter.
>>> z3=zlib.decompressobj()
Now compress some data.
>>> c=zlib.compress("This is a medium line of text")
Decompress with z2 works fine.
>>> z3.decompress(c)
b'This is a medium line of text'
Decompress with z2 is also fine.
>>> z2.decompress(c)
b'This is a medium line of text'
However with z1 it fails.
>>> z1.decompress(c)
Traceback (most recent call last):
File "", line 1, in
zlib.error: Error -3 while decompressing: invalid window size
In fact, only the optional value of 15 seems to work
for wbits, every other legal value (8-14) fails giving
the same error. I tried this with other random strings
with same effect.
Either there is no need to expose this as a parameter
or there could be a bug with how this parameter is used,
which has to be fixed. In either case, documentation
on this parameter has to be improved and legal range
of values should be provided.
--
components: Library (Lib)
messages: 94386
nosy: pythonhacker
severity: normal
status: open
title: Odd behaviour with zlib.decompressobj optional parameter "wbits"
type: behavior
versions: Python 3.0
___
Python tracker
<http://bugs.python.org/issue7191>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7150] datetime operations spanning MINYEAR give bad results
Anand B Pillai added the comment: The problem seems to be in the "normalize_date" function in datetimemodule.c. It is checking for a valid year range, but not checking for a valid month or day range. I have a patch which fixes this problem. It checks for month range (1<=m<=12) and day range(1<=d<=31). Here is Python with the patch. an...@anand-laptop:~/projects/python/py3k$ ./python Python 3.2a0 (py3k:75627, Oct 25 2009, 14:28:21) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/home/anand/.pythonrc", line 2, in import readline ImportError: No module named readline >>> import datetime >>> t0=datetime.datetime(1,1,1) >>> d1,d2,d3=map(datetime.timedelta, range(1,4)) >>> t0-d1 Traceback (most recent call last): File "", line 1, in OverflowError: date value out of range >>> t0-d2 Traceback (most recent call last): File "", line 1, in OverflowError: date value out of range >>> t0-d3 Traceback (most recent call last): File "", line 1, in OverflowError: date value out of range >>> d0=datetime.timedelta(0) >>> t0-d0 datetime.datetime(1, 1, 1, 0, 0) >>> Svn diff is attached. -- Added file: http://bugs.python.org/file15194/datetimemodule.c.svndiff ___ Python tracker <http://bugs.python.org/issue7150> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai added the comment: Ok, I will add this. -- ___ Python tracker <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Changes by Anand B Pillai : Removed file: http://bugs.python.org/file11035/gzip_patch.py ___ Python tracker <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Changes by Anand B Pillai : Removed file: http://bugs.python.org/file11044/gzip.patch ___ Python tracker <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Changes by Anand B Pillai : Removed file: http://bugs.python.org/file11050/gzip_svn_diff.patch ___ Python tracker <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai added the comment: Uploading fresh gzip.py SVN diff with a minor change, i.e accepting a regular string as argument, aka zlib.compress. -- Added file: http://bugs.python.org/file15282/gzip.py.svndiff ___ Python tracker <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai added the comment: Uploading rst documentation svn diff for module. -- Added file: http://bugs.python.org/file15283/gzip.rst.svndiff ___ Python tracker <http://bugs.python.org/issue3488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7191] Odd behaviour with zlib.decompressobj optional parameter "wbits"
Anand B Pillai added the comment: Ok, so you think a documentation update is enough ? Thanks. -- ___ Python tracker <http://bugs.python.org/issue7191> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15443] datetime module has no support for nanoseconds
Changes by Anand B Pillai : -- nosy: +pythonhacker ___ Python tracker <http://bugs.python.org/issue15443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21574] Port image types detections from PIL to the imghdr module
Changes by Anand B Pillai : -- nosy: +pythonhacker ___ Python tracker <http://bugs.python.org/issue21574> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23698] Fix documentation for multiprocessing.Manager
New submission from Anand B Pillai: multiprocessing.Manager seems to have an inconsistency in behaviour/documentation or both. The behaviour inconsistency is documented in the attached test script which should run for both Python2 and Python3. Briefly, multiprocessing.managers.BaseManager class starts a Python subprocess only after a call to its "start" method. Whereas its subclass, multiprocessing.managers.SyncManager does at the time of object creation. This is undocumented and against the base classe's documented behaviour. Also, the SyncManager is more commonly advertised via the facade multiprocessing.Manager() which is again at odds with the BaseManager's interface in that, 1. It takes no arguments (Python2) and different arguments (Python 3). 2. You can't call "start" on it but you can call "start" if you initialize it via multiprocessing.managers.SyncManager directly (!) 3. Even if you can't call a start on it, apparently you can shut it down via a call to "shutdown" 4. When you try to start such a manager you get a strange AssertionError complaining the state is not INITIAL. A better error is required here. Please find the attached file for all the sequence of tests done. Suggested changes are, 1. Fix the inconsistency in documented behaviour between SyncManager and its base class. Either don't start the child process upon object creation or document it. 2. Fix the inconsistency in SyncManager object creation interface and behaviour via "mulitprocessing.Manager()" and directly via "multiprocessing.managers.SyncManager(...)" . One should be able to start both objects cleanly. And the former should also take the address argument. If not document it properly. 3. The AssertionError when trying to start the SyncManager object obtained via a call to "multiprocessing.Manager()" looks like a bug. It should be fixed - otherwise a bette error should be raised and documentation updated. -- assignee: docs@python components: Documentation, Library (Lib) files: mp_test.py messages: 238379 nosy: docs@python, pythonhacker priority: normal severity: normal status: open title: Fix documentation for multiprocessing.Manager type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file38537/mp_test.py ___ Python tracker <http://bugs.python.org/issue23698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23698] Fix documentation for multiprocessing.Manager
Anand B Pillai added the comment: Is your patch uploaded anywhere ? Anyway, before thinking whether this should be a patch or doc fix, one needs multiprocessing module author to possibly comment on the right behaviour expected here. -- ___ Python tracker <http://bugs.python.org/issue23698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23698] Fix inconsistencies in behaviour and document it correctly for multiprocessing.Manager facade
Changes by Anand B Pillai : -- title: Fix documentation for multiprocessing.Manager -> Fix inconsistencies in behaviour and document it correctly for multiprocessing.Manager facade ___ Python tracker <http://bugs.python.org/issue23698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23746] sysconfg.is_python_build() is buggy
New submission from Anand B Pillai: On Python 3.5.0a1+ built from source, >>> import sysconfig >>> sysconfig.is_python_build() False >>> sysconfig.is_python_build(True) False >>> sysconfig._PROJECT_BASE '/opt/bin' >>> import sys >>> sys._home >>> The problem is, when sys._home is None, this function uses _is_python_source_dir(_PROJECT_BASE) . In this case the _PROJECT_BASE is clearly passed wrongly as '/opt/bin'. That is the INSTALL_PREFIX, not _PROJECT_BASE . Let us do a small hack and set _PROJECT_BASE to the folder where I build this Python version. # Of course this can't be reproduced but you get the idea. >>> sysconfig._PROJECT_BASE='/home/anand/code/cpython/' >>> sysconfig.is_python_build() True The documentation says, " sysconfig.is_python_build() Return True if the current Python installation was built from source. " which is clearly in conflict with what it is doing. >From a quick look at sysconfig.py it looks like it is calculating >_PROJECT_BASE wrongly. I can give a patch for this, but first I am more interested in finding out what this function is supposed to do - why have this function if you are not able to get the details of the build environment from the built interpreter ? Clearly it is not doing that here. The conclusions are part of the attached file in comments. -- components: Library (Lib) messages: 238993 nosy: pythonhacker priority: normal severity: normal status: open title: sysconfg.is_python_build() is buggy versions: Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue23746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23746] sysconfg.is_python_build() is buggy
Changes by Anand B Pillai : Added file: http://bugs.python.org/file38649/sysconfig_test.py ___ Python tracker <http://bugs.python.org/issue23746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23747] platform module exposes win32_ver function on posix systems
New submission from Anand B Pillai:
>>> import platform
>>> platform.system()
'Linux'
>>> platform.win32_ver()
('', '', '', '')
Why is this function even exposed on Linux ? It should be conditionally exposed
only on win32 platforms.
Funny that this is coming from the module named "platform" itself :)
--
components: Library (Lib)
messages: 238995
nosy: pythonhacker
priority: normal
severity: normal
status: open
title: platform module exposes win32_ver function on posix systems
___
Python tracker
<http://bugs.python.org/issue23747>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23747] platform module exposes win32_ver function on posix systems
Anand B Pillai added the comment:
Similarly for mac_ver, java_ver etc.
>>> platform.mac_ver()
('', ('', '', ''), '')
>>> platform.java_ver()
('', '', ('', '', ''), ('', '', ''))
Maybe it is okay if these functions are present, but can't they raise an
exception or return None instead of returning these funny tuples when empty
strings ?
I am surprised at Python's inconsistency in such things. For example,
>>> import winsound
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named 'winsound'
Works as expected on Linux. In the same vein, these functions shouldn't be
present as well IMHO - I agree this is debatable of course.
--
___
Python tracker
<http://bugs.python.org/issue23747>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23746] sysconfg.is_python_build() is buggy
Anand B Pillai added the comment: Thanks. From current documentation it isn't clear. Agree to make this a doc bug then. It should also be made clear this would work only for the executable built in the source directory. As in, (Running from the source folder using source Python executable). anand@toshiba-laptop:~/code/cpython$ ./python Python 3.5.0a1+ (default:656543a2ad75, Mar 3 2015, 22:56:27) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sysconfig >>> sysconfig.is_python_build() True -- ___ Python tracker <http://bugs.python.org/issue23746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23746] sysconfg.is_python_build() is buggy
Anand B Pillai added the comment: On second thoughts, why have such a function if it works correctly only when executed from source Cpython folder using source CPython executable and not otherwise ? Cuz if I am calling it like that I already KNOW that I am in such an environment. Possibly this is an internal function to be used by developers to find out if they are in such an environment. IMHO Then -> make it private (not callable outside) or drop it altogether. -- ___ Python tracker <http://bugs.python.org/issue23746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23746] sysconfg.is_python_build() is buggy
Anand B Pillai added the comment: > Lib/test/test_asdl_parser.py:12:if not sysconfig.is_python_build(): As I guessed - it is used internally by unit tests and possibly has no other significan audience. It is best to document this clearly. -- ___ Python tracker <http://bugs.python.org/issue23746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23748] platform._uname_cache is writeable
New submission from Anand B Pillai:
>> import platform
>>> print 'Actual =>',platform.uname()
Actual => ('Linux', 'toshiba-laptop', '3.13.0-24-generic', '#47-Ubuntu SMP Fri
May 2 23:30:00 UTC 2014', 'x86_64', 'x86_64')
>>> import hack_uname
# Someone imports my module unaware of the hack (see attached file)
>>> platform.uname()
('Limux', 'hacker-laptop', '11.15.0-28000-absurd', '#1 - FunkyDistro SMMP
Fry Feb 30 2015 23:59:00 UTC 2015', 'x866_64', 'x866_64')
Fix - Make the global _uname_cache inaccessible via the module and hence
unwriteable. I can provide a patch - it is kind of easy fix.
I think this might also be a security issue since if someone is writing a
significant piece of code based on the platform it can screw up the system - or
his web application if a piece of code like this is introduced in a module via
his chain of imports by a malicious hacker.
--
components: Library (Lib)
files: hack_uname.py
messages: 239005
nosy: pythonhacker
priority: normal
severity: normal
status: open
title: platform._uname_cache is writeable
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38652/hack_uname.py
___
Python tracker
<http://bugs.python.org/issue23748>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23748] platform._uname_cache is writeable
Anand B Pillai added the comment: I am changing the type to security as I dont think this is a behaviour issue. -- type: behavior -> security ___ Python tracker <http://bugs.python.org/issue23748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23748] platform._uname_cache is writeable
Anand B Pillai added the comment: Hmmm... dear sir - what prevents you from adding an __all__ to the module with these cache variables excluded ? -- ___ Python tracker <http://bugs.python.org/issue23748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23748] platform._uname_cache is writeable
Anand B Pillai added the comment: Closing is an easy fix, bet on my word this would appear as a different bug, thanks for your quickie fix! -- ___ Python tracker <http://bugs.python.org/issue23748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23746] sysconfg.is_python_build() is buggy
Changes by Anand B Pillai : -- assignee: -> docs@python components: +Documentation ___ Python tracker <http://bugs.python.org/issue23746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23746] sysconfg.is_python_build() is buggy
Changes by Anand B Pillai : -- nosy: +docs@python ___ Python tracker <http://bugs.python.org/issue23746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23698] Multiprocessing.Manager: fix behavior and doc inconsistencies
Anand B Pillai added the comment: @sbt - Any comments on this ? -- ___ Python tracker <http://bugs.python.org/issue23698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
