On 2015-05-26 18:27, Paul Moore wrote:
On 26 May 2015 at 18:23, MRAB pyt...@mrabarnett.plus.com wrote:
I made libpython35.a like I did for the others and it's all working
now. All
the tests pass. :-)
Cool. How did you make libpython35.a? Sounds like there is some
difference in the
What is wrong with except: in this specific case?
Victor
Le mardi 26 mai 2015, Yury Selivanov yselivanov...@gmail.com a écrit :
On 2015-05-26 12:26 AM, Terry Reedy wrote:
+try:
+encoding, lines = detect_encoding(buffer.readline)
+buffer.seek(0)
+text =
On 26 May 2015 at 00:34, MRAB pyt...@mrabarnett.plus.com wrote:
The 32-bit Python says it's 32-bit and the 64-bit Python says it's 64-bit.
---8---
C:
rem Compile for Python 3.5 (64-bit) [works]
cd C:\MinGW64\bin
C:\MinGW64\bin\gcc.exe -mdll -m64 -DMS_WIN64 -O2 -Wall -Wsign-compare
On 26.05.15 08:33, Yury Selivanov wrote:
On 2015-05-26 12:26 AM, Terry Reedy wrote:
+try:
+encoding, lines = detect_encoding(buffer.readline)
+buffer.seek(0)
+text = TextIOWrapper(buffer, encoding, line_buffering=True)
+text.mode = 'r'
+return text
+
2015-05-26 8:44 GMT+02:00 Serhiy Storchaka storch...@gmail.com:
No, finally is not correct there. buffer shouldn't be closed if no exception
is raised.
Yep. The binary file must only be closed in case of error, as written
in the commit message.
And this is one of the cases in which bare
On 26 May 2015 at 07:49, Paul Moore p.f.mo...@gmail.com wrote:
Do you get the same failure when using distutils to build the extension?
Hmm, I just checked and it seems that only Python 3.5 ships
libpythonXY.a by default - 3.4 and earlier (at least on my machine)
don't have it. Presumably you
The builds I am responsible for include it because someone reported an issue
and was persistent and helpful enough that I fixed it for them.
That said, until MinGW agrees on a stable branch/version/fork, there seems to
be a good chance that the shipped lib won't work for some people. If this is
On 26 May 2015 at 13:55, Steve Dower steve.do...@microsoft.com wrote:
The builds I am responsible for include it because someone reported an issue
and was persistent and helpful enough that I fixed it for them.
That said, until MinGW agrees on a stable branch/version/fork, there seems
to be a
On 2015-05-26 3:54 AM, Victor Stinner wrote:
2015-05-26 8:44 GMT+02:00 Serhiy Storchaka storch...@gmail.com:
No, finally is not correct there. buffer shouldn't be closed if no exception
is raised.
Yep. The binary file must only be closed in case of error, as written
in the commit message.
On Tue, 26 May 2015 08:20:01 +0200, Victor Stinner victor.stin...@gmail.com
wrote:
What is wrong with except: in this specific case?
Nothing is wrong with it from a technical standpoint. However, if we
use 'except BaseException' that makes it clear that someone has thought
about it and decided
On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote:
On 24 May 2015 at 19:44, Mark Shannon mark at hotpy.org wrote:
On 24/05/15 10:35, Nick Coghlan wrote:
If we leave __definition_order__ out for the time being then, for the
vast majority of code, the fact that the ephemeral namespace used
On 2015-05-26 14:24, Paul Moore wrote:
On 26 May 2015 at 13:55, Steve Dower steve.do...@microsoft.com wrote:
The builds I am responsible for include it because someone reported
an issue
and was persistent and helpful enough that I fixed it for them.
That said, until MinGW agrees on a
On 26 May 2015 at 18:23, MRAB pyt...@mrabarnett.plus.com wrote:
I made libpython35.a like I did for the others and it's all working now. All
the tests pass. :-)
Cool. How did you make libpython35.a? Sounds like there is some
difference in the process being used for the shipped version.
Paul
13 matches
Mail list logo
