Re: [Python-Dev] [Python-checkins] cpython (3.4): Issue #23840: tokenize.open() now closes the temporary binary file on error to

[Victor Stinner]

2015-05-26 8:44 GMT+02:00 Serhiy Storchaka :
> 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 'except:' is absolutely legal.

The "except: ; raise" is common in the Python stdlib.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

[Paul Moore]

On 26 May 2015 at 07:49, Paul Moore  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 generated it yourself for the previous
versions?

So I wonder if this is a difference between how you built your version
previously and how the shipped version is now built. The code to build
the shipped version is in Tools\msi\dev\dev.wixproj. It runs

gendef - "$(BuildPath)$(PyDllName).dll" >
"$(IntermediateOutputPath)mingwlib.def"
dlltool --dllname $(PyDllName).dll --def
"$(IntermediateOutputPath)mingwlib.def" --output-lib
"$(BuildPath)lib$(PyDllName).a" -m $(_GenDefPlatform)

which looks OK to me (_GenDefPlatform is i386 on 32-bit and
i386:x86-64 on 64-bit).

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

[Steve Dower]

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 
what's happened here, I see it as a good enough reason to stop shipping the lib 
and to add instructions on generating it instead (the gendef/dlltool dance).

Cheers,
Steve

Top-posted from my Windows Phone

From: Paul Moore
Sent: ‎5/‎26/‎2015 2:50
To: MRAB
Cc: Python-Dev
Subject: Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

On 26 May 2015 at 07:49, Paul Moore  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 generated it yourself for the previous
versions?

So I wonder if this is a difference between how you built your version
previously and how the shipped version is now built. The code to build
the shipped version is in Tools\msi\dev\dev.wixproj. It runs

gendef - "$(BuildPath)$(PyDllName).dll" >
"$(IntermediateOutputPath)mingwlib.def"
dlltool --dllname $(PyDllName).dll --def
"$(IntermediateOutputPath)mingwlib.def" --output-lib
"$(BuildPath)lib$(PyDllName).a" -m $(_GenDefPlatform)

which looks OK to me (_GenDefPlatform is i386 on 32-bit and
i386:x86-64 on 64-bit).

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

[Paul Moore]

On 26 May 2015 at 13:55, Steve Dower  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 good chance that the shipped lib won't work for some people. If this
> is what's happened here, I see it as a good enough reason to stop shipping
> the lib and to add instructions on generating it instead (the gendef/dlltool
> dance).

Agreed. If shipping it helps, then great. If it's going to cause bug
reports, let's go back to the status quo of not having it. The
instructions for generating it were in the old distutils docs, now
removed in the cleanup / redirection to packaging.python.org. I'm
inclined to just leave it undocumented - the people who need it know
how to do it or can find it, whereas documenting the process implies a
level of support that we're not yet really able to provide.

Let's wait to see what the OP comes back with before making a final
decision. I see a few questions:

1. Does using distutils work (as opposed to the quoted manual compile steps)?
2. Does using whatever process he used in the past to generate
libpythonXY.a result in a working version?

https://docs.python.org/2.7/install/index.html#gnu-c-cygwin-mingw
suggests using pexports rather than gendef. I don't know if that could
produce a different result, but I can't see how... It also implicitly
assumes you're using dlltool from the toolchain you'll be building
with rather than using -m. Again, I can't see why that would affect
the results.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.4): Issue #23840: tokenize.open() now closes the temporary binary file on error to

[Yury Selivanov]

On 2015-05-26 3:54 AM, Victor Stinner wrote:

2015-05-26 8:44 GMT+02:00 Serhiy Storchaka :

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.



Right.  My bad, sorry Victor ;)

Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Preserving the definition order of class namespaces.

[Jim J. Jewett]

On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote:
> On 24 May 2015 at 19:44, Mark Shannon  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 to
>>> evaluate the class body switched from being a basic dictionary to an
>>> ordered one would be a hidden implementation detail, rather than
>>> making all type objects a little bigger.

>> and a little slower.

> The runtime namespace used to store the class attributes is remaining
> a plain dict object regardless,

Lookup isn't any slower in the ordereddict.

Inserts are slower -- and those would happen in the ordereddict, as
the type object is being defined.

