[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Bill Janssen added the comment: Actually, when using setup.py with MinGW, you just need to say the right thing: % python setup.py build --compiler=mingw32 install That removes the check for vcvarsall.bat. Bill On Mon, Jan 2, 2012 at 6:19 AM, Piotr Dobrogost wrote: > > Piotr Dobrogost added the comment: > > @Lehmann > > You have to have either Visual Studio 2008 or Visual C++ Express 2008 > installed. The folder where vcvarsall.bat file is being looked for is read > from the registry. It's either > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC > (for Visual Studio) or > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VCExpress\9.0\Setup\VC (for > Visual C++ Express). > > -- > nosy: +piotr.dobrogost > > ___ > Python tracker > <http://bugs.python.org/issue2698> > ___ -- ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Bill Janssen added the comment: I'm guessing these things are due to interaction with some Apple security update, as the buildbots were working well 8 months ago. Bill On Wed, Sep 7, 2011 at 4:01 PM, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > If Bill gets a chance to investigate this before the weekend, great, > otherwise my plan to stop making noise in the buildbot results will be to: > > 1. Create a separate issue specifically for the errors reported by the Mac OS > X buildbots (allowing the problem to be spelled out more clearly for readers, > and also allowing the feature request itself to be closed) > > 2. Flag the offending tests as expected failures on Mac OS X, with a pointer > back to the new tracker issue. > > That way, if these failures are due to underlying OS bugs or limitations (as > they appear to be), we'll get a clear indication in the buildbots when Apple > have fixed the relevant problems. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue6560> > ___ > -- ___ Python tracker <http://bugs.python.org/issue6560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Bill Janssen added the comment: I'll take a look at this next week, when I'm more on-line again. Bill 2011/8/25 Charles-François Natali : > > Charles-François Natali added the comment: > >> The OS X buildbots show some failures: > > It seems to fail consistently on every OS X version. > I've had another look both at the code and the test, and couldn't find > anything wrong with it. > Since there are a number of known bugs pertaining to FD passing on OS X - > even on recent versions - I'd suggest to skip those tests on this platform. > As for sendto/sendmsg not being interrupted by the signal, I'd be curious to > see if running test_socket alone solves the problem (just to make sure no > other thread is running, which might receive the signal). > > -- > > ___ > Python tracker > <http://bugs.python.org/issue6560> > ___ > -- ___ Python tracker <http://bugs.python.org/issue6560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12765] test_packaging failure under Snow Leopard
Bill Janssen added the comment: I'm on vacation right now and can't get to it... Bill On Thu, Aug 18, 2011 at 12:22 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Bill is the owner of that buildbot. > > -- > nosy: +janssen > > ___ > Python tracker > <http://bugs.python.org/issue12765> > ___ > -- ___ Python tracker <http://bugs.python.org/issue12765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5117] os.path.relpath problem with root directory
Bill Janssen added the comment: Then we need to revert this patch and find one that works. -- resolution: fixed -> ___ Python tracker <http://bugs.python.org/issue5117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5117] os.path.relpath problem with root directory
Bill Janssen added the comment: Broke bunches of 2.7 buildbots. But why are we running test_ntpath on OS X, anyway? Shouldn't this be skipped everywhere except win32 platforms? -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue5117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Bill Janssen added the comment: PPC Tiger is using Python 2.7, so it's 3.6.11. Python 3.X also seems to be failing the sqlite tests on PPC Leopard. Is the required version # different between 3.1 and 3.x? -- ___ Python tracker <http://bugs.python.org/issue8845> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9455] platform test borked in 2.7 branch on Power PC
Bill Janssen added the comment: So the problem is in the _mac_ver_xml() routine in Lib/platform.py, which says: machine = os.uname()[4] if machine == 'ppc': # for compatibility with the gestalt based code machine = 'PowerPC' and perhaps should say: machine = os.uname()[4] if machine in ('ppc', 'Power Macintosh'): # for compatibility with the gestalt based code machine = 'PowerPC' -- ___ Python tracker <http://bugs.python.org/issue9455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9455] platform test borked in 2.7 branch on Power PC
Bill Janssen added the comment: This is on a PowerPC machine running Leopard: >>> os.uname()[4] 'Power Macintosh' >>> -- ___ Python tracker <http://bugs.python.org/issue9455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9455] platform test borked in 2.7 branch on Power PC
New submission from Bill Janssen : Looks like some test borked the 2.7 tests on the buildbots. Here's the offending test: test test_platform failed -- Traceback (most recent call last): File "/Users/buildbot/buildarea/2.7.parc-leopard-1/build/Lib/test/test_platform.py", line 196, in test_mac_ver self.assertEquals(res[2], 'PowerPC') AssertionError: 'Power Macintosh' != 'PowerPC' Re-running test 'test_platform' in verbose mode test_architecture (test.test_platform.PlatformTest) ... ok test_architecture_via_symlink (test.test_platform.PlatformTest) ... [17052 refs] [17052 refs] ok test_dist (test.test_platform.PlatformTest) ... ok test_java_ver (test.test_platform.PlatformTest) ... ok test_libc_ver (test.test_platform.PlatformTest) ... ok test_mac_ver (test.test_platform.PlatformTest) ... FAIL test_mac_ver_with_fork (test.test_platform.PlatformTest) ... ok test_machine (test.test_platform.PlatformTest) ... ok test_node (test.test_platform.PlatformTest) ... ok test_parse_release_file (test.test_platform.PlatformTest) ... ok test_platform (test.test_platform.PlatformTest) ... ok test_processor (test.test_platform.PlatformTest) ... ok test_release (test.test_platform.PlatformTest) ... ok test_sys_version (test.test_platform.PlatformTest) ... ok test_system (test.test_platform.PlatformTest) ... ok test_system_alias (test.test_platform.PlatformTest) ... ok test_uname (test.test_platform.PlatformTest) ... ok test_uname_win32_ARCHITEW6432 (test.test_platform.PlatformTest) ... skipped 'windows only test' test_version (test.test_platform.PlatformTest) ... ok test_win32_ver (test.test_platform.PlatformTest) ... ok == FAIL: test_mac_ver (test.test_platform.PlatformTest) -- Traceback (most recent call last): File "/Users/buildbot/buildarea/2.7.parc-leopard-1/build/Lib/test/test_platform.py", line 196, in test_mac_ver self.assertEquals(res[2], 'PowerPC') AssertionError: 'Power Macintosh' != 'PowerPC' -- Ran 20 tests in 6.468s FAILED (failures=1, skipped=1) test test_platform failed -- Traceback (most recent call last): File "/Users/buildbot/buildarea/2.7.parc-leopard-1/build/Lib/test/test_platform.py", line 196, in test_mac_ver self.assertEquals(res[2], 'PowerPC') AssertionError: 'Power Macintosh' != 'PowerPC' -- assignee: ronaldoussoren components: Library (Lib), Tests messages: 112516 nosy: janssen, ronaldoussoren priority: normal severity: normal status: open title: platform test borked in 2.7 branch on Power PC type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue9455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8447] buildbot: test_httpservers failure (No module named operator)
Bill Janssen added the comment: Failing on my PPC Tiger OS X buildbot, with 2.6, too. -- nosy: +janssen versions: +Python 2.6 ___ Python tracker <http://bugs.python.org/issue8447> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8621] uuid.uuid4() generates non-unique values on OSX
Bill Janssen added the comment: Stefan, I tried your suggestion of starting threading. Test still succeeds on my 10.5.8 system when test_uuid is run separately. Ronald, your fix works on my 10.5.8 system. Why not check it in, and let's see if the buildbots turn green again? -- ___ Python tracker <http://bugs.python.org/issue8621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9048] no OS X buildbots in the stable list
Bill Janssen added the comment: Bit of a chicken/egg issue here. Since we haven't had OS X buildbots for very long, and the ones we do have represent odd configurations, I think it's premature to say that "the port *doesn't* pass the test suite on a regular manner". I think it's just as reasonable to say that the developers making changes just aren't aware of bad side-effects on OS X. A good way to remedy that would be to make those bad side-effects more apparent, for example by adding an OS X buildbot into the "stable" set. Another issue is that none of the three OS X buildbots now running are really good representatives of the technology that most people I know who use OS X really use. That would be an Intel Core 2 Duo machine running Snow Leopard. -- ___ Python tracker <http://bugs.python.org/issue9048> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8621] uuid.uuid4() generates non-unique values on OSX
Bill Janssen added the comment: This is on an Intel machine running OS X 10.5.8. I downloaded and built 2.7rc2 from source with "./configure ; make". I then ran the tests with "make test". test_uuid fails with this output: test test_uuid failed -- Traceback (most recent call last): File "/private/tmp/Python-2.7rc2/Lib/test/test_uuid.py", line 472, in testIssue8621 self.assertNotEqual(parent_value, child_value) AssertionError: '751ca85de22f4450b7f95dd3f82c7e5f' == '751ca85de22f4450b7f95dd3f82c7e5f' However, when I run the test standalone with this command-line, it passes: % ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -l test_uuid test_uuid 1 test OK. Not sure what's going on. -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue8621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9052] 2.7rc2 fails test_urllib_localnet tests on OS X
New submission from Bill Janssen : % ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_urllib2_localnet == CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. build 5493)] == Darwin-9.8.0-i386-32bit little-endian == /private/tmp/Python-2.7rc2/build/test_python_58063 test_urllib2_localnet test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... ok test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ok test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... FAIL test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... FAIL test_200 (test.test_urllib2_localnet.TestUrlopen) ... ok test_200_with_parameters (test.test_urllib2_localnet.TestUrlopen) ... ok test_404 (test.test_urllib2_localnet.TestUrlopen) ... ok test_bad_address (test.test_urllib2_localnet.TestUrlopen) ... ok test_basic (test.test_urllib2_localnet.TestUrlopen) ... ok test_geturl (test.test_urllib2_localnet.TestUrlopen) ... ok test_info (test.test_urllib2_localnet.TestUrlopen) ... ok test_redirection (test.test_urllib2_localnet.TestUrlopen) ... ok test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ... ok == FAIL: test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) -- Traceback (most recent call last): File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 264, in test_proxy_with_bad_password_raises_httperror self.URL) AssertionError: HTTPError not raised == FAIL: test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) -- Traceback (most recent call last): File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 270, in test_proxy_with_no_password_raises_httperror self.URL) AssertionError: HTTPError not raised -- Ran 13 tests in 9.050s FAILED (failures=2) test test_urllib2_localnet failed -- multiple errors occurred 1 test failed: test_urllib2_localnet /tmp/Python-2.7rc2 397 % -- messages: 108314 nosy: janssen priority: high severity: normal stage: needs patch status: open title: 2.7rc2 fails test_urllib_localnet tests on OS X type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue9052> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9048] no OS X buildbots in the stable list
Changes by Bill Janssen : -- components: +None keywords: +buildbot versions: -Python 2.7 ___ Python tracker <http://bugs.python.org/issue9048> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9048] no OS X buildbots in the stable list
New submission from Bill Janssen : Considering the number of OS X machines running Python programs, it would be good idea to get this platform into the "stable" list of buildbots so that releases are checked against it. -- messages: 108302 nosy: janssen priority: normal severity: normal status: open title: no OS X buildbots in the stable list versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue9048> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8446] buildbot: DeprecationWarning not raised for icglue (test_py3kwarn.TestStdlibRemovals)
Bill Janssen added the comment: Not sure I understand this patch. Either the icglue module is removed in python 3, in which case it should raise the deprecation warning, or it is not, in which case it should be removed from the list of modules checked in test_py3kwarn. Shouldn't the patch also address one of these two cases? -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue8446> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python
Bill Janssen added the comment: It's fairly easy to create a restricted process tree for testing. ssh into a Mac which has no one logged into the console, from another machine, and use that connection to launch an xterm or Xemacs window to the other machine. Then log out of the ssh session. The session running in the xterm will now have no access privileges to the window server, and can be used for testing. -- ___ Python tracker <http://bugs.python.org/issue8716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python
Bill Janssen added the comment: [More info from Ronald Oussoren] This is a bug in Tk: >>> root = Tkinter.Tk() Thu May 13 20:45:13 Rivendell.local python[84887] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. >>> 2010-05-13 20:45:16.751 Python[84887:d07] An uncaught exception was raised 2010-05-13 20:45:16.762 Python[84887:d07] Error (1002) creating CGSWindow 2010-05-13 20:45:16.955 Python[84887:d07] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow' *** Call stack at first throw: ( 0 CoreFoundation 0x7fff85e31d24 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x7fff86f3 objc_exception_throw + 45 2 CoreFoundation 0x7fff85e31b47 +[NSException raise:format:arguments:] + 103 3 CoreFoundation 0x7fff85e31ad4 +[NSException raise:format:] + 148 4 AppKit 0x7fff84614aba _NSCreateWindowWithOpaqueShape2 + 473 5 AppKit 0x7fff845a9055 -[NSWindow _commonAwake] + 1214 6 AppKit 0x7fff845c6d3d -[NSWindow _makeKeyRegardlessOfVisibility] + 96 7 AppKit 0x7fff845c6cb2 -[NSWindow makeKeyAndOrderFront:] + 24 8 Tk 0x00010075b86c XMapWindow + 155 9 Tk 0x0001006ca6d0 Tk_MapWindow + 89 10 Tk 0x0001006d35e6 TkToplevelWindowForCommand + 2658 11 Tcl 0x0001006300d3 TclServiceIdle + 76 12 Tcl 0x0001006162ce Tcl_DoOneEvent + 329 13 _tkinter.so 0x000100595683 Tkapp_CallDeallocArgs + 277 14 readline.so 0x0001001f1f9a initreadline + 1280 15 Python 0x000176a1 PyOS_Readline + 239 16 Python 0x00018a57 PyTokenizer_FromString + 1322 17 Python 0x000190a0 PyTokenizer_Get + 154 18 Python 0x00015698 PyParser_AddToken + 1018 19 Python 0x0001000a2320 PyParser_ASTFromFile + 146 20 Python 0x0001000a443f PyRun_InteractiveOneFlags + 345 21 Python 0x0001000a4615 PyRun_InteractiveLoopFlags + 206 22 Python 0x0001000a4685 PyRun_AnyFileExFlags + 76 23 Python 0x0001000b0286 Py_Main + 2718 24 Python 0x00010e6c start + 52 25 ??? 0x0001 0x0 + 1 ) terminate called after throwing an instance of 'NSException' Abort trap This is running /usr/bin/python in a session as a user that doesn't have access to the GUI. The text above says that there is an uncaught ObjC exception, caused by the lack of a connection to the window server. Tk should have converted that to its own style of errors but didn't. -- ___ Python tracker <http://bugs.python.org/issue8716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python
New submission from Bill Janssen : test_tk fails on OS X if test is run from a daemon process without the privilege to access the window server, say a buildbot slave without anyone logged in to the console. The Tk support needs to check whether it has access rights to the window server before trying to access it. Workaround is to log buildbot into the console of the OS X machine (which usually but not always works), or to run tests manually. -- components: Tests, Tkinter messages: 105733 nosy: janssen priority: normal severity: normal stage: needs patch status: open title: test_tk fails on OS X if run from buildbot slave daemon -- crashes Python type: crash versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8552] msilib can't create large CAB files
Bill Janssen added the comment: Ah, found the size problem -- I was measuring something in 512 blocks not 1KB blocks. Never mind. -- ___ Python tracker <http://bugs.python.org/issue8552> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8552] msilib can't create large CAB files
Bill Janssen added the comment: Another bit of info. It's the frequent commits that seem to fix the problem; when I comment those out of the __del__ method, it fails as before. I also notice that the finished installer is about twice the size of the two data files in it (the CAB file and my zip file). Seems like a lot of overhead. -- ___ Python tracker <http://bugs.python.org/issue8552> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8552] msilib can't create large CAB files
Bill Janssen added the comment: I've now been able to build my installer. I applied Travis Oliphant's patch from http://bugs.python.org/issue2399 to Lib/msilib/__init__.py, then added a __del__ method to the Directory class: def __del__(self): if self._numfiles_wo_commit > 0: self.db.Commit() self.db = None self.keyfiles = None self.cab = None self.ids = None This seems to release enough memory that I can deal with a larger number of files. I don't think there's a good way to write a unit test for this, though. Success or failure will depend on the machine you're running it on, I think. -- ___ Python tracker <http://bugs.python.org/issue8552> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8552] msilib can't create large CAB files
Changes by Bill Janssen : Removed file: http://bugs.python.org/file17118/unnamed ___ Python tracker <http://bugs.python.org/issue8552> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8552] msilib can't create large CAB files
Bill Janssen added the comment: Yes, I've tried that. No joy. Right now I'm trying an approach which packages each top-level directory as a separate cab. What I'm finding is that if I get up around 4200 files, it breaks, regardless of the file sizes. Out of curiosity, how many files are in the Python MSI file? Bill On Tue, Apr 27, 2010 at 11:37 PM, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > > You could also try to commit the MSI file in-between, which may release > memory. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue8552> > ___ > -- Added file: http://bugs.python.org/file17118/unnamed ___ Python tracker <http://bugs.python.org/issue8552> ___Yes, I've tried that.  No joy.  Right now I'm trying an approach which packages each top-level directory as a separate cab.What I'm finding is that if I get up around 4200 files, it breaks, regardless of the file sizes.  Out of curiosity, how many files are in the Python MSI file? BillOn Tue, Apr 27, 2010 at 11:37 PM, Martin v. Löwis <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Martin v. Löwis <mailto:mar...@v.loewis.de";>mar...@v.loewis.de> added the comment: You could also try to commit the MSI file in-between, which may release memory. -- ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue8552"; target="_blank">http://bugs.python.org/issue8552> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8554] suspicious comment in msilib.py/__init__.py
New submission from Bill Janssen : Take a look at the first line of make_id(). What does that comment mean? Is the wrong line commented out? def make_id(str, add_num=True): #str = str.replace(".", "_") # colons are allowed -- components: Library (Lib), Windows messages: 104393 nosy: janssen, loewis priority: low severity: normal status: open title: suspicious comment in msilib.py/__init__.py versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8554> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8552] msilib can't create large CAB files
Bill Janssen added the comment: So, I subclassed msilib.CAB, and re-wrote commit() so that the CAB file is created in a different process, a la Tools/msi/msilib.py. Still have the same problem, though. So now I'm thinking it's not a memory problem, but I'm wondering if there's something about the length of the path names in the CAB file, or some such. -- ___ Python tracker <http://bugs.python.org/issue8552> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8552] msilib can't create large CAB files
Bill Janssen added the comment: Ummm, just in case the packager wanted to. In my case, I was putting the files which were registered as part of the installation in one CAB file, and another set of temporary files which were used by some of the installation scripts, but not part of the installation file set, in a second CAB file. I've since changed that second package to a zip file. -- ___ Python tracker <http://bugs.python.org/issue8552> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8552] msilib can't create large CAB files
New submission from Bill Janssen : I'm trying to create a CAB file containing about 69MB of data, in 4555 files. msilib fails in CAB.commit(): $ python build-msi-installer.py /c/UpLib/1.7.9 ~/uplib 1.7.9 ./uplib-1.7.9.msi c:\Documents and Settings\wjanssen\uplib\win32\uplib-1.7.9.msi install_location c:/UpLib/1.7.9 c:\docume~1\wjanssen\locals~1\temp\tmpu5dwz6 68943045 gc: collecting generation 0... gc: objects in each generation: 670 702 8255 gc: done, 0.s elapsed. gc: collecting generation 0... gc: objects in each generation: 707 1364 8255 gc: done, 0.s elapsed. gc: collecting generation 0... gc: objects in each generation: 699 2031 8255 gc: done, 0.s elapsed. gc: collecting generation 0... gc: objects in each generation: 794 2680 8255 gc: done, 0.s elapsed. gc: collecting generation 0... gc: objects in each generation: 730 3373 8255 gc: done, 0.s elapsed. gc: collecting generation 0... gc: objects in each generation: 765 4018 8255 gc: done, 0.s elapsed. gc: collecting generation 0... gc: objects in each generation: 741 4697 8255 gc: done, 0.s elapsed. (1, 4555, None, '#prereqs', None, None) Traceback (most recent call last): File "build-msi-installer.py", line 780, in p.run() File "build-msi-installer.py", line 243, in run self.add_files() File "build-msi-installer.py", line 312, in add_files cab.commit(self.db) File "c:\Python26\lib\msilib\__init__.py", line 223, in commit [(1, self.index, None, "#"+self.name, None, None)]) File "c:\Python26\lib\msilib\__init__.py", line 97, in add_data v = db.OpenView("SELECT * FROM `%s`" % table) _msi.MSIError: 1: 2229 2: c:\Documents and Settings\wjanssen\uplib\win32\uplib-1.7.9.msi 3: Media 4: SELECT * FROM `Media` gc: collecting generation 2... gc: objects in each generation: 416 5351 8254 gc: done, 0.s elapsed. $ (I added a bit of code to print out the Media table record, and the size of the file created with FCICreate.) This works fine if I choose a slightly smaller subset, such as /c/UpLib/1.7.9/lib, for instance. So I'm guessing this is a memory problem; at some point there's just not enough memory to open the MSI file and load the Media table. I opened the MSI file with orca and sure enough, there is no Media table in it. Not sure how to take that, though; perhaps the table only appears after a record has been written to it. Another reason to allow multiple CAB files in a single installer? -- components: Library (Lib), Windows messages: 104379 nosy: janssen, loewis priority: normal severity: normal status: open title: msilib can't create large CAB files type: resource usage versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8552> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3216] Scarce msilib documentation
Bill Janssen added the comment: Here's another one: class Directory shows an extra arg, "component", which isn't in the code. -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue3216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8526] msilib doesn't support multiple CAB instances in same installer
Bill Janssen added the comment: I'm certainly using the API provided by msilib, but perhaps I'm using it badly. Which API did you have in mind? I'm using msilib directly, not through bdist_msi. This seems like an artificial limitation to put on the Python library; the standard MSI spec supports 65K different cabs in a single installer. -- ___ Python tracker <http://bugs.python.org/issue8526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8526] msilib doesn't support multiple CAB instances in same installer
New submission from Bill Janssen : Working with Python 2.6.5, I find I cannot put multiple CABs in the same installer. This is due to this statement in msilib.CAB.commit(): add_data(db, "Media", [(1, self.index, None, "#"+self.name, None, None)]) The key, 1, must be different for each record in the 'Media' table. The symptom is an exception something like this: _msi.MSIError: Could not insert [(1, 3, None, '#foo', None, None)] into Media -- assignee: loewis components: Distutils, Library (Lib), Windows keywords: easy messages: 104135 nosy: janssen, loewis severity: normal status: open title: msilib doesn't support multiple CAB instances in same installer versions: Python 2.6, Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1128] msilib.Directory.make_short only handles file names with a single dot in them
Bill Janssen added the comment: Here's how Microsoft does it: http://support.microsoft.com/kb/142982/en-us -- ___ Python tracker <http://bugs.python.org/issue1128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7639] bdist_msi fails on files with long names
Bill Janssen added the comment: This looks a lot like bug 1128, too. I think the patch there would also fix this one. -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue7639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1128] msilib.Directory.make_short only handles file names with a single dot in them
Bill Janssen added the comment: So what happens if the original file name is something like "foo~1.txt"? Couldn't there be a name collision? -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue1128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
Bill Janssen added the comment: Looks like a good idea. -- ___ Python tracker <http://bugs.python.org/issue8222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2445] Use The CygwinCCompiler Under Cygwin
Bill Janssen added the comment: Shouldn't the import library name end with .lib? I've run up against this building PyLucene with MinGW. There seems to be code to figure this out already in CygwinCCompiler, but it's commented out (and arguably incomplete). -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue2445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Bill Janssen added the comment: My bad. Adding --compiler=mingw32 eliminates this error. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Bill Janssen added the comment: Re-opening. -- keywords: +26backport priority: high -> normal resolution: invalid -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Bill Janssen added the comment: I'm seeing this on Python 2.6.4 on Windows XP with the latest MinGW/msys. -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8108] test_ftplib fails with OpenSSL 0.9.8m
Bill Janssen added the comment: >> Depends on what we want. It just suppresses information that's now >> available. What we'd really like is for the caller to recognize that >> close() can fail, and should be re-tried if it does. That requires >> that we signal the error back up and out of the ssl module. It seems >> to me that any non-blocking code should recognize this and respect it. > Well, first, it will break code which used to work perfectly well (as > the > failing tests show). That OpenSSL decided to break compatibility > in what looks like a minor bugfix release (0.9.8m) doesn't mean we > should propagate the breakage. I admit to being powerfully swayed by this argument. Of course, you could also say that it exposes bugs in code which hasn't been tested enough. Again, look at where this stack trace is coming from. It's a default error handler in code that was written 10 years ago. Perhaps that code needs more than just a default error handler; perhaps the handler in FTP_TLS should be more sophisticated. > Second, I'm not an SSL expert, but it's not obvious to me that the > application should have to ensure a "complete shutdown" before > closing the socket. Often, stateful applicative protocols close > their "session" anyway (*) before shutting down the transport layer, > so I don't see what this additional precaution can buy > (apart from code complication). What it buys is the ability for careful code to properly shut down an SSL session when using non-blocking sockets. If we apply the fix, we deny that, and I'm sure someone will immediately file a bug about it :-). -- ___ Python tracker <http://bugs.python.org/issue8108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8108] test_ftplib fails with OpenSSL 0.9.8m
Bill Janssen added the comment: > Maybe because only the FTP test uses an SSL socket in non blocking mode. No, the SSL unit tests also do this. I think Giampaolo is right, what we're seeing is bad error handling in the FTP test code. -- ___ Python tracker <http://bugs.python.org/issue8108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8108] test_ftplib fails with OpenSSL 0.9.8m
Bill Janssen added the comment: > AFAICT, his proposed "quick fix" snippet should be good enough for us. Depends on what we want. It just suppresses information that's now available. What we'd really like is for the caller to recognize that close() can fail, and should be re-tried if it does. That requires that we signal the error back up and out of the ssl module. It seems to me that any non-blocking code should recognize this and respect it. Again, why does this failure only show up in the FTP test? Why aren't we seeing it elsewhere? -- ___ Python tracker <http://bugs.python.org/issue8108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8108] test_ftplib fails with OpenSSL 0.9.8m
Bill Janssen added the comment: And it would be interesting to know why all the SSL module tests don't fail in the same way. -- ___ Python tracker <http://bugs.python.org/issue8108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8108] test_ftplib fails with OpenSSL 0.9.8m
Bill Janssen added the comment: I think Giampaolo is right about this not being an ssl.py issue. Could the exception handling in ftp.py perhaps also be made more sophisticated? I'd really love to understand what the state of the TCP connection is here. I'm presuming that it's still open, because otherwise you'd get a different error from OpenSSL. So what's the error that's triggering this call? Is it simply that the sender has run out of stuff to send? Also, I think that asyncore.py is stingy about what information it sends. At the very least, it could invoke handle_error() with the exception it's handling as an argument. -- ___ Python tracker <http://bugs.python.org/issue8108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8108] test_ftplib fails with OpenSSL 0.9.8m
Bill Janssen added the comment: Looking at this further, what we're seeing is the trace of an ineffective attempt to handle an exception presumably raised from the FTP code. Can we see that exception? What's the actual state of the TCP connection at this point? -- ___ Python tracker <http://bugs.python.org/issue8108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8108] test_ftplib fails with OpenSSL 0.9.8m
Bill Janssen added the comment: What's happening is that the new state returns from SSL_shutdown() are saying, "the shutdown you asked for didn't happen this time, but call me again when you get a chance. And here is a hint about why it didn't happen, so that if you are sophisticated enough, you can get better information about whether subsequent calls to shutdown() will succeed." Given the underlying architectures we are dealing with, is it possible to handle this properly? Basically, what the SSL_shutdown code is saying is that all higher-level event loops should understand an additional kind of event, "shutting down the SSL socket", on a par with "read bytes" and "write bytes". But our event processing handlers, like asyncore, basically only deal with read and write. I don't see how to tell them that a "close" operation should turn into a "read" or "write". We could also think about turning non-blocking sockets into blocking sockets, by adding a time.sleep(0.1) and re-calling SSL_shutdown(). But maybe the right thing to do would be for the write handler in the asyncore loop to catch this, and re-try the write when it gets a chance. -- ___ Python tracker <http://bugs.python.org/issue8108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8108] test_ftplib fails with OpenSSL 0.9.8m
Bill Janssen added the comment: Victor, I'll take a look. -- ___ Python tracker <http://bugs.python.org/issue8108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7672] _ssl module causes segfault
Bill Janssen added the comment: Martin, I'm thinking that the module object has a __del__ method, and we could un-register the callbacks there. But I don't know if that method would ever get called. How does the act of "unloading a library" interact with the initialized Python interpreter? -- ___ Python tracker <http://bugs.python.org/issue7672> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
Bill Janssen added the comment: On Tue, Sep 29, 2009 at 12:47 PM, Giampaolo Rodola' wrote: > > Giampaolo Rodola' added the comment: > > Uhm... I'm sorry but actually I'm not sure about this patch anymore. > Now that I look at ssl.py again I'm noticing that send() is trapped in a > "while True" loop as well and the patch doesn't cover it. > > Not sure if that has been added recently or it was already there at the > time I submitted the report but it's another thing that need to be > fixed. > > > Moreover, I'm sure that removing the "while" loop is good for non- > blocking sockets but what about blocking ones? > Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised > in a blocking environment? > No. > If they aren't then the current patch just needs to take care of send() > method too, then it's fine. > Yes, it's fine. Bill -- Added file: http://bugs.python.org/file15010/unnamed ___ Python tracker <http://bugs.python.org/issue3890> ___On Tue, Sep 29, 2009 at 12:47 PM, Giampaolo Rodola' <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Giampaolo Rodola' <mailto:billiej...@users.sourceforge.net";>billiej...@users.sourceforge.net> added the comment: Uhm... I'm sorry but actually I'm not sure about this patch anymore. Now that I look at ssl.py again I'm noticing that send() is trapped in a "while True" loop as well and the patch doesn't cover it. Not sure if that has been added recently or it was already there at the time I submitted the report but it's another thing that need to be fixed. Moreover, I'm sure that removing the "while" loop is good for non- blocking sockets but what about blocking ones? Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised in a blocking environment?No. If they aren't then the current patch just needs to take care of send() method too, then it's fine.Yes, it's fine.Bill ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
Bill Janssen added the comment: I wonder if there is any way to test this, aside from the tests that are already in the test suite? The bug here is that the code effectively does a blocking read on a non-blocking socket, and we can't tell the difference. The fact that this patch passes all the existing tests and also seems to be a fix (through inspection) may have to be sufficient. After all, the tests for the previous SSL support (Python 2.5 and earlier) were extremely sketchy. -- ___ Python tracker <http://bugs.python.org/issue3890> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4033] python search path - .pth recursion
Bill Janssen added the comment: Looks like 1431 was closed by removing a line from the documentation, so it's not surprising that it's not clear. -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue4033> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6587] interrupts during long writes cause connection corruption with SSL module
New submission from Bill Janssen : The behavior when a write or send is interrupted is suboptimal. If the write buffer moves before a retry is attempted in response to SSL_ERROR_WANT_OUTPUT, OpenSSL rejects the retry attempt. See http://www.mail-archive.com/openssl-us...@openssl.org/msg07806.html. Looks like a simple fix. -- assignee: janssen messages: 90999 nosy: janssen priority: high severity: normal stage: needs patch status: open title: interrupts during long writes cause connection corruption with SSL module type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue6587> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4848] MacPython build script uses Carbon and MacOS modules slated for removal
Bill Janssen added the comment: Looks good. The contrast is stark. ___ Python tracker <http://bugs.python.org/issue4848> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4471] IMAP4 missing support for starttls
Bill Janssen added the comment: I brought this up on pydotorg, and Barry suggests that someone put together a Twisted environment which could be downloaded and run locally on the test machine. It would provide IMAP and POP servers, perhaps NNTP and others as well. Now, all we need is someone to make that happen :-). ___ Python tracker <http://bugs.python.org/issue4471> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1978] Python(2.5.1) will be crashed when i use _ssl module in multi-threads environment in linux.
Bill Janssen added the comment: Yes, the reason is that the supplied patch doesn't provide enough test cases. This is a big patch; 2.5.x is a bug-fix release; a newer version of the SSL code is available from PyPI as a work-around; I don't have time right now to write more tests myself. All of which means that I won't look at it more till the patch (or another patch) includes more test cases. ___ Python tracker <http://bugs.python.org/issue1978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4471] IMAP4 missing support for starttls
Bill Janssen added the comment: Why can't we use python.org for tests? Do we need IMAP/POP servers running? Let's send some mail to pydotorg to get that set up. ___ Python tracker <http://bugs.python.org/issue4471> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2437] Distutils runtime_library_dirs broken on Windows
Bill Janssen added the comment: Tarek writes: > Laurent, right. but we need to figure out how to get the CC name in > MinGW/Cygwin environment. > I am not familiar with them. Since this bug is specifically about that environment, shouldn't it be handled by someone who is familiar with them? Not objecting, here, but it seems unlikely to result in a rapid fix. And MinGW and Cygwin are pretty different, IMHO; don't mix them together here. ___ Python tracker <http://bugs.python.org/issue2437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2437] Distutils runtime_library_dirs broken on Windows
Bill Janssen added the comment: No, Tarek, I don't have a MinGW machine right now. But it should be easy to reproduce; just invoke that call I originally reported. The distutils code is just making assumptions that it shouldn't be making. ___ Python tracker <http://bugs.python.org/issue2437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5238] ssl makefile never closes socket
Bill Janssen added the comment: I'd recommend running the whole suite of tests here. The issue is mainly with httplib, as I recall it, which "closes" the socket before it finishes reading from it. ___ Python tracker <http://bugs.python.org/issue5238> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4471] IMAP4 missing support for starttls
Bill Janssen added the comment: Lorenzo, do we have test cases for this? I think you should try to add some test cases. We may need to set up some test mail servers on python.org to accommodate such tests. -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue4471> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
Bill Janssen added the comment: Well, maybe he found something -- never reported back. But it was a few months ago... I'm in no hurry to close it, though. ___ Python tracker <http://bugs.python.org/issue1251> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4870] ssl module is missing SSL_OP_NO_SSLv2
Bill Janssen added the comment: Actually, that's not quite true. Specifying TLSv1 or SSLv3 on the server side will disable SSLv2. However, there's currently no way to specify SSLv3 *or* TLSv1 *but not* SSLv2. This looks easy to fix; I'll add another entry to the list of protocol versions, which when selected will cause the server to use SSLv23, but will cause SSLv2 clients to be rejected. -- assignee: -> janssen resolution: -> accepted stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue4870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4848] MacPython build script uses Carbon and MacOS modules slated for removal
New submission from Bill Janssen : The build script for a Mac OS installer, in Mac/BuildScript/build-installer.py, currently requires OS 10.4 and Python 2.3. At some point it will have to be ported to a newer version of Python (and Mac OS). It uses a number of modules which are slated for future removal, particularly Carbon and MacOS. These modules are only used in the function "setIcon". They can be replaced with a call to a Cocoa method via PyObjC. The "setIcon" function using PyObjC would look like this: def setIcon(folder, imagefile): try: import os, AppKit AppKit.NSApplicationLoad() # initialize Cocoa return AppKit.NSWorkspace.sharedWorkspace().setIcon_forFile_options_( AppKit.NSImage.alloc().initWithContentsOfFile_(imagefile), os.path.abspath(folder), 0) except ImportError: return False -- components: Build, Macintosh messages: 79169 nosy: janssen priority: low severity: normal status: open title: MacPython build script uses Carbon and MacOS modules slated for removal type: feature request versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4848> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
Bill Janssen <[EMAIL PROTECTED]> added the comment: Unrelated? OK, but in fact I fixed this in 3.0 by providing a different internal API to _ssl.c. But you're right, that's an optimization. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3890> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
Bill Janssen <[EMAIL PROTECTED]> added the comment: Thanks for the patch. It looks pretty good to me, but I can't help thinking that there must be a better way of handling the recv() case; I don't like copying that buffer several times (from the SSL code to Python, from the Python to the buffer). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3890> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4171] SSL handshake fails after TCP connection in getpeername()
Changes by Bill Janssen <[EMAIL PROTECTED]>: -- assignee: -> janssen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
Bill Janssen <[EMAIL PROTECTED]> added the comment: I agree, too. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3890> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1210] imaplib does not run under Python 3
Bill Janssen <[EMAIL PROTECTED]> added the comment: Maybe the first thing to do is to expand the Lib/test/test_imaplib.py file, which right now is pretty darn minimal. We really need an IMAP server somewhere to test against, with a standard library of varied messages. Perhaps Python.org is running an IMAP server? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1210] imaplib does not run under Python 3
Bill Janssen <[EMAIL PROTECTED]> added the comment: Victor, what kind of content have you tried this with? For instance, have you passed unencoded (Content-Transfer-Encoding: binary) binary data through it, by mailing a JPEG, for instance? These things are strings really only at the application level; the data is still bytes. In addition, the use of Latin-1 goes against the explicit directives of the IMAP group, doesn't it? They're pushing UTF-8. Bill On Tue, Oct 14, 2008 at 4:27 AM, STINNER Victor <[EMAIL PROTECTED]>wrote: > > STINNER Victor <[EMAIL PROTECTED]> added the comment: > > Here is a patch for imaplib: > - add encoding attribute to IMAP4 class (as ftplib and see also issue > 3727 for my poplib patch) > - use makefile('r', encoding=self.encoding) instead of a binary file > (mode='rb') > - remove duplicate code in IMAP4_SSL > > I choosed ISO-8859-1 as the default charset. I tested the library on > my local IMAP4 server using IMAP4 and IMAP4_SSL classes. But the > library needs more unit tests as done for poplib. > > -- > keywords: +patch > nosy: +haypo > Added file: http://bugs.python.org/file11786/imaplib_unicode.patch > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1210> > ___ > Added file: http://bugs.python.org/file11790/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1210> ___Victor, what kind of content have you tried this with? For instance, have you passed unencoded (Content-Transfer-Encoding: binary) binary data through it, by mailing a JPEG, for instance? These things are strings really only at the application level; the data is still bytes. In addition, the use of Latin-1 goes against the explicit directives of the IMAP group, doesn't it? They're pushing UTF-8. BillOn Tue, Oct 14, 2008 at 4:27 AM, STINNER Victor <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: STINNER Victor <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: Here is a patch for imaplib: - add encoding attribute to IMAP4 class (as ftplib and see also issue 3727 for my poplib patch) - use makefile('r', encoding=self.encoding) instead of a binary file (mode='rb') - remove duplicate code in IMAP4_SSL I choosed ISO-8859-1 as the default charset. I tested the library on my local IMAP4 server using IMAP4 and IMAP4_SSL classes. But the library needs more unit tests as done for poplib. -- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file11786/imaplib_unicode.patch"; target="_blank">http://bugs.python.org/file11786/imaplib_unicode.patch ___ Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue1210"; target="_blank">http://bugs.python.org/issue1210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2276] distutils out-of-date for runtime_library_dirs flag on OS X
Bill Janssen <[EMAIL PROTECTED]> added the comment: Yes, we were looking at using this for linking PyLucene's JCC extension. I believe we came up with a different way of doing it. It would still be useful to have distutils.unixccompiler.runtime_library_dir_option() updated to understand the right flags for Leopard. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2276> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3991] urllib.request.urlopen does not handle non-ASCII characters
Bill Janssen <[EMAIL PROTECTED]> added the comment: I'm not concerned about any example inputs. I was just trying to explain why this isn't a bug. On the other hand, the IRI spec (RFC 3897) is another thing we might try to implement for Python. -- type: -> feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3991] urllib.request.urlopen does not handle non-ASCII characters
Bill Janssen <[EMAIL PROTECTED]> added the comment: It's not immediately clear to me how an auto-quote function can be written; as you say (and as the URI spec points out), you have to take a URL apart before quoting it, and you can't parse an invalid URL, which is what the input is. Best to think of this as a difference from 2.x. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3991] urllib.request.urlopen does not handle non-ASCII characters
Bill Janssen <[EMAIL PROTECTED]> added the comment: As I read RFC 2396, 1.5: "A URI is a sequence of characters from a very limited set, i.e. the letters of the basic Latin alphabet, digits, and a few special characters." 2.4: "Data must be escaped if it does not have a representation using an unreserved character; this includes data that does not correspond to a printable character of the US-ASCII coded character set, or that corresponds to any US-ASCII character that is disallowed, as explained below." So your URL string is invalid. You need to escape the characters properly. (RFC 2396 is what the HTTP RFC cites as its authority on URLs.) -- nosy: +janssen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3910] 2.6 regression in socket.ssl method
Bill Janssen <[EMAIL PROTECTED]> added the comment: OK, I found the fix. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3910> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3910] 2.6 regression in socket.ssl method
Bill Janssen <[EMAIL PROTECTED]> added the comment: Maybe not. test_ssl hangs when I run it "-u all -v". It's hanging on testSimpleSSLWrap. This is on OS X 10.5.5. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3910> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3910] 2.6 regression in socket.ssl method
Bill Janssen <[EMAIL PROTECTED]> added the comment: Will do. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3910> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3899] test_ssl.py doesn't properly test ssl integration with asyncore
Bill Janssen <[EMAIL PROTECTED]> added the comment: Sure, no argument. I was just making clear what was going on. Bill On Thu, Sep 18, 2008 at 7:33 PM, Josiah Carlson <[EMAIL PROTECTED]>wrote: > > Josiah Carlson <[EMAIL PROTECTED]> added the comment: > > Being able to test the async features of both sides of the SSL > connection is a good thing. > > Also, the subclass provides a useful example for users who want to use > asyncore and ssl servers without blocking on an incoming connection. > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue3899> > ___ > Added file: http://bugs.python.org/file11528/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3899> ___Sure, no argument. I was just making clear what was going on.BillOn Thu, Sep 18, 2008 at 7:33 PM, Josiah Carlson <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Josiah Carlson <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: Being able to test the async features of both sides of the SSL connection is a good thing. Also, the subclass provides a useful example for users who want to use asyncore and ssl servers without blocking on an incoming connection. ___ Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue3899"; target="_blank">http://bugs.python.org/issue3899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3910] 2.6 regression in socket.ssl method
Bill Janssen <[EMAIL PROTECTED]> added the comment: Looks OK to me. I think this is a back-port problem from 3.0. I'll put it in if no one objects. -- assignee: -> janssen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3910> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3899] test_ssl.py doesn't properly test ssl integration with asyncore
Bill Janssen <[EMAIL PROTECTED]> added the comment: The server wasn't meant to be non-blocking. The non-blocking test is performed when the client (which is non-blocking) connects to it. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2574] Add RFC 3768 SSM Multicast support to "socket"
Bill Janssen <[EMAIL PROTECTED]> added the comment: On Wed, Sep 17, 2008 at 10:45 AM, bms <[EMAIL PROTECTED]> wrote: > > Exercising the API fully requires an SSM capable multicast LAN. > Let's hope the PARC network is still up-to-date. It was when we were developing multicast here some 15-20 years ago :-). Bill Added file: http://bugs.python.org/file11512/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2574> ___On Wed, Sep 17, 2008 at 10:45 AM, bms <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Exercising the API fully requires an SSM capable multicast LAN. Let's hope the PARC network is still up-to-date. It was when we were developing multicast here some 15-20 years ago :-).Bill ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2574] Add RFC 3768 SSM Multicast support to "socket"
Bill Janssen <[EMAIL PROTECTED]> added the comment: I tried applying this patch to a clean SVN checkout of the 2.6 trunk on an OS X Leopard machine and it works (except for the part which patches configure.in). I then built the source tree and ran the test_socket test, which also worked fine. I don't see any tests for the specific functionality in the patch, or any patch to the documentation of the socket module. -- nosy: +janssen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2574> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
Bill Janssen <[EMAIL PROTECTED]> added the comment: I think that, where it's appropriate, you can do that. Just don't put it in the SSL module. Bill On Wed, Sep 10, 2008 at 11:24 PM, Heikki Toivonen <[EMAIL PROTECTED]>wrote: > > Heikki Toivonen <[EMAIL PROTECTED]> added the comment: > > Ok, thank you for clarifications. Now I understand why the hostname > checking isn't the solution that fits every problem. I am still not > completely clear how you'd do the checking otherwise, for example to > verify the service you are talking to is what you think it is. > > But still, I think dealing with email servers is another common use case > where hostname check is adequate most of the time. I am sure there are > other cases like this. Therefore I am still of the opinion that the > default should be to do the hostname check. Yes, make it overridable, > but doing the check is safer than not doing any checking IMO because > even if the check is incorrect for a certain purpose the developer is > likely to notice an error quickly and inclined to do some other security > check instead of not doing anything and thinking they have a secure system. > > If you want to continue the discussion, we should maybe take this to > some other forum, like comp.lang.python. > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1589> > ___ > Added file: http://bugs.python.org/file11463/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1589> ___I think that, where it's appropriate, you can do that. Just don't put it in the SSL module.BillOn Wed, Sep 10, 2008 at 11:24 PM, Heikki Toivonen <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Heikki Toivonen <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: Ok, thank you for clarifications. Now I understand why the hostname checking isn't the solution that fits every problem. I am still not completely clear how you'd do the checking otherwise, for example to verify the service you are talking to is what you think it is. But still, I think dealing with email servers is another common use case where hostname check is adequate most of the time. I am sure there are other cases like this. Therefore I am still of the opinion that the default should be to do the hostname check. Yes, make it overridable, but doing the check is safer than not doing any checking IMO because even if the check is incorrect for a certain purpose the developer is likely to notice an error quickly and inclined to do some other security check instead of not doing anything and thinking they have a secure system. If you want to continue the discussion, we should maybe take this to some other forum, like comp.lang.python. ___ Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue1589"; target="_blank">http://bugs.python.org/issue1589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Bill Janssen <[EMAIL PROTECTED]> added the comment: Sure -- but the point of the SSL module was to do something small and compatible with the existing socket.ssl module; I really don't want to get into a full-fledged Python interface to OpenSSL. Perhaps incremental progress would be OK... ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Bill Janssen <[EMAIL PROTECTED]> added the comment: Thanks, Simon. I remember digging through all this last year, and finally deciding to keep things simple and use the strategy the current codebase uses. It almost sounds like we'd need to create Key and Certificate objects in the _ssl module, which could be used to load up all the keys and/or certificates the server uses, before it changes UID (and presumbably loses access to the files the data is kept in). I was resisting going down that path; there's a lot of complexity there I want to avoid. But much of the mechanism of a Certificate object is already there; perhaps adding an opaque Key object wouldn't be too bad. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
Bill Janssen <[EMAIL PROTECTED]> added the comment: Sorry to be so brief there -- I was off on vacation. Verifying hostnames is a prescription that someone (well, OK, Eric Rescorla, who knows what he's talking about) put in the https IETF RFC (which, by the way, is only an informational RFC, not standards-track). It's a good idea if you're a customer trying to talk to Wells-Fargo, say, over an https connection, but isn't suitable for all https traffic. I support putting it in the httplib Https class by default, but there should be a way to override it, as there is with the Java APIs for https connections. (Take a look at javax.net.ssl.HostnameVerifier; one of the more popular Java classes at PARC is a version of this that verifies any hostname). So what's wrong with it? There are two problems. The first is that certificates for services are all about the hostname, and that's just wrong. You should verify the specific service, not just the hostname. So a client that really cares about what they are talking to should have the certificate for that service, and verify that it is the service it's talking to, and ignore the hostname in the URL. But the larger problem is that hostnames are a DNS construct for humans, and not really well supported on computers, or by the services that run on those computers. Most computers have only the haziest notion of what their hostname is, and many have lots of different hostnames (my laptop has at least five hostnames that I know of, all meaning the same computer, but with five different PARC IP addresses). So the services running on that computer aren't real clear about their hostnames, either. If I run a service on that computer that I secure with SSL, so that packets going over my WiFi are encrypted, which hostname should that service declare itself to be in the certificate? And the services on that computer keep running, even when it switches its IP address (and thus its set of hostnames). So doing hostname matching provokes lots of false negatives, especially when it's not needed. I think it by and large isn't a good idea, though I support having it (in an overrideable form) for the client-side https class in httplib. This is all exacerbated by the fact that HTTP isn't what it was when Eric wrote that RFC eight years ago. The growth of Web 2.0 and "RESTful" services means that lots of new things are using https in a much less formal way, more to get encrypted packets than to verify endpoints. So false negatives caused by mindless hostname verification cause real damage. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Changes by Bill Janssen <[EMAIL PROTECTED]>: -- resolution: -> accepted ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3805] sslobj.read py3k takes odd arguments
Bill Janssen <[EMAIL PROTECTED]> added the comment: But I should say... Greg, I do appreciate the review and the comments. I was waiting for the bytes work in 3K to settle down before looking at that code again. When I do, I'll take your comments to heart. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3805] sslobj.read py3k takes odd arguments
Changes by Bill Janssen <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11446/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3805] sslobj.read py3k takes odd arguments
Bill Janssen <[EMAIL PROTECTED]> added the comment: Please, guys, let's not deep-end on this. It's an admittedly eccentric but working and purely internal interface. There are actual release-blockers that need to be addressed. On Tue, Sep 9, 2008 at 4:14 AM, Amaury Forgeot d'Arc <[EMAIL PROTECTED] > wrote: > > Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > > The same function has two distinct behaviours: > - If you pass a number, it return a bytes object. > - If you pass a buffer, it returns a number! > Different arguments and different return types: they should have > different names IMO. > > io.py proposes read(n) and readinto(buf) for this distinction, and I > fail to see a reason why PySSL_SSLread need to be different: > > - readinto(buf, count=-1) could be similar to the actual PySSL_SSLread. > the "count" defaults to len(buf). > - read(count) could be implemented in C or python (or not at all), it is > equivalent to: >def read(self, count=1024): >buf = bytearray(count) >nb = self.readinto(buf) >return bytes(buf[:nb]) > > -- > nosy: +amaury.forgeotdarc > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue3805> > ___ > Added file: http://bugs.python.org/file11446/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3805> ___Please, guys, let's not deep-end on this. It's an admittedly eccentric but working and purely internal interface. There are actual release-blockers that need to be addressed. On Tue, Sep 9, 2008 at 4:14 AM, Amaury Forgeot d'Arc <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Amaury Forgeot d'Arc <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: The same function has two distinct behaviours: - If you pass a number, it return a bytes object. - If you pass a buffer, it returns a number! Different arguments and different return types: they should have different names IMO. io.py proposes read(n) and readinto(buf) for this distinction, and I fail to see a reason why PySSL_SSLread need to be different: - readinto(buf, count=-1) could be similar to the actual PySSL_SSLread. the "count" defaults to len(buf). - read(count) could be implemented in C or python (or not at all), it is equivalent to: def read(self, count=1024): buf = bytearray(count) nb = self.readinto(buf) return bytes(buf[:nb]) -- nosy: +amaury.forgeotdarc ___ Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue3805"; target="_blank">http://bugs.python.org/issue3805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3805] sslobj.read py3k takes odd arguments
Changes by Bill Janssen <[EMAIL PROTECTED]>: -- priority: high -> low ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3805] sslobj.read py3k takes odd arguments
Bill Janssen <[EMAIL PROTECTED]> added the comment: There was a reason to do it that way. Now if I can only remember what it was... ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.
Bill Janssen <[EMAIL PROTECTED]> added the comment: And for the 3K branch. Thanks! -- resolution: accepted -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3162> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.
Bill Janssen <[EMAIL PROTECTED]> added the comment: I've applied Simon's patch to the 2.6 trunk. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3162> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.
Bill Janssen <[EMAIL PROTECTED]> added the comment: Re: nomenclature I think this is partly a design bug on my part, supporting the old pre-2.6 "read" and "write" methods on the SSL context. Users should really call "makefile" to get something they can "read" and "write"; those methods should, in 2.6, only be internal, and not exposed outside the class. Of course, that would complicate the socket.ssl compatibility code. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3162> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1291446] SSLObject breaks read semantics
Bill Janssen <[EMAIL PROTECTED]> added the comment: Ah, sorry. I was looking at the 2.6 documentation, not the 2.5 documentation. In 2.6 (which is what the new SSL code is for), documentation of socket.ssl has been removed entirely, along with the text that you cite, although the functionality from 2.5 socket.ssl is still provided for backwards compatibility. In 2.6, the ssl.SSLSocket type is a subclass of socket.socket, so you call "makefile" on it to get a file-like object for reading and writing. If you'd like to submit a patch for 2.5 and 2.6, I think this is backwards-compatible enough to qualify as a fix, not a feature enhancement. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1291446> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.
Bill Janssen <[EMAIL PROTECTED]> added the comment: Simon, thanks, this patch looks good to me (2.6 only, right?). I'll try it out and report back. If it looks good, I'll commit it. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3162> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1291446] SSLObject breaks read semantics
Bill Janssen <[EMAIL PROTECTED]> added the comment: The way I read the documentation, file.read() (and that's what we're talking about) is still not guaranteed to read all the bytes of the file. But, you're right, that is the accepted semantics. So the documentation should change, too. However, the "read" method on an SSLSocket, which is not a file() subclass, is *not* guaranteed to return N bytes, it's guaranteed to return at most N bytes. Call "makefile" on SSLSocket if you need a file-like object. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1291446> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1210] imaplib does not run under Python 3
Bill Janssen <[EMAIL PROTECTED]> added the comment: Take a look at the thread here: http://mailman2.u.washington.edu/mailman/htdig/imap-protocol/2008-February/000811.html I think the summary is, arbitrary bytes may occur in some places, but they're likely to be UTF-8. Otherwise, it's mainly ASCII, but purposely left vague to see what convention developed. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com