[issue1154] Carbon.CF memory leak
New submission from hhas: CFStringRefObj_Convert leaks memory when passed a str. See attached diff file for patch. -- components: Macintosh files: CFmodule.diff messages: 55843 nosy: hhas severity: normal status: open title: Carbon.CF memory leak type: resource usage versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1154> __1830,1831c1830,1832 < *p_itself = CFStringCreateWithCString((CFAllocatorRef)NULL, cStr, kCFStringEncodingASCII); < return 1; --- > *p_itself = CFStringCreateWithCString((CFAllocatorRef)NULL, cStr, > kCFStringEncodingASCII); > PyMem_Free(cStr); > return 1; ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1155] Carbon.CF memory management problem
New submission from hhas: While other CF...RefObj_Convert functions return a borrowed object, CFStringRefObj_Convert will return either a new or borrowed CFStringRef depending on the type of value supplied (str, unicode or CFString). As a result, extensions that use CFStringRefObj_Convert function to (e.g.) parse arguments - for example, Carbon.Launch (Launch_LSGetApplicationForInfo, Launch_LSFindApplicationForInfo) - will leak memory when a str or unicode value is passed. Three possible solutions: 1. Make all CF...RefObj_Convert functions return a 'new' object (i.e. call CFRetain if returning an existing CF object) and make callers responsible for always calling CFRelease on these objects when done. 2. Make CFStringRefObj_Convert accept Carbon.CF.CFStringRef values only, and make users responsible for calling Carbon.CF.toCF on Python str/unicode values before passing them to extension functions. 3. Make no changes to existing code, but advise Python users to call Carbon.CF.toCF themselves before passing text values to extension functions whose docstrings specify CFStringRef parameters if they wish to avoid memory leaks. The third solution would be the obvious choice if future Python development plans call for the deprecation and eventual removal of Carbon.CF. If Carbon.CF is to retained in the long term, however, then some sort of fix would be preferable. While the other two solutions would inevitable cause some disruption, I would suggest #1 is the lesser evil as it would require only existing standard and 3rd-party C extensions to be modified, whereas #2 would require existing Python code to be modified which would affect end-users as well. Note that if solution #1 is used, callers would need to avoid invoking CFRelease when an older, unfixed version of Carbon.CF is in use as this would cause a memory error. This shouldn't cause a problem if the fix is made in a major Python release (whose extensions are incompatible with earlier versions, and vice-versa). pymactoolbox.h could supply a suitable macro, e.g.: #define CarbonCFRelease(v) if (v != NULL) CFRelease(v); which client code could invoke as: #ifdef CarbonCFRelease CarbonCFRelease(someRef); CarbonCFRelease(anotherRef); #endif Unpatched extensions would continue to leak (more) memory, of course, but there should be no other ill effects. -- components: Macintosh messages: 55846 nosy: hhas severity: normal status: open title: Carbon.CF memory management problem type: resource usage versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1155> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10192] 'from urllib.parse import *' does not import urlencode function
New submission from hhas : Problem: The following statement fails to import the public urlencode function into the current namespace: from urllib.parse import * Solution: Add 'urlencode' to urllib.parse.__all__. -- components: Library (Lib) messages: 119558 nosy: hhas priority: normal severity: normal status: open title: 'from urllib.parse import *' does not import urlencode function type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue10192> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10976] json.loads() throws TypeError on bytes object
New submission from hhas :
json.loads() accepts strings but errors on bytes objects. Documentation and API
indicate that both should work. Review of json/__init__.py code shows that the
loads() function's 'encoding' arg is ignored and no decoding takes place before
the object is passed to JSONDecoder.decode()
Tested on Python 3.1.2 and Python 3.2rc1; fails on both.
Example:
#
#!/usr/local/bin/python3.2
import json
print(json.loads('123'))
# 123
print(json.loads(b'123'))
#
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/json/decoder.py:325:
# TypeError: can't use a string pattern on a bytes-like object
print(json.loads(b'123', encoding='utf-8'))
#
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/json/decoder.py:325:
# TypeError: can't use a string pattern on a bytes-like object
#
Patch attached.
--
components: Library (Lib)
files: json.diff
keywords: patch
messages: 126772
nosy: hhas
priority: normal
severity: normal
status: open
title: json.loads() throws TypeError on bytes object
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20481/json.diff
___
Python tracker
<http://bugs.python.org/issue10976>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10976] json.loads() throws TypeError on bytes object
hhas added the comment: Doc fix works for me. -- ___ Python tracker <http://bugs.python.org/issue10976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1155] Carbon.CF memory management problem
hhas added the comment: The Carbon extensions are deprecated in Python 2.6 and absent in Python 3, and PyObjC provides a far better alternative. I'd be surprised if this issue affects any users at this point (chances are I'm the only one who was ever bothered by it, and I eliminated all Carbon extension dependencies from my code in 2008). So I would recommend closing it as won't fix. -- ___ Python tracker <http://bugs.python.org/issue1155> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue916013] Improving MacPython's IAC support
hhas added the comment: As of Python 2.6/3.0, all Mac-specific modules are deprecated/eliminated from the standard library and there are no longer any plans to submit appscript for possible inclusion. This issue should be rejected and closed. ___ Python tracker <http://bugs.python.org/issue916013> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33794] Python.framework build is missing 'Current' symlink
New submission from hhas : The Python.framework installed at '/Library/Frameworks/Python.framework' should have a subdirectory structure similar to this: Python.framework | |-Headers [symlink to 'Versions/Current/Headers'] | |-Python [symlink to 'Versions/Current/Python'] | |-Resources [symlink to 'Versions/Current/Resources'] | |-Versions | | | |-2.7 [directory created by 2.7 installer] | | | |-3.5 [directory created by 3.5 installer] | | | |-3.6 [directory created by 3.6 installer] | | | ... | | | |- Current [symlink to last installed version, e.g. '3.6'] Current Python.framework installers create a 2.x/3.x directory and Headers+Python+Resources symlinks, but fail to create a 'Current' symlink. This breaks the top-level symlinks and causes importing the framework via NSBundle to fail. Please fix the framework build and/or install script to create the missing symlink. -- components: macOS messages: 318926 nosy: hhas, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python.framework build is missing 'Current' symlink versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15116] remove out-of-date Mac application scripting documentation
New submission from hhas : 1. The entire '4.6. Application Scripting' section should be deleted from the following Python 2 & 3 pages as appscript (and PyOSA) is no longer developed or supported and its use is not recommended for new projects (http://appscript.sourceforge.net/status.html): http://docs.python.org/using/mac.html#application-scripting http://docs.python.org/release/3.2/using/mac.html#application-scripting http://docs.python.org/dev/using/mac.html#application-scripting 2. The sentence 'For more up-to-date implementation of AppleScript support for Python, see the third-party py-appscript project: <http://pypi.python.org/pypi/appscript/>' should be deleted from the following Python 2 page: http://docs.python.org/library/macosa.html -- assignee: docs@python components: Documentation messages: 163282 nosy: docs@python, hhas priority: normal severity: normal status: open title: remove out-of-date Mac application scripting documentation versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue15116> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15116] remove out-of-date Mac application scripting documentation
hhas added the comment: @Ned: The whole page has been needing updated for years, but no-one's ever quite managed to complete it. In that light, might I suggest a two-step approach? 1. Edit the existing text now to remove all the obsolete info (e.g. section 4.1.2. is also defunct) and check in those changes before end of this month. 2. Develop whatever shiny new content you think is needed at your leisure. That way, if step 2 takes longer than expected (and creating new material always does), at least the current errors won't appear in the next release. The update to the OSA page can also be done immediately, as that's just a straight text deletion. -- ___ Python tracker <http://bugs.python.org/issue15116> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1113328] OSATerminology still semi-broken
hhas added the comment: No idea, be honest. The original patch was created for 2.3, and I've no free time to look into it myself now. BTW, note that nobody uses this module any more; it's deprecated in 2.6, absent in 3.0, and OSAGetAppTerminology() is deprecated in OS X 10.5 as well. I've already recommended that this and other bugs related to now- deprecated MacPython-only APIs be closed as "won't fix". ___ Python tracker <http://bugs.python.org/issue1113328> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
