[issue10063] file:// scheme will stop accessing via ftp protocol
Senthil Kumaran orsent...@gmail.com added the comment: On Sun, Oct 10, 2010 at 03:49:42PM +, R. David Murray wrote: Does it also need a deprecation cycle? I think, adding a deprecation cycle might just delay this change. So, I would prefer if we make it in the 3.2 itself. - This is not a user-facing API change and I did not see any references where people relied upon this behavior. (No bugs / usage cases) - It is actually a bug, because one may not be sure if the ftp service is running the machine in the first place and user may not intend that ftp service be used for accessing local resources. We had python-dev discussion on this sometime back when fixing another bug and conclusion was that we raise a ValueError when file:// scheme was used in non-local url. Instead of ValueError, I think the generic URLError is okay too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9055] test_issue_8959_b fails when run from a service
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Hello. I've been finding the way to determine whether the process is running as service or not. Does this way work? On my environment, True is returned. I hope False will be returned in service environment. http://msdn.microsoft.com/en-us/library/d56de412%28v=VS.80%29.aspx http://msdn.microsoft.com/en-us/library/ms683225%28VS.85%29.aspx / from __future__ import print_function import ctypes from ctypes.wintypes import * UOI_FLAGS = 1 WSF_VISIBLE = 0x0001 class USEROBJECTFLAGS(ctypes.Structure): _fields_ = [(fInherit, BOOL), (fReserved, BOOL), (dwFlags, DWORD)] def window_station_has_display_surfaces(): dll = ctypes.windll.user32 h = dll.GetProcessWindowStation() if not h: raise ctypes.WinError() uof = USEROBJECTFLAGS() needed = DWORD() res = dll.GetUserObjectInformationW(h, UOI_FLAGS, ctypes.byref(uof), ctypes.sizeof(uof), ctypes.byref(needed)) if not res: raise ctypes.WinError() return bool(uof.dwFlags WSF_VISIBLE) def main(): print(window_station_has_display_surfaces()) if __name__ == '__main__': main() -- nosy: +ocean-city ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9055 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9055] test_issue_8959_b fails when run from a service
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Oh, I forgot to mention this. I think it can be possible to disable gui resource on regrtest.py when this function returns False. (I hope #9931 also can be fixed by this) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9055 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9055] test_issue_8959_b fails when run from a service
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I'm planning to try it on buildbot XP-5. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9055 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
Changes by Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: -- dependencies: +test_issue_8959_b fails when run from a service ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9931 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9055] test_issue_8959_b fails when run from a service
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I confirmed window_station_has_display_surfaces() returned False on XP-5 which is running as service. See http://www.python.org/dev/buildbot/builders/x86%20XP-5%203.x/builds/1453/steps/test/logs/stdio (It ran r85362) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9055 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: ... So Antoine and Martin: which encoding do you prefer? I still propose to drop the fsname encoding. Then this question goes away. You mean that we should use the following encoding for the command line arguments, environment variables and all filenames/paths: - Mac OS X: utf-8 - Windows: unicode for command line/env, mbcs to decode filenames - others OSes: locale encoding To do that, we have to: - others OSes: delete the PYTHONFSENCODING variable - Mac OS X: use utf-8 to decode the command line arguments (we can use PyUnicode_DecodeUTF8()+PyUnicode_AsWideCharString() before Python is initialized) On others OSes, we continue to use the FS encoding to encode command line/env vars, because the FS encoding will always be the locale encoding. And it's more pratical to use sys.getfilesystemencoding() than mbstowcs(), wcstombs(), _Py_wchar2char(), _Py_char2wchar(), etc. because the FS encoding doesn't depend on the current locale, and it uses Python codecs which support more error handlers. I like this solution because it doesn't change a lot of things. I agree to drop PYTHONFSENCODING because it looks like PYTHONFSENCODING introduced more inconsistencies than it solved. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Changes by Fred L. Drake, Jr. fdr...@acm.org: -- nosy: +fdrake ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. fdr...@acm.org added the comment: Causing perfectly good Python 2 applications to degrade in performance is bad, even if something else is available. This should be fixed as a regression. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Antoine Pitrou pit...@free.fr added the comment: This should be fixed as a regression. As far as I understand, this is not a regression. I don't think the cStringIO code has changed in years. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. fdr...@acm.org added the comment: Ok, reading more carefully, it's not a regression. But it's certainly a bug, and should be fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Antoine Pitrou pit...@free.fr added the comment: Ok, reading more carefully, it's not a regression. But it's certainly a bug, and should be fixed. Right. The patch looks straightforward, but I'm not familiar with the cStringIO code. Could you take a look? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. fdr...@acm.org added the comment: Assigning to myself for review. -- assignee: - fdrake keywords: +needs review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: I like this solution because it doesn't change a lot of things. I agree to drop PYTHONFSENCODING because it looks like PYTHONFSENCODING introduced more inconsistencies than it solved. If you remove the PYTHONFSENCODING, then we have to reconsider removal of sys.setfilesystemencoding(). The main argument for removal of the sys function was having the environment variable. If you remove both, Python will get very poor grades for OS interoperability on platforms that often deal with multiple different encodings for file names. I am repeating myself, but please keep in mind that the locale is an application scope setting. It doesn't have anything to do with what's actually stored in file systems or what the OS uses internally. Python therefore has to provide a way to customize the file system encoding and allow to override the locale guessing that's currently happening. You can't just tell people to go with whatever encoding setup you prefer to make Python's guessing easier or more correct. Python has to adapt to what the users actually use, not the other way around. Where that's not easily possible, there have to be ways to explicitly tell Python what to use... telling the user to adjust his or her locale settings just to be able to run Python is not an option. The world is still moving towards Unicode - it's not 100% there yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: You mean that we should use the following encoding for the command line arguments, environment variables and all filenames/paths: - Mac OS X: utf-8 - Windows: unicode for command line/env, mbcs to decode filenames No: unicode for filenames also. - others OSes: locale encoding Yes, that is my proposal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: If you remove both, Python will get very poor grades for OS interoperability on platforms that often deal with multiple different encodings for file names. Why that? It will work very well in such a setting, much better than, say, Java. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10063] file:// scheme will stop accessing via ftp protocol
R. David Murray rdmur...@bitdance.com added the comment: If it's been reviewed on python-dev and the consensus was to turn it into an error in 3.2, then I'm fine with it. But I'll bet we'll get at least a few bug reports :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10060] python.exe crashes or hangs on help() modules when bad modules found
Dev Player devpla...@gmail.com added the comment: I believe that a 3rd party package is corrupt. Whether it is or not I don't know. However whether or not a package is corrupt or not is not what I am reporting as a bug. I am reporting that python.exe crashes when I do help() modules. In GUI wrappers around python.exe, such as idle and pycrust, I get more information to the problem then when just in python.exe command line interpreter. As per the first post the errors I get in pycrust and idle are: ... File Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py, line 367, in Win32RawInput ret=dialog.GetSimpleInput(prompt) File Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py, line 223, in GetSimpleInput if title is None: title=win32ui.GetMainFrame().GetWindowText() error: The frame does not exist To be honest the meaning of these errors is beyond my expertise, or lack of thereof. I attempted to give as much info on what I experienced with running python.exe help() modules as I saw. If there is a direction you can point me to that I can gather more information then what I've already given, I'll give that a go as well. Other pointers to reported problems of a similar nature: http://mail.python.org/pipermail/pythonmac-sig/2008-November/020712.html https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/137210 Again this is not a report of a corrupt package. It is a report of python.exe crashing using commands considered part of Python.exe; that being help() then modules. An external library may be the cause or may not. But if it is an external library that is corrupt I would hope python.exe would not fail because of it, but instead just either ignore the package or report an error. Another reason why I think python.exe shouldn't crash because of external library integrity is what if there is a file or some such thing in one's Python path that looks like and smells like a Python module/package but isn't? Should python.exe fail because of such a file? I do not know the structure of a Python package or whether pythonwin on my PC is corrupt. However I imaging that if a fake package can be made so that IT is corrupt (perhaps make a missing file) that testing would be relatively easy. Sorry I don't have more information for you. But hearing from others who have tried their python.exe help() modules works or fails would be a start. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9437] can't build extensions with non-default ldflags (e.g. -m32)
Antoine Pitrou pit...@free.fr added the comment: There are now failures on the FreeBSD 7.2 buildbot: == ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) -- Traceback (most recent call last): File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/unixccompiler.py, line 254, in link self.spawn(linker + ld_args) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/ccompiler.py, line 909, in spawn spawn(cmd, dry_run=self.dry_run) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/spawn.py, line 34, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/spawn.py, line 138, in _spawn_posix % (cmd[0], exit_status)) distutils.errors.DistutilsExecError: command 'gcc' failed with exit status 1 During handling of the above exception, another exception occurred: Traceback (most recent call last): File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/tests/test_build_ext.py, line 65, in test_build_ext cmd.run() File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py, line 347, in run self.build_extensions() File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py, line 456, in build_extensions self.build_extension(ext) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py, line 543, in build_extension target_lang=language) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/ccompiler.py, line 719, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/unixccompiler.py, line 256, in link raise LinkError(msg) distutils.errors.LinkError: command 'gcc' failed with exit status 1 == ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) -- Traceback (most recent call last): File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/unixccompiler.py, line 254, in link self.spawn(linker + ld_args) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/ccompiler.py, line 909, in spawn spawn(cmd, dry_run=self.dry_run) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/spawn.py, line 34, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/spawn.py, line 138, in _spawn_posix % (cmd[0], exit_status)) distutils.errors.DistutilsExecError: command 'gcc' failed with exit status 1 During handling of the above exception, another exception occurred: Traceback (most recent call last): File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/tests/test_build_ext.py, line 321, in test_get_outputs cmd.run() File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py, line 347, in run self.build_extensions() File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py, line 456, in build_extensions self.build_extension(ext) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py, line 543, in build_extension target_lang=language) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/ccompiler.py, line 719, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/unixccompiler.py, line 256, in link raise LinkError(msg) distutils.errors.LinkError: command 'gcc' failed with exit status 1 Of course since distutils doesn't tell us what the gcc error message is, it's hard to do anything. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9437] can't build extensions with non-default ldflags (e.g. -m32)
Antoine Pitrou pit...@free.fr added the comment:
Apparently, the error message is:
gcc: ${LDFLAGS}: No such file or directory
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9437
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Ronald Oussoren ronaldousso...@mac.com added the comment: On 09 Oct, 2010,at 02:07 PM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: For the command line, it would mean that we introduced a new encoding: command line encoding, which will be utf-8 on OSX. Or more generally environment encoding, if it's also used for env vars. This could solve the subprocess issue neatly.  Note that the command-line and environment encoding on OSX is generally UTF-8, even if that is not always reflected in the locale settings. On recent OSX releases LANG will be set to a UTF-8 aware locale (en_US.UTF-8 on my machine) when you start a shell using Terminal.app. The correct locale environment variables are AFAIK not set in two important situations: on OSX 10.4 and when running code from an application bundle, in both cases the environment/command-line encoding should be treated as UTF-8. There is one reason for not wanting to assume that the encoding is always UTF-8: the user might access the system from a non-UTF8 terminal (such as when logging in with an SSH session from a system not using UTF-8, or using an alternate terminal application). IMHO these are minor enough use-cases that we could just enforce that the encoding is UTF-8 on OSX. That would ensure that the filesystem encoding and environment/command-line encoding are consistent and we'd no longer run into the problem that triggered this issue. Ronald -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ -- title: Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent - Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent Added file: http://bugs.python.org/file19184/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___htmlbodydivbrbrOn 09 Oct, 2010,at 02:07 PM, Antoine Pitrou lt;rep...@bugs.python.orggt; wrote:brbr/divdivblockquote type=citedivdiv class=_stretchbr Antoine Pitrou lt;pit...@free.frgt; added the comment:br br gt; For the command line, it would mean that we br gt; introduced a new encoding: command line encoding, which will be utf-8 on br gt; OSX.br br Or more generally environment encoding, if it's also used for envbr vars. This could solve the subprocess issue neatly./div/div/blockquotespannbsp;/span/divdivbr/divdivspan/spanNote that the command-line and environment encoding on OSX is generally UTF-8, even if that is not always reflected in the locale settings./divdivbr/divdivOn recent OSX releases LANG will be set to a UTF-8 aware locale (en_US.UTF-8 on my machine) when you start a shell using Terminal.app./divdivbr/divdivThe correct locale environment variables are AFAIK not set in two important situations: on OSX 10.4 and when running code from an application bundle, in both cases the environment/command-line encoding should be treated as UTF-8./divdivbr/divdivThere is one reason for not wanting to assume that the encoding is always UTF-8: the user might access the system from a non-UTF8 terminal (such as when logging in with an SSH session from a system not using UTF-8, or using an alternate terminal application). IMHO these are minor enough use-cases that we could just enforce that the encoding is UTF-8 on OSX.nbsp;/divdivbr/divdivThat would ensure that the filesystem encoding and environment/command-line encoding are consistent and we'd no longer run into the problem that triggered this issue./divdivbr/divdivRonald/divdivblockquote type=citedivdiv class=_stretchbr br --br br ___br Python tracker lt;rep...@bugs.python.orggt;br lt;a href=http://bugs.python.org/issue9992; _mce_href=http://bugs.pythonorg/issue9992;http://bugs.python.org/issue9992/agt;br ___br /div/div/blockquote/div/body/html___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9437] can't build extensions with non-default ldflags (e.g. -m32)
Martin v. Löwis mar...@v.loewis.de added the comment:
Notice that the error shows further up in the output, at the point where the
test was actually run:
gcc: ${LDFLAGS}: No such file or directory
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9437
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: There is one reason for not wanting to assume that the encoding is always UTF-8: the user might access the system from a non-UTF8 terminal (such as when logging in with an SSH session from a system not using UTF-8, or using an alternate terminal application). IMHO these are minor enough use-cases that we could just enforce that the encoding is UTF-8 on OSX. Ok, that's enough of an expert statement for me to settle the OSX case: we will always assume that environment data is UTF-8 on OSX (leaving the rest to the surrogate escape handler). -- title: Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent - Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Marc-Andre Lemburg m...@egenix.com added the comment: Martin v. Löwis wrote: Martin v. Löwis mar...@v.loewis.de added the comment: If you remove both, Python will get very poor grades for OS interoperability on platforms that often deal with multiple different encodings for file names. Why that? It will work very well in such a setting, much better than, say, Java. Well, Java pretty much fails completely in this respect, so being better than Java is not exactly the benchmark I had in mind :-) I think the proper benchmark would be a Python2 application that has no problems with these things, since file names are just bytes that refer to files on the disk, with no associated encoding - at least on Unix and related platforms. Being pedantic about forcing some encoding onto things that don't have an encoding won't really work out in practice. Dealing with file names, OS environments, pipes and sockets is dirty work, so I think we should go with the 80-20 approach in making 80% easy and 20% harder, but still possible. -- title: Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent - Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9437] can't build extensions with non-default ldflags (e.g. -m32)
Antoine Pitrou pit...@free.fr added the comment:
The cause for the failure seems to be a bug in the dreaded _parse_makefile().
When you give it a Makefile such as:
LDFLAGS=-foo
PY_LDFLAGS=-bar
LDSHARED=$(CC) -shared ${LDFLAGS} $(PY_LDFLAGS)
It outputs the following variables:
{'CC': '',
'LDFLAGS': '-foo',
'LDSHARED': '-shared ${LDFLAGS} -bar',
'PY_LDFLAGS': '-bar'}
That is, ${LDFLAGS} isn't expanded.
However, since the Makefile now explicitly appends PY_LDFLAGS to LDSHARED, we
could also stop doing so in ./configure.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9437
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4758] Python 3.x internet documentation needs work
Rafe H. Kettler rafe.kett...@gmail.com added the comment: I stumbled upon this issue and I feel similarly about the documentation for a particular module, ftplib. I think that the documentation is a bit too concise and assumes that the reader in an expert in the protocol when the point of the module is to abstract out such details. For example, for the error documentation, the exceptions are only explained by the error code the server can return to trigger them. So, while the explanation of error_perm, for example, should say something about permissions, it just says raised when an error code in the range 500–599 is received. This is particularly unclear for those with no knowledge of the internals of the protocol. Also, in the documentation for RetrLines(), the documentation mentions the options LIST, NLST, and MLSD without explaining what they are. I know that when I first started using ftplib I had to experiment with each option to determine what they do, and I think it would be better if this was clear in the docs from the start. I can propose a patch to the documentation if needed. -- nosy: +Rafe.H..Kettler ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9921] os.path.join('x','') behavior
Rafe H. Kettler rafe.kett...@gmail.com added the comment: I think Brian's second solution (the result is simply path2 when path1 is empty or path2 is an absolute path?) is a strong one. If that were tacked on towards the end it would add some clarity to the docs for people who will end up using this behavior or want a more in-depth explanation. At the same time, I think putting it towards the end (as more of a side note, like the bit about behavior on Windows with drive names) lets less sophisticated users (like me) ignore that piece of documentation. -- nosy: +Rafe.H..Kettler ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9921] os.path.join('x','') behavior
Radu Grigore radugrig...@gmail.com added the comment: posixpath.py's comment says -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9921] os.path.join('x','') behavior
Radu Grigore radugrig...@gmail.com added the comment: Realizing I still don't know what os.join.path does, I looked at the source. The comment in posixpath.py is: # Ignore the previous parts if a part is absolute. # Insert a '/' unless the first part is empty or already ends in '/'. I find this clear and it directly corresponds to the implementation. On the other hand, the source of ntpath.join() is a nightmare, and there's no similarly simple comment there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: Being pedantic about forcing some encoding onto things that don't have an encoding won't really work out in practice. Dealing with file names, OS environments, pipes and sockets is dirty work, so I think we should go with the 80-20 approach in making 80% easy and 20% harder, but still possible. Unix applications can always use the byte-oriented file name APIs if they need to. Then you are back to the state that things have in Python 2. No need to have a user-tunable file system encoding there. However, I completely fail to see the advantage that the PYTHONFSENCODING variable has over the LANG variable. If it's possible to set PTHONFSENCODING in some application, it surely is also possible to set LANG (or LC_CTYPE), no? Setting the latter also gives you the advantage that environment variables and command line arguments use the same encoding as file names. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Antoine Pitrou pit...@free.fr added the comment: However, I completely fail to see the advantage that the PYTHONFSENCODING variable has over the LANG variable. If it's possible to set PTHONFSENCODING in some application, it surely is also possible to set LANG (or LC_CTYPE), no? Setting the latter also gives you the advantage that environment variables and command line arguments use the same encoding as file names. I guess LANG and LC_CTYPE can be used for other purposes such as internationalization. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10066] xmlrpclib does not handle some non-printable characters properly
New submission from Peter Gyorko gyor...@balabit.hu: If I add a string to the response, which contains non-printable characters, the output will not be parsed by the most of the XML parsers (I tried with XML-RPC for PHP). Here is my quick and dirty fix: --- a/Lib/xmlrpclib.py +++ b/Lib/xmlrpclib.py @@ -165,9 +165,18 @@ def _decode(data, encoding, is8bit=re.compile([\x80-\xff]).search): return data def escape(s, replace=string.replace): -s = replace(s, , amp;) -s = replace(s, , lt;) -return replace(s, , gt;,) +res = '' +for char in s: +char_code = ord(char) +if (char_code 32 and char_code not in (9, 10, 13)) or char_code 126: +res += '\\x%02x' % ord(char) +else: +res += char + +res = replace(res, , amp;) +res = replace(res, , lt;) +res = replace(res, , gt;) +return res if unicode: def _stringify(string): -- components: XML messages: 118376 nosy: gyorkop priority: normal severity: normal status: open title: xmlrpclib does not handle some non-printable characters properly type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10066 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Marc-Andre Lemburg m...@egenix.com added the comment: Martin v. Löwis wrote: Martin v. Löwis mar...@v.loewis.de added the comment: Being pedantic about forcing some encoding onto things that don't have an encoding won't really work out in practice. Dealing with file names, OS environments, pipes and sockets is dirty work, so I think we should go with the 80-20 approach in making 80% easy and 20% harder, but still possible. Unix applications can always use the byte-oriented file name APIs if they need to. Then you are back to the state that things have in Python 2. No need to have a user-tunable file system encoding there. Right and if you take the position of refusing to guess which we usually do in Python, then interfacing to file names using bytes would be the appropriate way to handle the situation. However, since Python3 has chosen to regard file names as text regardless of platform, we're now in the situation that we have to come up with some educated guess on the encoding. However, I completely fail to see the advantage that the PYTHONFSENCODING variable has over the LANG variable. If it's possible to set PTHONFSENCODING in some application, it surely is also possible to set LANG (or LC_CTYPE), no? Setting the latter also gives you the advantage that environment variables and command line arguments use the same encoding as file names. The advantage is that you can change the Python files system encoding *without* having to change your locale settings. You can't possibly expect a user to switch to using UTF-8 for all his/her applications just because Python needs this to properly decode file names. Users of applications written in Python will most likely not even know how to change the locale encoding. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9921] os.path.join('x','') behavior
Rafe H. Kettler rafe.kett...@gmail.com added the comment: Radu, while the comments are not as clear for ntpath, the behavior is the same. So, the comment you detailed from posixpath could be adapted to Windows by replacing '/' with 'a separator' or something of that nature. That said, the comment in posixpath could be adapted to clear english like so: join() inserts a separator unless the first part is empty or already ends in a separator. If a part is absolute, join() ignores the previous parts. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9003] urllib.request and http.client should allow certificate checking
Antoine Pitrou pit...@free.fr added the comment: Here is a patch which also adds 'cafile' and 'capath' keyword arguments to urlopen(). -- stage: needs patch - patch review Added file: http://bugs.python.org/file19185/httpcli+urllib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9003 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9921] os.path.join('x','') behavior
Changes by Radu Grigore radugrig...@gmail.com: -- nosy: -rgrig ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10060] python.exe crashes or hangs on help() modules when bad modules found
R. David Murray rdmur...@bitdance.com added the comment: What I am saying is that if an extension module (one that provides non-python code in a load module) is corrupt, then it can totally screw up Python's internal bookkeeping, and there is nothing Python can do to protect itself against that. If the corrupt module in question is pure Python, then you are correct, 'help' should not fail. If, however, the corrupt module is not pure Python, then there may be nothing that can be done by Python to prevent the failure. Can you reproduce the problem using a pure Python 'corrupt' module? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9003] urllib.request and http.client should allow certificate checking
Antoine Pitrou pit...@free.fr added the comment: Here is a new patch with doc updates for urllib.request. -- Added file: http://bugs.python.org/file19186/httpcli+urllib2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9003 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5870] subprocess.DEVNULL
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. fdr...@acm.org added the comment: Committed with minor changes in r85366 (release27-maint branch). -- keywords: -needs review resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9003] urllib.request and http.client should allow certificate checking
Antoine Pitrou pit...@free.fr added the comment: This patch should fix the test hanging issues witnessed on some machines. -- Added file: http://bugs.python.org/file19187/httpcli+urllib3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9003 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10052] Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4)
Mark Dickinson dicki...@gmail.com added the comment: Anyway, I would like to leave the decision to the core developers. You mean the core developers other than Stefan? ;-) I don't have any objection to a patch for this problem, provided that that patch is specifically targeted at FreeBSD 4, and clearly doesn't change behaviour on any other platform. On one hand I agree that FreeBSD 4 isn't a high priority platform; on the other, it's not *that* obscure, and failure to build the Python core (rather than the extension modules) is quite a big deal. It's also a regression from 2.6, IIUC. And it should be easy to fix, with a single block of code in pyport.h. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: MvL - Windows: unicode for command line/env, mbcs to decode filenames MvL No: unicode for filenames also. Yes, I mean unicode for everything, but decode bytes data from the mbcs encoding. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: MAL If you remove the PYTHONFSENCODING, then we have to reconsider MAL removal of sys.setfilesystemencoding(). Plase, Marc, read my comments. You never consider technical problems, you just propose to ensure that Python just works, without answering to my technical questions. I already explained 2 or 3 times that sys.setfilesystemencoding() was completly buggy and not usable in pratical. You proposed PYTHONFSENCODING and I implemented it. But then I explained in an email to python-dev and in this issue, that this environment variable introduced many problems. I don't see how sys.setfilesystemencoding() would solve this issue, it's out of scope. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3865] explain that profilers should be used for profiling, not benchmarking
Sandro Tosi sandro.t...@gmail.com added the comment: Hello, Here's a patch that implement what's request by Fredrik. Regards, Sandro -- keywords: +patch nosy: +sandro.tosi Added file: http://bugs.python.org/file19188/issue3865-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3865 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: You can't possibly expect a user to switch to using UTF-8 for all his/her applications just because Python needs this to properly decode file names. If the user hasn't switched to UTF-8, why would Python need that to properly decode file names? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: MAL You can't just tell people to go with whatever encoding setup MAL you prefer to make Python's guessing easier or more correct. Python doesn't really *guess* the encoding, it just reads the encoding from the locale. What do you mean by more correct? How can Python knowns the right encoding better than the user? Python should not guess anything. If the environment is not correctly configured, it's not Python's fault. The user has to fix its environment. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: I guess LANG and LC_CTYPE can be used for other purposes such as internationalization. That's why there are different environement variables: * LC_MESSAGES for i18n (messages) * LC_CTYPE for the encoding * LC_TIME for time and date * etc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9003] urllib.request and http.client should allow certificate checking
Senthil Kumaran orsent...@gmail.com added the comment: Yes, it does solve the problem of httplib and urllib2_localnet tests which were hanging with the earlier patch on certain machines.. -- Added file: http://bugs.python.org/file19189/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9003 ___Yes, it does solve the problem of httplib and urllib2_localnet tests which were hanging with the earlier patch on certain machines..divbr /div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: issue9992.patch: - Remove PYTHONFSENCODING environment variable - Mac OS X: Use utf-8 to decode command line arguments - Fix issue #9992 (this issue): attached test, locale_fs_encoding.py, pass - Fix issue #9988 - Fix issue #10014 - Fix issue #10039 $ diffstat issue9992.patch Doc/using/cmdline.rst | 12 Doc/whatsnew/3.2.rst|6 -- Lib/test/test_os.py | 30 -- Lib/test/test_subprocess.py |4 Lib/test/test_sys.py| 29 - Modules/main.c |3 --- Modules/python.c| 10 +- Python/pythonrun.c | 22 ++ 8 files changed, 15 insertions(+), 101 deletions(-) I like such patch: it removes more code than it adds, but it fixes 4 different issues! I didn't tested the patch specific to OSX (use utf8 to decode command line arguments). -- Added file: http://bugs.python.org/file19190/issue9992.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9991] xmlrpc client ssl check faulty
Jesse Kaukonen jesse.kauko...@gmail.com added the comment: This problem also occurs with our service at www.renderfarm.fi with Blender. I tested the included patch, and can confirm that it works. I'm very interested in the possibility of seeing this included in the official release ASAP! -- nosy: +gekko ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9991 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: I think that issue9992.patch fixes also #4388 because it uses the same encoding (FS encoding, utf8) on OSX to encode and to decode command line arguments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9991] xmlrpc client ssl check faulty
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9991 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8533] regrtest: use backslashreplace error handler for stdout
STINNER Victor victor.stin...@haypocalc.com added the comment: Oops, sorry. I'll withdraw my last patch. Why? Your patch is useful to run a single test outside regrtest. But you should not remove the hack on regrtest.py, only keep your patch on unittest/runner.py. There are not exclusive. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8533] regrtest: use backslashreplace error handler for stdout
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Thank you. I'll reattach the patch only for Lib/unittest/runner.py -- Added file: http://bugs.python.org/file19191/py3k_also_no_unicode_error_on_direct_test_run.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10060] python.exe crashes or hangs on help() modules when bad modules found
Dev Player devpla...@gmail.com added the comment: On Mon, Oct 11, 2010 at 1:43 PM, R. David Murray rep...@bugs.python.orgwrote: R. David Murray rdmur...@bitdance.com added the comment: Can you reproduce the problem using a pure Python 'corrupt' module? -- When in python.exe, and you type help() then modules, aren't you really asking for packages? I don't know how to make a package let alone a corrupt one. If help() modules is in fact looking for just a Python module file with extension _.py in lib\site-packages I don't know what Python help() modules looks for in that source code _.py file to be considered a module worth reporting back to the user. Certain module attributes? I do not know enough atm about how PythonWin is packaged. I'll look into it but I'm a newbie here and hopes for well informed facts on PythonWin may be ... well leave it at that. Perhaps an idea here too: If python.exe help() modules crashes when it passes control to a module or package that is not pure Python (source code or byte code) but some kind of C SWIG thing, then perhaps to make python.exe more robust it should simulate what idle does, as idle does not crash and it reports error when finished with calling python.exe help() modules. In other words, perhaps the Python interpreter can call an external routine (another program) that behaves like help() modules, perhaps using something like os.system() or subprocess.Popen(). Call it help.py or help.exe or something. If help.exe returns, all is good. If help crashes just like Python did at least Python can handle the crashing of help.exe gracefully. This idea is purely with the interest to make python.exe more robust. -- Added file: http://bugs.python.org/file19192/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10060 ___br div class=gmail_quote blockquote style=BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex class=gmail_quote div class=imOn Mon, Oct 11, 2010 at 1:43 PM, R. David Murray span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/span wrote:brR. David Murray lt;a href=mailto:rdmur...@bitdance.com;rdmur...@bitdance.com/agt; added the comment:br Can you reproduce the problem using a pure Python #39;corrupt#39; module?br--br/div/blockquote div /div divWhen in python.exe, and you type help() then modules, aren#39;t you really asking for packages? /div divI don#39;t know how to make a package let alone a corrupt one./div div /div divIf help() modules is in fact looking for just a Python module file with extension _.py in lib\site-packages I don#39;t know what Python help() modules looks for in that source code _.py file to be considered a module worth reporting back to the user. Certain module attributes?/div div /div divI do not know enough atm about how PythonWin is packaged. I#39;ll look into it but I#39;m a newbie here and hopes for well informed facts on PythonWin may be ... well leave it at that./div div /div divPerhaps an idea here too: If python.exe help() modules crashes when it passes control to a module or package that is not pure Python (source code or byte code) but some kind of C SWIG thing, then perhaps to make python.exe more robust it should simulate what idle does, as idle does not crash and it reports error when finished with calling python.exe help() modules./div div /div divIn other words, perhaps the Python interpreter can call an external routine (another program) that behaves like help() modules, perhaps using something like os.system() or subprocess.Popen(). Call it help.py or help.exe or something. If help.exe returns, all is good. If help crashes just like Python did at least Python can handle the crashing of help.exe gracefully. This idea is purely with the interest to make python.exe more robust./div div /div/div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10041] socket.makefile(mode = 'r').readline() silently removes carriage return
kai zhu kaizhu...@gmail.com added the comment: np antoine :) this 2 line patch will match socket.makefile() signature with open(). any chance it can b committed b4 python3.2 beta? i rely on this patch in order to forward-port redis to python3 -- Added file: http://bugs.python.org/file19193/makefile.errors.newline.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10041] socket.makefile(mode = 'r').readline() silently removes carriage return
R. David Murray rdmur...@bitdance.com added the comment: Kai: could you write a unit test for this? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1028] Tkinter binding involving Control-spacebar raises unicode error
Tangaroa jspru...@yahoo.com added the comment: Python 3.1.2, Ubuntu (Lucid) Caused by Control + Shift + Spacebar Debugger output from terminal: Traceback (most recent call last): File /usr/bin/idle-python3.1, line 5, in module main() File /usr/lib/python3.1/idlelib/PyShell.py, line 1420, in main root.mainloop() File /usr/lib/python3.1/tkinter/__init__.py, line 1012, in mainloop self.tk.mainloop(n) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding Will try the patch. -- nosy: +jsprunck -amaury.forgeotdarc, doko, ezio.melotti, gpolo, kbk, nnorwitz, ocean-city, terry.reedy, wplappert versions: -Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10041] socket.makefile(mode = 'r').readline() silently removes carriage return
kai zhu kaizhu...@gmail.com added the comment: added unittest to patch tested test.test_socket on debian colinux running under winxp i get 2 unrelated errors (in both patched and unpatched version) from testRDM and testStream about socket.AF_TIPC being unsupported: pub...@colinux 3 ~/build/py3k.patch: ./python -m unittest test.test_socket ..s..EE == ERROR: testRDM (test.test_socket.TIPCTest) -- Traceback (most recent call last): File /home/public/build/py3k.patch/Lib/test/test_socket.py, line 1683, in testRDM srv = socket.socket(socket.AF_TIPC, socket.SOCK_RDM) File /home/public/build/py3k.patch/Lib/socket.py, line 94, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) socket.error: [Errno 97] Address family not supported by protocol == ERROR: testStream (test.test_socket.TIPCThreadableTest) -- Traceback (most recent call last): File /home/public/build/py3k.patch/Lib/test/test_socket.py, line 131, in _setUp self.__setUp() File /home/public/build/py3k.patch/Lib/test/test_socket.py, line 1707, in setUp self.srv = socket.socket(socket.AF_TIPC, socket.SOCK_STREAM) File /home/public/build/py3k.patch/Lib/socket.py, line 94, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) socket.error: [Errno 97] Address family not supported by protocol -- Ran 131 tests in 15.960s FAILED (errors=2, skipped=1) -- Added file: http://bugs.python.org/file19194/socket.makefile.with.unittest.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10041] socket.makefile(mode = 'r').readline() silently removes carriage return
kai zhu kaizhu...@gmail.com added the comment: updated unittest patch -- Added file: http://bugs.python.org/file19195/socket.makefile.with.unittest.v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2953] _zip_directory_cache untested and undocumented
Changes by Éric Araujo mer...@netwok.org: Removed file: http://bugs.python.org/file13625/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2953] _zip_directory_cache untested and undocumented
Changes by Éric Araujo mer...@netwok.org: Removed file: http://bugs.python.org/file13638/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2953] _zip_directory_cache untested and undocumented
Éric Araujo mer...@netwok.org added the comment: Could the recently-added functools.lru_cache help here? -- components: -Distutils nosy: +eric.araujo versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4758] Python 3.x internet documentation needs work
Éric Araujo mer...@netwok.org added the comment: Rafe, thank you for your message and willingness to contribute. I feel what you’re reporting is another bug: the original report talks about bytes/str confusion only, not about the simplicity of the APIs. Could you open another bug with component “Documentation” and add orsenthil to the nosy list? Thanks in advance. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
