Re: [Python-Dev] Who understands _ssl.c on Windows?
Tim Peters [EMAIL PROTECTED] writes: _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary when socketmodule.c is compiled, but (for some unknown reason) only to a 4-byte boundary when _ssl.c is compiled. Although that seems to match the details in the bug report, I have no theory for how that could happen (I don't see any MS packing pragmas anywhere). Well, poking a bit reveals that _ssl and _socket are built by quite different mechanisms: _socket by a .vcproj but _ssl by _ssl.mak. I don't see anything overly suspicious in _ssl.mak, but I don't really know much about Windows compiler options... Cheers, mwh -- so python will fork if activestate starts polluting it? I find it more relevant to speculate on whether Python would fork if the merpeople start invading our cities riding on the backs of giant king crabs. -- Brian Quinlan, comp.lang.python ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The i string-prefix: I18n'ed strings
On Saturday 08 April 2006 1:05 am, Barry Warsaw wrote: On Sat, 2006-04-08 at 00:45 +0200, Martin v. Löwis wrote: *Never* try to do i18n that way. Don't combine fragments through concatenation. Instead, always use placeholders. Martin is of course absolutely right! If you have many fragments, the translator gets the challenge of translating dollars. Now, this might need to be translated differently in different contexts (and perhaps even depending on the value of balance); the translator must always get the complete message as a single piece. Plus, if you have multiple placeholders, the order may change in some translations. I haven't been following this discussion, so something similar may already have been mentioned. The way Qt handles this is to use %1, %2 etc as placeholders. The numbers refer to the arguments (the order of which is obviously fixed by the programmer). The translator determines the order in which the placeholders appear in the format string. Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
Michael Hudson wrote: Tim Peters [EMAIL PROTECTED] writes: _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary when socketmodule.c is compiled, but (for some unknown reason) only to a 4-byte boundary when _ssl.c is compiled. Although that seems to match the details in the bug report, I have no theory for how that could happen (I don't see any MS packing pragmas anywhere). Well, poking a bit reveals that _ssl and _socket are built by quite different mechanisms: _socket by a .vcproj but _ssl by _ssl.mak. I don't see anything overly suspicious in _ssl.mak, but I don't really know much about Windows compiler options... A mailing list post found via Google suggests that Visual Studio automatically sets the struct member alignment to 4 bytes when building via old .mak files, for compatibility with older VC++. Anyway, a /Zp8 flag should correct this. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
Tim Peters wrote: _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary when socketmodule.c is compiled, but (for some unknown reason) only to a 4-byte boundary when _ssl.c is compiled. This is indeed what happens, because of what I consider three bugs: one in Python, and two in the Platform SDK: - _ssl.mak fails to define WIN32; this is bug 1 - because of that, WinSock2.h includes pshpack4.h at the beginning (please take a look at the comment above that include) - WinSock2.h includes windows.h (and some other stuff). This ultimately *defines* WIN32. I haven't traced where exactly it gets defined, but verified that it does before the end of WinSock2.h. Most likely, it comes from Ole2.h. This is bug 2: if WIN32 is a flag to the SDK headers, they shouldn't set it themselves. If they want to assume it is always defined, they should just make the things that it currently affects unconditional. - WinSock2 then includes poppack.h, under the same condition (WIN32 not defined) as pshpack4.h. This is bug 3: the code assumes that the condition doesn't change, but it might. They should instead set a macro (say, WINSOCK2_PSHPACK4) at push time, and then check for it to determine if they need to pop. Anyway, the fix is then straight-forward: just add /DWIN32 to _ssl.mak. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] need info for externally maintained modules PEP
OK, I am going to write the PEP I proposed a week or so ago, listing all modules and packages within the stdlib that are maintained externally so we have a central place to go for contact info or where to report bugs on issues. This should only apply to modules that want bugs reported outside of the Python tracker and have a separate dev track. People who just use the Python repository as their mainline version can just be left out. For each package I need the name of the module, the name of the maintainer, homepage of the module outside of Python, and where to report bugs. Do people think we need to document the version that has been imported into Python and when that was done as well? Anyway, here is a list of the packages that I think have outside maintenance (or at least have been at some point). Anyone who has info on them that I need, please let me know the details. Also, if I missed any, obviously speak up: - bsddb (still external?) - sqlite - ctypes - cjkcodecs (still external?) - expat - email - logging (still external?) - Tix - ElementTree ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] need info for externally maintained modules PEP
On Sat, 2006-04-08 at 14:47 -0700, Brett Cannon wrote: - email This has an standalone release, but development and bug reports should all happen in the Python project. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
Georg Brandl wrote: Suppose I wanted to implement that, what would be the best strategy to follow: - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c - emit different bytecodes in compile.c - directly create TryExcept AST nodes in ast.c I'd probably go for the third option. Isn't that the sort of thing the fancy new ast system is designed for? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] need info for externally maintained modules PEP
Brett Cannon [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This should only apply to modules that want bugs reported outside of the Python tracker and have a separate dev track. People who just use the Python repository as their mainline version can just be left out. If you include the latter in a separate section (modules with separate release, but using Python repository and tracker, like email), then people will know they have not just been forgotten about and indeed should have bugs reported in the regular tracker ;-). TJR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
So Martin fixed _ssl.c on Windows (thanks! what a subtle pit that turned out to be), and I restored the test_timeout() test in test_socket_ssl. That test was introduced on Bug Day, but: a) First got fiddled to exclude Windows, because the _ssl.c bug made it impossible for the test to pass on Windows; and, b) Then got disabled on all boxes, because the gmail.org address it tried to connect to stopped responding to anyone, and all buildbot test runs on all non-Windows boxes failed as a result for hours that day. We have one oddity remaining: now that test fails on, and only on, Trent's x86 W2k trunk buildbot. It always times out there, and never times out elsewhere. It times out during a socket.connect() call on that buildbot. The socket timeout is set to 30 seconds (seems a very long time, right?). Trent (and anyone else who wants to play along), what happens if you do this by hand in a current trunk or 2.4 build?: import socket s = socket.socket() s.settimeout(30.0) s.connect((gmail.org, 995)) On my box (when gmail.org:995 responds at all), the connect succeeds in approximately 0.03 seconds, giving 29.97 seconds to spare ;-) Can you identify a reason for why it times out on the Win2K buildbot? (beats me -- firewall issue, DNS sloth, ...?) Anyone: is it a bug or a feature that a socket.connect() call that times out may raise either socket.timeout or socket.error? Trent's box raises socket.error. On my box, when I set a timeout value small enough so that it _does_ time out, socket.timeout is raised: import socket s = socket.socket() s.settimeout(0.01) s.connect((gmail.org, 995)) Traceback (most recent call last): File stdin, line 1, in module File string, line 1, in connect socket.timeout: timed out ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
