[issue9055] test_issue_8959_b fails when run from a service

Hirokazu Yamamoto 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%28

[issue9055] test_issue_8959_b fails when run from a service

Hirokazu Yamamoto 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

[issue9055] test_issue_8959_b fails when run from a service

Hirokazu Yamamoto added the comment: I'm planning to try it on buildbot XP-5. -- ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue9931] test_ttk_guionly hangs on XP5

Changes by Hirokazu Yamamoto : -- dependencies: +test_issue_8959_b fails when run from a service ___ Python tracker ___ ___ Python-bugs

[issue9055] test_issue_8959_b fails when run from a service

Hirokazu Yamamoto 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) --

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

STINNER Victor 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 filena

[issue10045] poor cStringIO.StringO seek performance

Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue10045] poor cStringIO.StringO seek performance

Fred L. Drake, Jr. 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

[issue10045] poor cStringIO.StringO seek performance

Antoine Pitrou 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 __

[issue10045] poor cStringIO.StringO seek performance

Fred L. Drake, Jr. added the comment: Ok, reading more carefully, it's not a regression. But it's certainly a bug, and should be fixed. -- ___ Python tracker ___ _

[issue10045] poor cStringIO.StringO seek performance

Antoine Pitrou 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? --

[issue10045] poor cStringIO.StringO seek performance

Fred L. Drake, Jr. added the comment: Assigning to myself for review. -- assignee: -> fdrake keywords: +needs review ___ Python tracker ___

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Marc-Andre Lemburg 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

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Martin v. Löwis 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. >

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Martin v. Löwis 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. --

[issue10063] file:// scheme will stop accessing via ftp protocol

R. David Murray 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

[issue10060] python.exe crashes or hangs on help() modules when bad modules found

Dev Player 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 pyt

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Antoine Pitrou added the comment: There are now failures on the FreeBSD 7.2 buildbot: == ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) --

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Antoine Pitrou added the comment: Apparently, the error message is: gcc: ${LDFLAGS}: No such file or directory -- ___ Python tracker ___

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Ronald Oussoren added the comment: On 09 Oct, 2010,at 02:07 PM, Antoine Pitrou wrote: Antoine Pitrou 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

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Martin v. Löwis 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

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Martin v. Löwis 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 applica

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Marc-Andre Lemburg added the comment: Martin v. Löwis wrote: > > Martin v. Löwis 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 wor

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Antoine Pitrou 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',

[issue4758] Python 3.x internet documentation needs work

Rafe H. Kettler 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

[issue9921] os.path.join('x','') behavior

Rafe H. Kettler 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 w

[issue9921] os.path.join('x','') behavior

Radu Grigore added the comment: posixpath.py's comment says -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9921] os.path.join('x','') behavior

Radu Grigore 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 direct

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Martin v. Löwis 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

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Antoine Pitrou 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 als

[issue10066] xmlrpclib does not handle some non-printable characters properly

New submission from Peter Gyorko : 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 +

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Marc-Andre Lemburg added the comment: Martin v. Löwis wrote: > > Martin v. Löwis 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 d

[issue9921] os.path.join('x','') behavior

Rafe H. Kettler 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

[issue9003] urllib.request and http.client should allow certificate checking

Antoine Pitrou 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

[issue9921] os.path.join('x','') behavior

Changes by Radu Grigore : -- nosy: -rgrig ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue10060] python.exe crashes or hangs on help() modules when bad modules found

R. David Murray 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"

[issue9003] urllib.request and http.client should allow certificate checking

Antoine Pitrou 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 __

[issue5870] subprocess.DEVNULL

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue10045] poor cStringIO.StringO seek performance

Fred L. Drake, Jr. added the comment: Committed with minor changes in r85366 (release27-maint branch). -- keywords: -needs review resolution: -> accepted status: open -> closed ___ Python tracker ___

[issue9003] urllib.request and http.client should allow certificate checking

Antoine Pitrou 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 _

[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 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'

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

STINNER Victor 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

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

STINNER Victor 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 answerin

[issue3865] explain that profilers should be used for profiling, not benchmarking

Sandro Tosi 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

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

Martin v. Löwis 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?

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

STINNER Victor 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"? Ho

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

STINNER Victor 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. -- _

[issue9003] urllib.request and http.client should allow certificate checking

Senthil Kumaran 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

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

STINNER Victor 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 $ dif

[issue9991] xmlrpc client ssl check faulty

Jesse Kaukonen 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

[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

STINNER Victor 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 __

[issue9991] xmlrpc client ssl check faulty

Changes by Antoine Pitrou : -- nosy: +orsenthil ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue8533] regrtest: use backslashreplace error handler for stdout

STINNER Victor 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. -- _

[issue8533] regrtest: use backslashreplace error handler for stdout

Hirokazu Yamamoto 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

[issue10060] python.exe crashes or hangs on help() modules when bad modules found

Dev Player added the comment: > On Mon, Oct 11, 2010 at 1:43 PM, R. David Murray > wrote: > R. David Murray 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 fo

[issue10041] socket.makefile(mode = 'r').readline() silently removes carriage return

kai zhu 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.error

[issue10041] socket.makefile(mode = 'r').readline() silently removes carriage return

R. David Murray added the comment: Kai: could you write a unit test for this? -- nosy: +r.david.murray ___ Python tracker ___ ___ Pyt

[issue1028] Tkinter binding involving Control-spacebar raises unicode error

Tangaroa 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 main() File "/usr/lib/python3.1/idlelib/PyShell.py", line 1420, in main roo

[issue10041] socket.makefile(mode = 'r').readline() silently removes carriage return

kai zhu 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: ./pyth

[issue10041] socket.makefile(mode = 'r').readline() silently removes carriage return

kai zhu added the comment: updated unittest patch -- Added file: http://bugs.python.org/file19195/socket.makefile.with.unittest.v2.patch ___ Python tracker ___

[issue2953] _zip_directory_cache untested and undocumented

Changes by Éric Araujo : Removed file: http://bugs.python.org/file13625/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue2953] _zip_directory_cache untested and undocumented

Changes by Éric Araujo : Removed file: http://bugs.python.org/file13638/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue2953] _zip_directory_cache untested and undocumented

Éric Araujo added the comment: Could the recently-added functools.lru_cache help here? -- components: -Distutils nosy: +eric.araujo versions: +Python 3.2 ___ Python tracker ___

[issue4758] Python 3.x internet documentation needs work

Éric Araujo 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 “Documentati