Note that since we're talking about the type objects, rather than the
instances, most* long-running code won't care, but it will hurt startup
time.

*code which creates lots of throwaway classes is obviously an exception.

FWIW, much of the extra per-insert cost is driven by either the need to
keep deletion O(1) or the desire to keep the C layout binary compatible.

A different layout (with its own lookdict) could optimize for the
insert-each-value-once case, or even for small dicts (e.g., keyword
dicts).  I could imagine this producing a speedup, with the ordering
being just a side benefit.  It is too late to use such a new layout by
default in 3.5, but we should be careful not to close it off.  (That
said, I don't think __definition_order__ would actually close it off,
though it might start to look like a wart.)

-jJ

--

If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them.  -jJ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

[MRAB]

On 2015-05-26 14:24, Paul Moore wrote:
> On 26 May 2015 at 13:55, Steve Dower  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 good chance that the shipped lib won't work for some 
people. If this
> > is what's happened here, I see it as a good enough reason to stop 
shipping
> > the lib and to add instructions on generating it instead (the 
gendef/dlltool

> > dance).
>
> Agreed. If shipping it helps, then great. If it's going to cause bug
> reports, let's go back to the status quo of not having it. The
> instructions for generating it were in the old distutils docs, now
> removed in the cleanup / redirection to packaging.python.org. I'm
> inclined to just leave it undocumented - the people who need it know
> how to do it or can find it, whereas documenting the process implies a
> level of support that we're not yet really able to provide.
>
> Let's wait to see what the OP comes back with before making a final
> decision. I see a few questions:
>
> 1. Does using distutils work (as opposed to the quoted manual compile 
steps)?

> 2. Does using whatever process he used in the past to generate
> libpythonXY.a result in a working version?
>
> https://docs.python.org/2.7/install/index.html#gnu-c-cygwin-mingw
> suggests using pexports rather than gendef. I don't know if that could
> produce a different result, but I can't see how... It also implicitly
> assumes you're using dlltool from the toolchain you'll be building
> with rather than using -m. Again, I can't see why that would affect
> the results.
>
It's been so long since the last Python release that I didn't remember 
that I had to make the lib file.


I made libpython35.a like I did for the others and it's all working now. 
All the tests pass. :-)


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

[Paul Moore]

On 26 May 2015 at 18:23, MRAB  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
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.4): Issue #23840: tokenize.open() now closes the temporary binary file on error to

[R. David Murray]

On Tue, 26 May 2015 08:20:01 +0200, Victor Stinner  
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 that all exceptions should be caught, as opposed to
it being legacy code or a programming mistake.

> > 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
> >>> +except:
> >>> +buffer.close()
> >>> +raise
> >>>
> >>
> >> Please do not add bare 'except:'.  If you mean 'except BaseException:',
> >> say so.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

[MRAB]

On 2015-05-26 18:27, Paul Moore wrote:
> On 26 May 2015 at 18:23, MRAB  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.
>
For making the .def files, I used:

C:\MinGW64\x86_64-w64-mingw32\bin\gendef.exe

MinGW didn't contain gendef.exe!

For making the .a files, I used:

C:\MinGW64\bin\dlltool.exe

for the 64-bit builds and:

C:\MinGW\bin\dlltool.exe

for the 32-bit builds.

They all worked.

When I tried:

C:\MinGW64\bin\dlltool.exe

or:

C:\MinGW64\x86_64-w64-mingw32\bin\dlltool.exe

for the 32-bit builds, they wouldn't link.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

[Paul Moore]

On 27 May 2015 at 03:02, MRAB  wrote:
> When I tried:
>
> C:\MinGW64\bin\dlltool.exe
>
> or:
>
> C:\MinGW64\x86_64-w64-mingw32\bin\dlltool.exe
>
> for the 32-bit builds, they wouldn't link.

Was that with "-m i386"? If so, then I suspect that's the issue.
Steve, did you use 64-bit mingw to build the .a files? Assuming so, I
guess we either stop shipping libpythonXY.a, or the instructions for
building the Windows release need to clearly state that you want a
32-bit mingw on PATH for the 32-bit builds, and a 64-bit mingw on PATH
for the 64-bit builds (which sounds messy and error-prone :-()

I'd be inclined to call this a mingw bug. However, I don't have the
first clue where to report it.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com