Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Quoting Nick Coghlan : If you don't want to do an rc3 despite the cherry picked changes since rc2, then you need to make it easy for people to test the changes directly from the release branch. An opaque intermittently updated tarball is not acceptable when none of our infrastructure is designed to work that way. I was OK with just the tarball when I assumed you would an rc3 if non-trivial defects were found in rc2. If that's not the case, then we *need* a public mirror of your release clone. Another rc or not - I expect to see a 3.4.1 release *really* shortly after the 3.4.0 release. So except for issues where Python does not work at all, any glitches that remain in the code can be fixed in the bug fix release. Regards, Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 4 March 2014 20:16, wrote: > > Quoting Nick Coghlan : > >> If you don't want to do an rc3 despite the cherry picked changes since >> rc2, then you need to make it easy for people to test the changes >> directly from the release branch. An opaque intermittently updated >> tarball is not acceptable when none of our infrastructure is designed >> to work that way. I was OK with just the tarball when I assumed you >> would an rc3 if non-trivial defects were found in rc2. If that's not >> the case, then we *need* a public mirror of your release clone. > > > Another rc or not - I expect to see a 3.4.1 release *really* shortly after > the 3.4.0 release. So except for issues where Python does not work at all, > any glitches that remain in the code can be fixed in the bug fix release. Right, but I don't see the need to rush 3.4.0 itself - these were definitely edge cases (that's why our test suite missed them), but they were a result of two of the deeper changes in 3.4 (the import system changes and the introspection changes). Mike and Armin found, investigated and reported them when testing on rc2 turned up a couple of relatively obscure and hard to diagnose failures in their own test suites, and it seems discourteous to then turn around and put pressure on them to double check the fix in our original release time frame rather than granting the extra two weeks a 3rd rc would provide not just to us, but to anyone doing third party testing. (Barry and Matthias already confirmed we can do that much while still having the final release make it directly in Ubuntu 14.04) Maybe I'm being overly conservative, and if Larry, you, and Ned are all comfortable with the idea of going straight to a final release from here, I'm not going to argue further (since you're the ones that would incur the additional work from an additional release). I just wanted to be clear that I'd be more comfortable with either a 3rd release candidate given the pip installation, pkgutil & type slot introspection changes I'm aware of, or at least the ability for people to test the in-development final release using the usual processes documented in the devguide. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Hi, 2014-03-03 22:38 GMT+01:00 Nick Coghlan : > Related question - have you decided yet whether or not to do an rc3? I take a look at current release blocker issues for Python 3.4. I saw bugfixes (ex: upgrade SQLite from 3.8.3 to 3.8.3.1) but also fixes for regressions between Python 3.4rc2 and Python 3.4rc1, especially about pip on Windows. It looks like the Windows installer *and* pip are currently broken on Windows with Python 3.4rc2. It would be sad to release Python 3.4 with pip broken (on Windows) since it was announced (*) that Python 3.4 finally fixes the "pip bootstrap" issue, and users may expect this feature. If we fix the Windows installer and pip on Windows, it would be safer to have a RC3 because I don't know how to test Windows installer and I don't want to learn how to do that. Note: There are also requested changes in OS X installer (upgrade SQLite). IMO a perfect final version is exactly the same than the last RC except that the version changed. Here I see a long list of cherry-pick issues... @Larry: What do you think of a RC3 for March 16th, and a final release one week later (March 23th)? (Or maybe a RC3 for this week-end if you have some free time :-)) (*) Read for example https://lwn.net/Articles/570471/ "Rationalizing Python packaging" Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode_string future, str -> basestring, fix or feature
> Guido van Rossum writes:
> Given that the claim "Python 2 doesn't support Unicode filenames"
> is factually incorrect (in Python 2.7, most filesystem calls in
> fact do support Unicode, at least on some platforms),
I don't understand what "support Unicode" means. Just that
with open(u"\u4e00", "w") as f: f.write("works!\n")
does what is expected[1] if the user knows what he is doing (ie, has
set PYTHONIOENCODING to a Unicode UTF or one of the Asian encodings)?
> I think individual functions in the os module that are found
> lacking should be considered bugs, and if someone goes through
> the effort to supply an otherwise acceptable fix, we shouldn't
> reject it on the basis that we don't want to consider supporting
> Unicode filenames.
As above, "acceptable fix" means take whatever the current value is
for file system name encoding, and use that to encode and decode
unicode objects to/from str, or raise a UnicodeError if it doesn't
work?
I think it's important to define this somewhat carefully, because this
is an area that has a strong tendency to "mission creep". Given that
builtin open "works" by the above definition, I guess it's reasonable
to accept such patches.
Footnotes:
[1] It writes the line "works!\n" to a file whose name consists of the
single Chinese character for "one".
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On Tue, 04 Mar 2014 11:16:41 +0100 [email protected] wrote: > > Quoting Nick Coghlan : > > > If you don't want to do an rc3 despite the cherry picked changes since > > rc2, then you need to make it easy for people to test the changes > > directly from the release branch. An opaque intermittently updated > > tarball is not acceptable when none of our infrastructure is designed > > to work that way. I was OK with just the tarball when I assumed you > > would an rc3 if non-trivial defects were found in rc2. If that's not > > the case, then we *need* a public mirror of your release clone. > > Another rc or not - I expect to see a 3.4.1 release *really* shortly after > the 3.4.0 release. So except for issues where Python does not work at all, > any glitches that remain in the code can be fixed in the bug fix release. I agree with Martin. At this point, we'd better release 3.4.0 (fixing any critical regressions, but leaving non-critical ones aside), then patiently collect evidence of issues, and fix them in non-rush mode for 3.4.1. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On Tue, Mar 4, 2014 at 8:33 AM, Antoine Pitrou wrote: > On Tue, 04 Mar 2014 11:16:41 +0100 > [email protected] wrote: > > > > Quoting Nick Coghlan : > > > > > If you don't want to do an rc3 despite the cherry picked changes since > > > rc2, then you need to make it easy for people to test the changes > > > directly from the release branch. An opaque intermittently updated > > > tarball is not acceptable when none of our infrastructure is designed > > > to work that way. I was OK with just the tarball when I assumed you > > > would an rc3 if non-trivial defects were found in rc2. If that's not > > > the case, then we *need* a public mirror of your release clone. > > > > Another rc or not - I expect to see a 3.4.1 release *really* shortly > after > > the 3.4.0 release. So except for issues where Python does not work at > all, > > any glitches that remain in the code can be fixed in the bug fix release. > > I agree with Martin. At this point, we'd better release 3.4.0 (fixing > any critical regressions, but leaving non-critical ones aside), then > patiently collect evidence of issues, and fix them in non-rush > mode for 3.4.1. > How about this (if Larry is amenable): critical now/this week (e.g. pip on Windows works), non-critical in 3.4.1 with Larry aiming to release 3.4.1 by the end of April? That way the PyCon sprints can be used by projects to test against 3.4.1 and the core sprint can work on squashing any bugs that will inevitably come up from 3.4.0 being out the door. This also lets us make our stated 3.4.0 release date. Every release we feel pressure to squeeze on those last few bugs and this release is the same. Heck, you can say it's enhanced as we had a longer rc cycle. Normally the bugs from Armin and Mike -- which I appreciate -- would have just happened after 3.4.0 went out the door and thus be rolled into 3.4.1 anyway. I suspect the community in general views *.0 releases as stable but not perfect while *.1 releases as the solid one where no surprises will pop up because of new code. I have also filed http://bugs.python.org/issue20851 to make sure the devguide covers running tests from a tarball. If the way the release has been handled has still bugged you enough it can be discussed at the language summit, but it would be the first time we consider putting any restrictions on the RM (which I would loathe to do; I'm fine with nudging Larry to do his stuff in public next time in hopes he's more comfortable with the whole process, but I wouldn't want to require it). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Start writing inlines rather than macros?
Skip Montanaro wrote: > I do have one question though. Suppose you encounter a compiler that > doesn't understand the inline keyword, so you choose the static > declaration as Kristján suggested. The resulting Python executable > should be functionally correct, but if the optimizer doesn't happen to > inline a given static function you might be stuck with some bad > performance across-the-board (if it never inlines, or doesn't inline > where we really need it to), or only under some circumstances (as a > hypothetical example, inlining in dictobject.c, but not in ceval.c). > Is there a configurable way to tell if a compiler will inline > functions which are declared static, and possibly under what > conditions they might not? It might still be necessary to maintain > macros for those platforms. I think that all modern compilers can handle "static inline" in header files. If you have a compiler that cannot, chances are that the platform is horribly outdated and this particular performance issue will be relatively benign compared to other ones. Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode_string future, str -> basestring, fix or feature
On Tue, Mar 4, 2014 at 5:23 AM, Stephen J. Turnbull wrote:
> > Guido van Rossum writes:
>
> > Given that the claim "Python 2 doesn't support Unicode filenames"
> > is factually incorrect (in Python 2.7, most filesystem calls in
> > fact do support Unicode, at least on some platforms),
>
> I don't understand what "support Unicode" means. Just that
>
> with open(u"\u4e00", "w") as f: f.write("works!\n")
>
> does what is expected[1] if the user knows what he is doing (ie, has
> set PYTHONIOENCODING to a Unicode UTF or one of the Asian encodings)?
>
That's all I'm asking for, since that's what most functions in 2.7 already
do.
> > I think individual functions in the os module that are found
> > lacking should be considered bugs, and if someone goes through
> > the effort to supply an otherwise acceptable fix, we shouldn't
> > reject it on the basis that we don't want to consider supporting
> > Unicode filenames.
>
> As above, "acceptable fix" means take whatever the current value is
> for file system name encoding, and use that to encode and decode
> unicode objects to/from str, or raise a UnicodeError if it doesn't
> work?
>
The same thing that is done for other functions that take filenames.
> I think it's important to define this somewhat carefully, because this
> is an area that has a strong tendency to "mission creep". Given that
> builtin open "works" by the above definition, I guess it's reasonable
> to accept such patches.
>
Right, the interpretation given to Unicode filenames by builtin open()
should be propagated to other functions (I actually suspect that
os.statvfs(), which apparently doesn't, is in the minority here). AFAIK
that's also roughly what happens in Python 3.
> Footnotes:
> [1] It writes the line "works!\n" to a file whose name consists of the
> single Chinese character for "one".
>
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Am 04.03.2014 15:52, schrieb Brett Cannon: > I have also filed http://bugs.python.org/issue20851 to make sure the > devguide covers running tests from a tarball. If the way the release has > been handled has still bugged you enough it can be discussed at the > language summit, but it would be the first time we consider putting any > restrictions on the RM. I wouldn't put it this way, but instead ask how to enable the RM to do this kind of work more publicly. I really would like it more if we can extend our buildd infrastructure to automatically test during the time where the trunk and the release candidates don't match. I am aware that this was never done for any release in the past, but maybe this is something that can be enabled for 3.5. But before documenting a process which may change depending on the RM why not try to align the process? Matthias ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 5 Mar 2014 08:15, "Matthias Klose" wrote: > > Am 04.03.2014 15:52, schrieb Brett Cannon: > > I have also filed http://bugs.python.org/issue20851 to make sure the > > devguide covers running tests from a tarball. If the way the release has > > been handled has still bugged you enough it can be discussed at the > > language summit, but it would be the first time we consider putting any > > restrictions on the RM. > > I wouldn't put it this way, but instead ask how to enable the RM to do this kind > of work more publicly. I really would like it more if we can extend our buildd > infrastructure to automatically test during the time where the trunk and the > release candidates don't match. I am aware that this was never done for any > release in the past, but maybe this is something that can be enabled for 3.5. > But before documenting a process which may change depending on the RM why not > try to align the process? I think it's also the fact that new feature releases are rare and changes of release manager even more so, meaning there's a fair bit of relearning involved every time (since what was appropriate a couple of years earlier may not be appropriate the next time, and we'll usually have new developers involved that weren't around for the previous release). While I'd still strongly prefer an rc3, I think we at least need to get the remaining release blockers sorted in the tracker (either fixing them or reclassifying them, or else closing them if they're a rejected cherry pick request) and a tarball or release clone available for core developer and third party testing. We won't be able to get people to test the pip integration fixes on Windows that way (that's one of the reasons I would like an rc3 and don't understand the apparent desire to avoid one), but we would at least be able to check that the Flask and Alembic test suites pass. I'm being fussy about this for two reasons. Firstly, because my view is the same as Victor's: the time between the last rc and the final release should be completely uninteresting, with no significant regressions reported relative to the previous major version (or any such cases clearly being rare enough to wait for the first maintenance release). Secondly, I care because I think we need to take into account the social benefits of ensuring that we treat third party testers as valued members of the release process by giving them a clear chance to confirm that the problems they reported have been addressed before we proceed with the release. That third party testing does help improve the stability of the final release, and wherever practical, we should be doing our best to encourage it. For 3.4rc2, the Alembic and Flask test suites both hit clear regression bugs (one due to pkgutil still calling a now deprecated function, the other due to a type slot publishing an incorrect signature), and users also found that upgrading pip on Windows would prevent subsequently uninstalling CPython. I can politely ask Mike and Armin to test against a pre-release tarball, or against the default branch and assure them the patch has been included in the release tag, but I have no reasonable answer to give them if they ask "why not just publish an rc3 to make this easy to test?". For the folks that reported the Windows installer issues, we can't ask them to double check the fixes at all if we don't do an rc3. Regards, Nick. > > Matthias > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On Mar 05, 2014, at 09:24 AM, Nick Coghlan wrote: >I think it's also the fact that new feature releases are rare and changes >of release manager even more so, meaning there's a fair bit of relearning >involved every time (since what was appropriate a couple of years earlier >may not be appropriate the next time, and we'll usually have new developers >involved that weren't around for the previous release). This is true. Be aware though that Larry is in communication with Benjamin, Georg, and myself, and the PSU is running a closed mailing list for past, present, and future release managers[1]. But you're right that the process and tools can change fairly significantly between releases, and certainly between release manager stints. We have PEP 101 and a bunch of scripts to automate as much as possible. I'm fully supportive of RMs taking on at least two releases in a row, for a similar reason it makes sense to hold PyconNA's in the same city more than one year in a row. Larry has to figure out what works for him on the fly, and I'm positive that he takes everyone's comments and feedback seriously. RMing is just not that easy. Hopefully, once the heat of the release subsides, we and Larry can review the process and make whatever changes are necessary for next time. >While I'd still strongly prefer an rc3, I think we at least need to get the >remaining release blockers sorted in the tracker (either fixing them or >reclassifying them, or else closing them if they're a rejected cherry pick >request) and a tarball or release clone available for core developer and >third party testing. I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. Despite Serhiy's comment (msg212475) I haven't quite gotten the Ubuntu package working entirely, and I hope to return to it once I have some other unrelated high priority issues resolved. It's fine to close as rejected any cherry picks that won't make it into 3.4.0. For the related bugs that are fixed in trunk though, those marked as release blockers should IMO be demoted to deferred blockers so they can be handled in 3.4.1. (Unless of course the disposition is to not fix them until 3.5). >I'm being fussy about this for two reasons. Firstly, because my view is the >same as Victor's: the time between the last rc and the final release should >be completely uninteresting, with no significant regressions reported >relative to the previous major version (or any such cases clearly being >rare enough to wait for the first maintenance release). I completely agree. I don't even trust seemingly innocent changes -- they have broken us before! Ideally, the only difference between the last rc and the final release is the version bump. That may or may not be possible. >Secondly, I care because I think we need to take into account the social >benefits of ensuring that we treat third party testers as valued members of >the release process by giving them a clear chance to confirm that the >problems they reported have been addressed before we proceed with the >release. That third party testing does help improve the stability of the >final release, and wherever practical, we should be doing our best to >encourage it. Given how difficult it is to get people to test pre-final release versions, I definitely agree we need to encourage and support enthusiastic third parties. We all want to avoid the brown paper bag release. ;) Cheers, -Barry [1] Both the PSU and this mailing list emphatically do not exist. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
On 03/04/2014 03:59 PM, Barry Warsaw wrote: I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. I talked to the other guys on the 3.4 team, and we're all willing to do an rc3 this weekend. I'll add that to PEP 429. In other news, I'm thrilled to confirm something Antoine mentioned a week or two ago: it is literally impossible for garden-variety core devs to push new branches back into trunk. I tried to, early this morning (PST), with someone logged in to hg.python.org ready to clean up in case it actually worked. But happily hg hooks on the server reject new branches every time. Since this banishes my chief objection to publishing the repo where I do my cherry picking, I'll be publishing that repo this week. I think I still have a rebase ahead of me, so I'm going wait until after the latest (and hopefully last!) round of cherry-picking. I'll post to python-dev once the tree is public. //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
