Re: [Python-Dev] Preserving the definition order of class namespaces.
On Sat, 23 May 2015 20:14:56 -0700 Larry Hastings wrote: > > On 05/23/2015 07:38 PM, Nick Coghlan wrote: > > Eric clarified for me that Larry was considering granting a feature > > freeze exemption to defer landing this to beta 2 while Eric tracked > > down a segfault bug in the current patch that provides a C > > implementation of OrderedDict. > > Yeah, I'm willing to grant the feature freeze exception, assuming he can > find general approval from the community (and assuming he still has > Guido's blessing). I just wanted a little more sunlight on the topic, > rather than rushing to check it in. Given the pain that has gone into making the patch segfault- and reference leak-free, and given it adds a lot of complication in the data types area, I'm frankly uneasy with having this land after the feature freeze. It's a sure recipe to *add* instability rather than remove it. Regards Antoine. ___ 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] PEP 485: math.isclose()
On Mon, May 25, 2015 at 9:45 AM, Chris Barker wrote: > And a few comments on the patch ( I have not idea how to patch a patch...) > Is there a branch somewhere with this patch applied? Not at the moment. But if you click the "review" link next to the patch on the tracker then you can leave comments "inside" the patch, and we can discuss them there directly. For future reference, that's the preferred place for these type of comments. I'll work your comment into a revised version of the patch and have it up later today. - Tal Einat ___ 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
[Python-Dev] PEP 484
May I suggest to eliminate "->" in function definition?
def function1 (variable1: variable1_type, variable2:
variable2_type): function1_type
return str2function1_type(str(variable1)+str(' ')+str(variable2))
OR
def function1: function1_type (variable1: variable1_type,
variable2: variable2_type):
return str2function1_type(str(variable1)+str(' ')+str(variable2))
both look a bit simpler than
def function1 (variable1: variable1_type, variable2:
variable2_type) -> function1_type:
return str2function1_type(str(variable1)+str(' ')+str(variable2))
Are there any convincing reasons to introduce syntactic sugar?
Yours Mike Kozulya
___
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] [RELEASED] Python 3.5.0b1 is now available
: On Sun, May 24, 2015 at 06:03:50PM -0700, Ned Deily wrote: > Zero Piraeus wrote: > > Source tarballs (both .tgz and .tar.xz) are missing ... > > They seem to be there now. Are you still not able to download them? Oops. Both Larry's reply to me and my thankyou to him turn out to have been offlist. Yes, got 'em now. Turns out to have been a permissions error (which the 403 error would have alerted me to, had I been paying attention). So, in public this time: Thanks, Larry (and thanks for all the work on the release) ... -[]z. -- Zero Piraeus: inter caetera http://etiol.net/pubkey.asc ___ 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] PEP 484
On Mon, May 25, 2015, at 04:02, Mike Kozulya wrote:
> May I suggest to eliminate "->" in function definition?
>
> def function1 (variable1: variable1_type, variable2:
> variable2_type): function1_type
> return str2function1_type(str(variable1)+str('
> ')+str(variable2))
>
> OR
>
> def function1: function1_type (variable1: variable1_type,
> variable2: variable2_type):
> return str2function1_type(str(variable1)+str('
> ')+str(variable2))
>
> both look a bit simpler than
>
> def function1 (variable1: variable1_type, variable2:
> variable2_type) -> function1_type:
> return str2function1_type(str(variable1)+str('
> ')+str(variable2))
>
> Are there any convincing reasons to introduce syntactic sugar?
That's simply preexisting function annotation syntax.
https://www.python.org/dev/peps/pep-3107/
It's not invented by the type hinting pep.
___
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.
On Mon, May 25, 2015, at 03:33, Antoine Pitrou wrote: > On Sat, 23 May 2015 20:14:56 -0700 > Larry Hastings wrote: > > > > On 05/23/2015 07:38 PM, Nick Coghlan wrote: > > > Eric clarified for me that Larry was considering granting a feature > > > freeze exemption to defer landing this to beta 2 while Eric tracked > > > down a segfault bug in the current patch that provides a C > > > implementation of OrderedDict. > > > > Yeah, I'm willing to grant the feature freeze exception, assuming he can > > find general approval from the community (and assuming he still has > > Guido's blessing). I just wanted a little more sunlight on the topic, > > rather than rushing to check it in. > > Given the pain that has gone into making the patch segfault- and > reference leak-free, and given it adds a lot of complication in the > data types area, I'm frankly uneasy with having this land after the > feature freeze. It's a sure recipe to *add* instability rather than > remove it. I agree completely with Antoine. All the hard work that's gone into it recently should make it easy to land stably in 3.6. :) ___ 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.
On Mon, May 25, 2015 at 1:33 AM, Antoine Pitrou wrote: > On Sat, 23 May 2015 20:14:56 -0700 > Larry Hastings wrote: >> Yeah, I'm willing to grant the feature freeze exception, assuming he can >> find general approval from the community (and assuming he still has >> Guido's blessing). I just wanted a little more sunlight on the topic, >> rather than rushing to check it in. > > Given the pain that has gone into making the patch segfault- and > reference leak-free, and given it adds a lot of complication in the > data types area, I'm frankly uneasy with having this land after the > feature freeze. It's a sure recipe to *add* instability rather than > remove it. Well, the exception for C OrderedDict itself is a separate matter. I chose to be more public than I could have been about the last remaining bugs in the interest of getting them resolved a bit faster. At this point I wouldn't consider C OrderedDict to add a whole lot of risk to 3.5. That said, at this point landing it in 3.5 it doesn't matter to me much because my main motivator (__definition_order__) isn't landing in 3.5. The fact that 3.6 is already open to new features eases the sting a bit. I'd still prefer to land OrdereDict-by-default class definition namespaces in 3.5, which is dependent on C OrderedDict, but alone that isn't as important to me for 3.5 as cls.__definition_order__ was. Regardless, I know there were a few folks (e.g. Yury) that wanted to see C OrderedDict in 3.5 and there may be others that would really like OrderedDict-by-default in 3.5 (Nick?). Since Larry already gave an exception, I'd still be glad to land both in 3.5 if Yury (or others) wants to make that case. The patches will be ready. -eric ___ 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
[Python-Dev] Unable to build regex module against Python 3.5 32-bit
As the subject says, I've been unable to build the regex module against Python 3.5b1 for 32-bit. MingGW says: skipping incompatible .../libpython35.a when searching for -lpython35 It builds without a problem against Python 3.5 for 64-bit. Any ideas? Should I just wait until beta 2? ___ 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-committers] Reminder: 3.5 now has its own branch! "default" branch is now 3.6!
On 05/25/2015 02:03 AM, Serhiy Storchaka wrote: Perhaps needed version bump in the default branch? I think now Misc/NEWS will have two modifiable sections - for 3.5 (bugfixes) and for 3.6 (new features). That's a good point! I've added a "3.6.0 alpha 1" section as you suggest. That suggests more FAQs: Q: When I check in just to the default branch (3.6), where should I put my news items in Misc/NEWS? A: There's a section for "3.6.0 alpha 1", put them there. Q: When I check in to 3.5 and merge into to the default branch, where should I put my news items in Misc/NEWS? A: It should go in the same section (3.5.0 beta 1, beta 2, rc 1, etc). I suspect I'll still have to do some cleanup in Misc/NEWS when we ship 3.5.0 final. Isn't it always the way! //arry/ ___ 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
Try building the module with -m32. The error message basically means: "../libpython35.a is 32-bit, but what you're building is 64-bit." Gotta love ld! On May 25, 2015 3:06:01 PM CDT, MRAB wrote: >As the subject says, I've been unable to build the regex module against >Python 3.5b1 for 32-bit. MingGW says: > > skipping incompatible .../libpython35.a when searching for -lpython35 > >It builds without a problem against Python 3.5 for 64-bit. > >Any ideas? Should I just wait until beta 2? >___ >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/rymg19%40gmail.com -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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
On 2015-05-25 21:09, Ryan Gonzalez wrote: > Try building the module with -m32. The error message basically means: "../libpython35.a is 32-bit, but what you're building is 64-bit." Gotta love ld! > Unless I've missing something, I'm already passing it to gcc. All of the other versions build without a problem: Python 2.5-2.7 and Python 3.1-3.4, both 32-bit and 64-bit, and now Python 3.5 64-bit. That's 15 building and 1 failing! > On May 25, 2015 3:06:01 PM CDT, MRAB wrote: > > As the subject says, I've been unable to build the regex module against > Python 3.5b1 for 32-bit. MingGW says: > > skipping incompatible .../libpython35.a when searching for -lpython35 > > It builds without a problem against Python 3.5 for 64-bit. > > Any ideas? Should I just wait until beta 2? ___ 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.
On 2015-05-25 3:40 PM, Eric Snow wrote: I'd still be glad to land both in 3.5 if Yury (or others) wants to make that case. I'm big +1 for a speedy OrderedDict in 3.5 (TBH I thought it was merged in 3.5 long before alpha-4) I doubt that merging it will add such a significant instability that we cannot track and fix in several months before the release, given that all tests pass without refleaks/segfaults before committing the implementation. 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.
On 5/25/2015 3:40 PM, Eric Snow wrote: On Mon, May 25, 2015 at 1:33 AM, Antoine Pitrou wrote: On Sat, 23 May 2015 20:14:56 -0700 Larry Hastings wrote: Yeah, I'm willing to grant the feature freeze exception, assuming he can find general approval from the community (and assuming he still has To me, the message from Antoine, below, and Benjamin's second suggest a lack of 'general approval'. Guido's blessing). I just wanted a little more sunlight on the topic, rather than rushing to check it in. Given the pain that has gone into making the patch segfault- and reference leak-free, and given it adds a lot of complication in the data types area, I'm frankly uneasy with having this land after the feature freeze. It's a sure recipe to *add* instability rather than remove it. Well, the exception for C OrderedDict itself is a separate matter. I chose to be more public than I could have been about the last remaining bugs in the interest of getting them resolved a bit faster. At this point I wouldn't consider C OrderedDict to add a whole lot of risk to 3.5. That said, at this point landing it in 3.5 it doesn't matter to me much because my main motivator (__definition_order__) isn't landing in 3.5. The fact that 3.6 is already open to new features eases the sting a bit. I'd still prefer to land OrdereDict-by-default class definition namespaces in 3.5, which is dependent on C OrderedDict, but alone that isn't as important to me for 3.5 as cls.__definition_order__ was. Regardless, I know there were a few folks (e.g. Yury) that wanted to see C OrderedDict in 3.5 and there may be others that would really like OrderedDict-by-default in 3.5 (Nick?). Since Larry already gave an exception, Conditional on 'general approval of the community'. > I'd still be glad to land both in 3.5 if Yury (or others) wants to make that case. The patches will be ready. -- Terry Jan Reedy ___ 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
On 25 May 2015 at 21:06, MRAB wrote: > As the subject says, I've been unable to build the regex module against > Python 3.5b1 for 32-bit. MingGW says: > > skipping incompatible .../libpython35.a when searching for -lpython35 > > It builds without a problem against Python 3.5 for 64-bit. > > Any ideas? Should I just wait until beta 2? MinGW is (and always has been) only marginally supported, unfortunately. I'd rather it didn't break totally for 3.5, but I am anticipating some difficulties (there have been a lot of compiler-related changes with 3.5). Could you raise a bug, including details of precisely how you tried to build the module (presumably https://pypi.python.org/pypi/regex/2015.05.10) and assign it to me? I'll try to take a look and reproduce the issue. With luck, it may be as simple as the wrong version of libpython35.a being picked up somewhere. Just to check the obvious - you *are* using 32-bit Python 3.5b1 and a 32-bit Mingw to build the 32-bit version, and 64-bit Python 3.5b1 and a 64-bit Mingw to build the 64-bit one? (I.e., two installations of Python and two of Mingw) 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] Preserving the definition order of class namespaces.
On Mon, May 25, 2015 at 2:40 PM, Terry Reedy wrote: > On 5/25/2015 3:40 PM, Eric Snow wrote: >> Since Larry already gave an exception, > > Conditional on 'general approval of the community'. Unless I misunderstood him, Larry gave me an unconditional exception for OrderedDict itself (as long as it is in before beta 2.) The condition only applied to making OrderedDict the default class definition namespace and adding cls.__definition_order__. Furthermore, the condition related to the semantic changes to Python, not to concerns about destabilizing Python. I don't mean to imply that Larry can't retract (or modify) the exceptions he's given me. In fact, if there is sufficient risk of de-stabilizing the release then I'd expect him to do so. However, ultimately that's his call as release manager; and I do not believe there is any greater risk now than what I explained to him in our discussions leading up to the exceptions I received. -eric > >> I'd still be glad to land both in 3.5 if Yury (or >> >> others) wants to make that case. The patches will be ready. ___ 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
On 2015-05-25 22:59, Paul Moore wrote: > On 25 May 2015 at 21:06, MRAB wrote: > > As the subject says, I've been unable to build the regex module against > > Python 3.5b1 for 32-bit. MingGW says: > > > > skipping incompatible .../libpython35.a when searching for -lpython35 > > > > It builds without a problem against Python 3.5 for 64-bit. > > > > Any ideas? Should I just wait until beta 2? > > MinGW is (and always has been) only marginally supported, > unfortunately. I'd rather it didn't break totally for 3.5, but I am > anticipating some difficulties (there have been a lot of > compiler-related changes with 3.5). > > Could you raise a bug, including details of precisely how you tried to > build the module (presumably > https://pypi.python.org/pypi/regex/2015.05.10) and assign it to me? > I'll try to take a look and reproduce the issue. With luck, it may be > as simple as the wrong version of libpython35.a being picked up > somewhere. > > Just to check the obvious - you *are* using 32-bit Python 3.5b1 and a > 32-bit Mingw to build the 32-bit version, and 64-bit Python 3.5b1 and > a 64-bit Mingw to build the 64-bit one? (I.e., two installations of > Python and two of Mingw) > I'm not sure what happened, but I'm now getting this for Python 3.5 (32-bit): C:\Python35(32-bit)\libs/libpython35.a(dsxbs01290.o):(.idata$7+0x0): undefined reference to `_head_C__build_cpython_PCBuild_win32_libpython35_a' C:\Python35(32-bit)\libs/libpython35.a(dsxbs00283.o):(.idata$7+0x0): undefined reference to `_head_C__build_cpython_PCBuild_win32_libpython35_a' C:\Python35(32-bit)\libs/libpython35.a(dsxbs00291.o):(.idata$7+0x0): undefined reference to `_head_C__build_cpython_PCBuild_win32_libpython35_a' C:\Python35(32-bit)\libs/libpython35.a(dsxbs00273.o):(.idata$7+0x0): undefined reference to `_head_C__build_cpython_PCBuild_win32_libpython35_a' C:\Python35(32-bit)\libs/libpython35.a(dsxbs00255.o):(.idata$7+0x0): undefined reference to `_head_C__build_cpython_PCBuild_win32_libpython35_a' C:\Python35(32-bit)\libs/libpython35.a(dsxbs01280.o):(.idata$7+0x0): more undefined references to `_head_C__build_cpython_PCBuild_win32_libpython35_a' follow collect2: ld returned 1 exit status All other builds, from Python 2.5 to Python 3.4, both 32-bit and 64-bit, and also Python 3.5 (64-bit), work. 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 -Wconversion -I"C:\Python35\include" -c "D:\projects\mrab-regex\regex_3\regex\_regex_unicode.c" -o "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex_unicode.o" "C:\MinGW64\bin\gcc.exe" -mdll -m64 -DMS_WIN64 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python35\include" -c "D:\projects\mrab-regex\regex_3\regex\_regex.c" -o "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex.o" "C:\MinGW64\bin\gcc.exe" -m64 -shared -s "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex_unicode.o" "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex.o" -L"C:\Python35\libs" -lpython35 -o "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex.pyd" rem Compile for Python 3.5 (32-bit) [fails] cd C:\MinGW\bin "C:\MinGW\bin\gcc.exe" -mdll -m32 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python35(32-bit)\include" -c "D:\projects\mrab-regex\regex_3\regex\_regex_unicode.c" -o "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex_unicode.o" "C:\MinGW\bin\gcc.exe" -mdll -m32 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python35(32-bit)\include" -c "D:\projects\mrab-regex\regex_3\regex\_regex.c" -o "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex.o" "C:\MinGW\bin\gcc.exe" -m32 -shared -s "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex_unicode.o" "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex.o" -L"C:\Python35(32-bit)\libs" -lpython35 -o "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex.pyd" ---8<--- ___ 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.
On 26 May 2015 05:41, "Eric Snow" wrote: > > Regardless, I know there were a few folks (e.g. Yury) that wanted to > see C OrderedDict in 3.5 and there may be others that would really > like OrderedDict-by-default in 3.5 (Nick?). I think it's the combination with PEP 487 that makes OrderedDict-by-default genuinely compelling, so I don't mind if the application to class namespaces slips to 3.6 (and perhaps even becomes part of that PEP). For the feature freeze exception for the C odict implementation itself, I think I'm morally obliged to back that given my highly debatable decision to check in the PEP 489 implementation even though we hadn't worked out all the kinks in module unloading yet (Petr subsequently got all of the refleaks in the machinery itself sorted out before the beta, including a previously undetected one in PyType_FromSpecAndBases, but there's still a leak when unloading the new multi-phase initialisation test module). Regards, Nick. ___ 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.
On 05/25/2015 03:22 PM, Eric Snow wrote: On Mon, May 25, 2015 at 2:40 PM, Terry Reedy wrote: On 5/25/2015 3:40 PM, Eric Snow wrote: Since Larry already gave an exception, Conditional on 'general approval of the community'. Unless I misunderstood him, Larry gave me an unconditional exception for OrderedDict itself (as long as it is in before beta 2.) For the record I've granted three exceptions to the beta 1 feature freeze (so far): * Raymond asked for one (a couple weeks ago!) for adding slice support to collections.deque. He knew he wouldn't have time to finish it before beta 1. * Serhiy asked for one very-last-minute for a C reimplementation of lru_cache. He checked it in about a half-hour before feature freeze and it made all the buildbots fail. (The ones that weren't already failing, that is.) * Eric asked for one for this C reimplementation of OrderedDict; the coding was done, the debugging wasn't. And yes, as Eric said, I made separate pronouncements. I said COrderedDict could go in as long as it was in before beta 2; "the other work" of __definition_order__ and switching type_prepare and __build_class__ to using ordered dicts I made conditional on "general approval of the community." The latter has already been tabled for now. So, in all three cases it's work that's been under development for a while. These people did this work out of the kindness of their hearts, to make Python better. As a community we want to encourage that and make sure these developers know we appreciate their efforts. These people would be happier if the work shipped in 3.5 as opposed to 3.6 so it got into user's hands sooner. Also, in Serhiy and Eric's cases, these are reimplementations of existing Python libraries in C. On the one hand, that means we should have good regression test coverage in the library--which it seems like we do, as both of them are debugging problems uncovered by the regression tests. This gives us a little more confidence that the work is good. On the other hand, it does mean there's a higher chance of destabilization, as there's already an installed base using these libraries. (As opposed to something new like math.isclose which has no installed base.) So yes this could introduce bugs that will impact existing users. Bottom line: while an important part job of my job is saying "no", I also feel like an important part of my job is saying "yes". On balance, what will be best for Python? In these cases, I think "yes" is better. My feeling is, let's check it in (before beta 2), and if it causes problems during the betas / rcs we can back them out. //arry/ ___ 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.
On Mon, May 25, 2015 at 6:30 PM, Larry Hastings wrote: > Eric asked for one for this C reimplementation of OrderedDict; the coding > was done, the debugging wasn't. > > And yes, as Eric said, I made separate pronouncements. I said COrderedDict > could go in as long as it was in before beta 2; "the other work" of > __definition_order__ and switching type_prepare and __build_class__ to using > ordered dicts I made conditional on "general approval of the community." > The latter has already been tabled for now. > > > So, in all three cases it's work that's been under development for a while. > These people did this work out of the kindness of their hearts, to make > Python better. As a community we want to encourage that and make sure these > developers know we appreciate their efforts. These people would be happier > if the work shipped in 3.5 as opposed to 3.6 so it got into user's hands > sooner. > > Also, in Serhiy and Eric's cases, these are reimplementations of existing > Python libraries in C. On the one hand, that means we should have good > regression test coverage in the library--which it seems like we do, as both > of them are debugging problems uncovered by the regression tests. This > gives us a little more confidence that the work is good. On the other hand, > it does mean there's a higher chance of destabilization, as there's already > an installed base using these libraries. (As opposed to something new like > math.isclose which has no installed base.) So yes this could introduce bugs > that will impact existing users. > > > Bottom line: while an important part job of my job is saying "no", I also > feel like an important part of my job is saying "yes". On balance, what > will be best for Python? In these cases, I think "yes" is better. My > feeling is, let's check it in (before beta 2), and if it causes problems > during the betas / rcs we can back them out. Thanks, Larry. As to the conditional exceptions, I'm just going to drop those entirely in favor of getting them in 3.6. I'll still pursue OrderedDict for 3.5b2 though (and hope to land it this week). -eric ___ 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
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. try..finally would be even better. 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] [Python-checkins] cpython (3.4): Issue #23840: tokenize.open() now closes the temporary binary file on error to
What is wrong with "except:" in this specific case? Victor Le mardi 26 mai 2015, Yury Selivanov a écrit : > > > 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. >> > > try..finally would be even better. > > 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/victor.stinner%40gmail.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] [Python-checkins] cpython (3.4): Issue #23840: tokenize.open() now closes the temporary binary file on error to
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 +except: +buffer.close() +raise Please do not add bare 'except:'. If you mean 'except BaseException:', say so. try..finally would be even better. No, finally is not correct there. buffer shouldn't be closed if no exception is raised. And this is one of the cases in which bare 'except:' is absolutely legal. ___ 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
On 26 May 2015 at 00:34, MRAB 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 > -Wconversion -I"C:\Python35\include" -c > "D:\projects\mrab-regex\regex_3\regex\_regex_unicode.c" -o > "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex_unicode.o" > "C:\MinGW64\bin\gcc.exe" -mdll -m64 -DMS_WIN64 -O2 -Wall -Wsign-compare > -Wconversion -I"C:\Python35\include" -c > "D:\projects\mrab-regex\regex_3\regex\_regex.c" -o > "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex.o" > "C:\MinGW64\bin\gcc.exe" -m64 -shared -s > "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex_unicode.o" > "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex.o" -L"C:\Python35\libs" > -lpython35 -o "D:\projects\mrab-regex\regex_3\Release(3.5)\_regex.pyd" > > rem Compile for Python 3.5 (32-bit) [fails] > cd C:\MinGW\bin > "C:\MinGW\bin\gcc.exe" -mdll -m32 -O2 -Wall -Wsign-compare -Wconversion > -I"C:\Python35(32-bit)\include" -c > "D:\projects\mrab-regex\regex_3\regex\_regex_unicode.c" -o > "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex_unicode.o" > "C:\MinGW\bin\gcc.exe" -mdll -m32 -O2 -Wall -Wsign-compare -Wconversion > -I"C:\Python35(32-bit)\include" -c > "D:\projects\mrab-regex\regex_3\regex\_regex.c" -o > "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex.o" > "C:\MinGW\bin\gcc.exe" -m32 -shared -s > "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex_unicode.o" > "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex.o" > -L"C:\Python35(32-bit)\libs" -lpython35 -o > "D:\projects\mrab-regex\regex_3\Release(3.5)(32-bit)\_regex.pyd" > > ---8<--- Do you get the same failure when using distutils to build the extension? Paul PS This discussion should probably be moved to bugs.python.org, as I mentioned... ___ 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
