[ python-Bugs-1777530 ] ctypes on Solaris
Bugs item #1777530, was opened at 2007-08-20 02:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777530&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aki (akineko) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes on Solaris Initial Comment: This is not really a bug. ctypes uses 'objdump', which is not available by default. (There are reasons not to install binutil on Solaris) There is no 'objdump' but Solaris has 'elfdump', instead. ctypes.util.py can use 'elfdump' instead of 'objdump'. #cmd = "objdump -p -j .dynamic 2>/dev/null " + f cmd = "elfdump -d 2>/dev/null " + f #res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read()) res = re.search(r'\sSONAME\s+([^\s]+)\s+([^\s]+)', os.popen(cmd).read())if not res: return None return res.group(2) # <<<--- // ./Modules/_ctypes/libffi/config.guess also uses objdump so that file probably needs to be updated as well. Thank you for your attention. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777530&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777458 ] glob doesn't return unicode with unicode parameter
Bugs item #1777458, was opened at 2007-08-20 09:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777458&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with unicode parameter Initial Comment: Unless I'm not understanding a previous bug report, I see this is a regression of http://sourceforge.net/tracker/index.php?func=detail&aid=1001604&group_id=5470&atid=305470. Here's an interactive session with 2.5.1 on WXP: In [1]: import sys In [2]: sys.version Out[2]: '2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]' In [3]: import glob In [4]: glob.glob(u"*txt") Out[4]: ['hola.txt', 'ma\xf1ana.txt'] In [5]: glob.glob(u"./*txt") Out[5]: [u'.\\hola.txt', u'.\\ma\xf1ana.txt'] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777458&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1759845 ] subprocess.call fails with unicode strings in command line
Bugs item #1759845, was opened at 2007-07-24 14:24
Message generated for change (Comment added) made by mclausch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759845&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matt (mclausch)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.call fails with unicode strings in command line
Initial Comment:
On Windows, subprocess.call() fails with an exception if either the executable
or any of the arguments contain upper level characters. See below:
>>> cmd = [ u'test_\xc5_exec.bat', u'arg1', u'arg2' ]
>>> subprocess.call(cmd)
Traceback (most recent call last):
File "", line 1, in
File "C:\Python25\lib\subprocess.py", line 443, in call
return Popen(*popenargs, **kwargs).wait()
File "C:\Python25\lib\subprocess.py", line 593, in __init__
errread, errwrite)
File "C:\Python25\lib\subprocess.py", line 815, in _execute_child
startupinfo)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xc5' in position 5:
ordinal not in range(128)
--
>Comment By: Matt (mclausch)
Date: 2007-08-20 17:12
Message:
Logged In: YES
user_id=1852547
Originator: YES
Sorry, I should have been more specific. I'm looking for a general
solution, not just one for characters in iso-8859-1. For instance, I need
to execute a subprocess where the executable or the arguments may contain
Japanese characters.
So another example would be:
cmd = [ u'test_\u65e5\u672c\u8a9e_exec.bat', u'arg1', u'arg2' ]
subprocess.call(cmd)
--
Comment By: brotchie (brotch)
Date: 2007-08-05 04:36
Message:
Logged In: YES
user_id=1860608
Originator: NO
Python's default character coding is 'ascii' which can't convert unicode >
127 into chars.
Forcing the unicode string to encode as 'iso-8859-1'
eg.
subprocess.call(cmd.encode('iso-8859-1'))
resolves the problem and runs the correct command.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759845&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778207 ] rounding inconsisntency using string formatting
Bugs item #1778207, was opened at 2007-08-20 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Hurlburt (jim_hurlburt) Assigned to: Nobody/Anonymous (nobody) Summary: rounding inconsisntency using string formatting Initial Comment: Sirs: Using python to generate a text file for transfer of data between systems, I seem to be getting inconsistent rounding results using a text formatting string Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 print "%9.4f" % (229.0 * .325,)-> 74.4250 correct print "%9.2f" % (round(74.425, 2),)-> 74.43 correct print "%9.2f" % (74.425,) -> 74.42 wrong print "%9.2f" % (167.255,) ->167.26 correct print "%9.2f" % (167.2551,)->167.26 correct print "%9.2f" % (167.2549,)->167.25 correct It appears as if the string formatting code is a bit flakey. Perhaps working in binary with too small a precision? For a bit I thought it might be "Round even up, odd down at the .005 break, but that doesn't appear to be the case. Now that I know it's there, I can do a workaround. Seems as if it deserves a fix or at least a document notation of the problem. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Yakima, WA -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778207 ] rounding inconsisntency using string formatting
Bugs item #1778207, was opened at 2007-08-20 23:20 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Hurlburt (jim_hurlburt) Assigned to: Nobody/Anonymous (nobody) Summary: rounding inconsisntency using string formatting Initial Comment: Sirs: Using python to generate a text file for transfer of data between systems, I seem to be getting inconsistent rounding results using a text formatting string Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 print "%9.4f" % (229.0 * .325,)-> 74.4250 correct print "%9.2f" % (round(74.425, 2),)-> 74.43 correct print "%9.2f" % (74.425,) -> 74.42 wrong print "%9.2f" % (167.255,) ->167.26 correct print "%9.2f" % (167.2551,)->167.26 correct print "%9.2f" % (167.2549,)->167.25 correct It appears as if the string formatting code is a bit flakey. Perhaps working in binary with too small a precision? For a bit I thought it might be "Round even up, odd down at the .005 break, but that doesn't appear to be the case. Now that I know it's there, I can do a workaround. Seems as if it deserves a fix or at least a document notation of the problem. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Yakima, WA -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-21 01:02 Message: Logged In: YES user_id=703403 Originator: NO This isn't really a bug---it's just one of those unavoidable things that happens when you're representing decimals using binary floating point: take a look at section 4.3 of the General Python FAQ: http://www.python.org/doc/faq/general/ If anything *is* wrong here it's actually the round() result, not the string formatting: 74.425 isn't exactly representable as a binary floating-point number, so Python (like most other languages) approximates it by the closest number that *is* exactly representable, which is (on my machine and probably yours too): 74.42499971578290569595992565155029296875 Since this is less than 74.425, the round function would, in an ideal world, round this down to 74.42 instead of up to 74.43. In the absence of an ideal world, making this sort of thing happen reliably and portably is hard, and I'd guess that round() is unlikely to change. Have you looked at the decimal module in the standard library? It sounds as though you might find it useful. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1093389 ] mapitags.PROP_TAG() doesn't account for new longs
Bugs item #1093389, was opened at 2004-12-31 05:36 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Joe Hildebrand (hildjj) Assigned to: Mark Hammond (mhammond) Summary: mapitags.PROP_TAG() doesn't account for new longs Initial Comment: Test case: >>> from win32com.mapi.mapitags import * >>> PROP_TAG(PT_LONG, 0x8041) 2151743491L Should be: -2143223805L or, alternately, the rest of the mapi interfaces should know about unsigned ints. -- >Comment By: Mark Hammond (mhammond) Date: 2007-08-21 11:15 Message: Logged In: YES user_id=14198 Originator: NO This should be in the pywin32 collector, and should also be resolved in recent pywin32 builds, where either form will be accepted when being passed to MAPI. -- Comment By: Joe Hildebrand (hildjj) Date: 2005-09-20 09:43 Message: Logged In: YES user_id=101697 For example, you could use this (awful hack): def PROP_TAG(ulPropType,ulPropID): a = (ulPropID<<16)|(ulPropType) if ulPropID & 0x8000: a = int(-((a ^ 0x) + 1)) return a mostly posted here so i can google for it next time... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-926910 ] Overenthusiastic check in Swap?
Bugs item #926910, was opened at 2004-04-01 05:34 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926910&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: benson margulies (benson_basis) Assigned to: Mark Hammond (mhammond) Summary: Overenthusiastic check in Swap? Initial Comment: When Py_DEBUG is turned on, PyThreadState_Swap calls in a fatal error if the two different thread states are ever used for a thread. I submit that this is not a good check. The documentation encourages us to write code that creates and destroys thread states as C threads come and go. Why can't a single C thread make a thread state, release it, and then make another one later? One particular usage pattern: We have an API that initializes embedded python. Then we have another API where the callers are allowed to be in any C thread. The second API has no easy way to tell if a thread used for it happens to be the same thread that made the initialization call. As the code is written now, any code running on the 'main thread' is required to fish out the build-in main-thread thread state. -- >Comment By: Mark Hammond (mhammond) Date: 2007-08-21 11:18 Message: Logged In: YES user_id=14198 Originator: NO The docs probably could be improved, but for now, this bug as reported is not going to be fixed. -- Comment By: benson margulies (benson_basis) Date: 2004-06-08 00:20 Message: Logged In: YES user_id=876734 Somehow, the path I took through the documentation failed to rub my nose in this. It would be good if the language from the original PEP was applied to the APIs that I coded to to warn people to use these other APIs instead. -- Comment By: Mark Hammond (mhammond) Date: 2004-06-07 17:22 Message: Logged In: YES user_id=14198 That check should not fail if you use the PyGILState APIs - it manages all of this for you. The PyGILState functions were added to handle exactly what you describe as your use case - is there any reason you can't use them? -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-07 15:15 Message: Logged In: YES user_id=80475 Mark, I believe this is your code. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926910&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777530 ] ctypes on Solaris
Bugs item #1777530, was opened at 2007-08-20 02:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777530&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aki (akineko) >Assigned to: Thomas Heller (theller) Summary: ctypes on Solaris Initial Comment: This is not really a bug. ctypes uses 'objdump', which is not available by default. (There are reasons not to install binutil on Solaris) There is no 'objdump' but Solaris has 'elfdump', instead. ctypes.util.py can use 'elfdump' instead of 'objdump'. #cmd = "objdump -p -j .dynamic 2>/dev/null " + f cmd = "elfdump -d 2>/dev/null " + f #res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read()) res = re.search(r'\sSONAME\s+([^\s]+)\s+([^\s]+)', os.popen(cmd).read())if not res: return None return res.group(2) # <<<--- // ./Modules/_ctypes/libffi/config.guess also uses objdump so that file probably needs to be updated as well. Thank you for your attention. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-20 22:59 Message: Logged In: YES user_id=33168 Originator: NO Thomas, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777530&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777160 ] Please warn about a subtle trap
Bugs item #1777160, was opened at 2007-08-19 10:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Please warn about a subtle trap Initial Comment: In python, -1**2 is -1.This will horribly surprise most mathematicians or C programmers where unary - binds very tightly. Such people will expect -1**2 == 1. This problem shows up in scientific contexts, especially Numpy, where an easy way to generate an alternating string of positive and negative numbers is -1**numpy.arange(10). In this example, one expects to produce [1, -1, 1, -1, ...]. So, please put a note in the documentation warning of this problem. It can lead to subtly wrong computations. The appropriate place to put the note is in the Python Reference Manual, section 5.4, The Power operator. Please insert a final line saying: "Note: since the minus sign is not part of a numeric literal, powers of negative numeric constants need to be written with parentheses. Be aware that -1**2 == -(1**2), not (-1)**2." -- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:07 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57255. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777160&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777168 ] Confusing typography Python Ref 5.9
Bugs item #1777168, was opened at 2007-08-19 10:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing typography Python Ref 5.9 Initial Comment: In the python reference manual, section 5.9, all that stuff with italic "opa", "opb" etc reads rather poorly because of a visually confusing choice of names. The bit about "...then a opa b opb c ... y opy z opz" looks more like "aopabopbcopc...yopyzopz" : in other words a unintelligible string of gibberish. A similar problem occurs slightly below. Note that the spaces *are* really there, but they do not show up well in the italic font used on my Firefox/Debian system, so it's hard to parse. The visual confusion is exacerbated by the similarities in the operator and variable names (e.g. "opa" and "a", then "opb" then "b"), and also by the use of a three-character string to mean "operator a" versus a one-character name for the variable. So, please change "opa" to "A" et cetera, or make some other change that makes it easier to read. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:12 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57256. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:12 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57256. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777168 ] Confusing typography Python Ref 5.9
Bugs item #1777168, was opened at 2007-08-19 10:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing typography Python Ref 5.9 Initial Comment: In the python reference manual, section 5.9, all that stuff with italic "opa", "opb" etc reads rather poorly because of a visually confusing choice of names. The bit about "...then a opa b opb c ... y opy z opz" looks more like "aopabopbcopc...yopyzopz" : in other words a unintelligible string of gibberish. A similar problem occurs slightly below. Note that the spaces *are* really there, but they do not show up well in the italic font used on my Firefox/Debian system, so it's hard to parse. The visual confusion is exacerbated by the similarities in the operator and variable names (e.g. "opa" and "a", then "opb" then "b"), and also by the use of a three-character string to mean "operator a" versus a one-character name for the variable. So, please change "opa" to "A" et cetera, or make some other change that makes it easier to read. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:12 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57256. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
