Re: [Python-Dev] Python 3.4 Release Manager
On Wed, Nov 23, 2011 at 6:50 AM, Senthil Kumaran wrote: > That's cool. But just my thought, wouldn't it be better for someone > who regularly commits, fixes bugs and feature requests be better for a > RM role? Once a developer gets bored with those and wants more, could > take up RM role. Is there anything wrong with this kind of thinking? There is something to be said for letting those people continue to regularly commit and fix bugs rather than saddling them with the RM role. :) Schiavo Simon ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 Release Manager
Antoine Pitrou writes: > On Tue, 22 Nov 2011 20:27:24 -0800 > Raymond Hettinger wrote: > > > > > > But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's > > > that? Needs work? > > > > You could try a more positive leadership style: THAT LOOKS GREAT, I'M > > SURE THE RM FOR PYTHON 3.5 WILL LOVE IT ;-) > > How about: PHP 5.5 IS NOW OPEN FOR COMMIT ? I thought Larry's version was somewhat more encouraging. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix compiler warning by implementing this more cleverly
Le Mercredi 23 Novembre 2011 01:49:28 Terry Reedy a écrit : > The one-liner could be followed by >assert(kind==1 || kind==2 || kind==4) > which would also serve to remind the reader of the possibilities. For a ready string, kind must be 1, 2 or 4. We might rename "kind" to "charsize" because its value changed from 1, 2, 3 to 1, 2, 4 (to make it easy to compute the size of a string: length * kind). You are not supposed to see the secret kind==0 case. This value is only used for string created by _PyUnicode_New() and not ready yet: str = _PyUnicode_New() /* use str */ assert(PyUnicode_KIND(str) == 0); if (PyUnicode_READY(str) < 0) /* error */ assert(PyUnicode_KIND(str) != 0); /* kind is 1, 2, 4 */ Thanks to the effort of t0rsten, Martin and me, quite all functions use the new API (PyUnicode_New). For example, PyUnicode_AsRawUnicodeEscapeString() starts by ensuring that the string is ready. For your information, PyUnicode_KIND() fails with an assertion error in debug mode if the string is not ready. -- I don't have an opinion about the one-liner vs the switch :-) But if you want to fix compiler warnings, you should use "enum PyUnicode_Kind" type and PyUnicode_WCHAR_KIND should be removed from the enum. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On Tue, Nov 22, 2011 at 17:41, Stephen J. Turnbull wrote: > This is still a big mess in Gentoo and MacPorts, though. MacPorts > hasn't done anything about ceating a transition infrastructure AFAICT. > Gentoo has its "eselect python set VERSION" stuff, but it's very > dangerous to set to a Python 3 version, as many things go permanently > wonky once you do. (So far I've been able to work around problems > this creates, but it's not much fun.) Problems like what? > I don't have any connections to the distros, so can't really offer to > help directly. I think it might be a good idea for users to lobby > (politely!) their distros to work on the transition. Please create a connection to your distro by filing bugs as you encounter them? The Gentoo Python team is woefully understaffed (and I've been busy with some Real Life things, although that should improve in a couple more weeks), but we definitely care about providing an environment where you can successfully run python2 and python3 in parallel. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
Dirkjan Ochtman writes: > On Tue, Nov 22, 2011 at 17:41, Stephen J. Turnbull > wrote: > > This is still a big mess in Gentoo and MacPorts, though. MacPorts > > hasn't done anything about ceating a transition infrastructure AFAICT. > > Gentoo has its "eselect python set VERSION" stuff, but it's very > > dangerous to set to a Python 3 version, as many things go permanently > > wonky once you do. (So far I've been able to work around problems > > this creates, but it's not much fun.) > > Problems like what? Like those I explained later in the post, which you cut. But I'll repeat. Some ebuilds are not prepared for Python 3, so must be emerged with a Python 2 eselected (and sometimes they need a specific Python 2). Some which are prepared don't get linted often enough, so new ebuilds are DOA because of an accented character in a changelog triggering a Unicode exception or similar dumb things like that. > > I don't have any connections to the distros, so can't really offer to > > help directly. I think it might be a good idea for users to lobby > > (politely!) their distros to work on the transition. > > Please create a connection to your distro by filing bugs as you > encounter them? No, thank you. File bugs, maybe, although most of the bugs I encounter in Gentoo are already in the database (often with multiple regressions going back a year or more), I could do a little more of that. (Response in the past has not been encouraging.) But I don't have time for distro politics. Is lack of Python 3-readiness considered a bug by Gentoo? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On Wed, Nov 23, 2011 at 13:21, Stephen J. Turnbull wrote: > > Problems like what? > > Like those I explained later in the post, which you cut. But I'll They were in a later post, I didn't cut them. :) > > Please create a connection to your distro by filing bugs as you > > encounter them? > > No, thank you. File bugs, maybe, although most of the bugs I > encounter in Gentoo are already in the database (often with multiple > regressions going back a year or more), I could do a little more of > that. (Response in the past has not been encouraging.) But I don't > have time for distro politics. I'm sorry for the lack of response in the past. I looked at Gentoo's Bugzilla and didn't find any related bugs you reported or were CC'ed on, can you name some of them? > Is lack of Python 3-readiness considered a bug by Gentoo? Definitely. Again, we are trying to hard to make things better, but there's a lot to do and going through version bumps sometimes wins out over addressing the hard problems. Be assured, though, that we're also trying to make progress on the latter. If you're ever on IRC, come hang out in #gentoo-python, where distro politics should be minimal and the crew is generally friendly and responsive. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
Ned Deily writes: > In article <[email protected]>, > "Stephen J. Turnbull" wrote: > > I haven't had the nerve to do this on MacPorts because "port" is such > > a flaky thing (not so much port itself, but so many ports assume that > > the port maintainer's local configuration is what others' systems use, > > so I stay as vanilla as possible -- I rather doubt that many ports are > > ready for Python 3, and I'm not willing to be a guinea pig). > > I think your fears are unfounded. MacPort's individual port files are > supposed to be totally independent of the setting of 'port select'. If you think I'm complaining or imagining things, you're missing the point. My fears are *not* unfounded. For personal use, I wanted Python 2.6 to be default using "port select", and things went wonky. Some things just didn't work, or disappeared. Reverting to 2.5 fixed, so I left it that way for a while. I tried it again with Python 2.7, same deal, different ports. Maybe those would have been considered bugs in "port select", I don't know. But reverting was easy, "fixed" things, and I won't try it with Python 3 (until I have a sacrificial system available). Also, the MacPorts solution is very resource intensive for users: I have *seven* Python stacks on the Mac where I'm typing this -- the only version of Python I've been able to eliminate once it has been installed so far is 3.0! although I could probably get rid of 3.1 now). It also leads to fragmentation (*all* of my 2.x stacks are incomplete, I can't do without any of them), and a couple of extra frustrating steps in finding the code that raised an exceptions or whatever. Not to mention that it's in my face daily: "port outdated" frequently lines up 3, occasionally 4 versions of the same port. This *only* happens with Python! And there's no way that many ports are ready for Python 3, because their upstreams aren't! I think that projects that would like to move to Python 3 are going to find they get pushback from Mac users who "don't need" *yet another* Python stack installed. Note that Gentoo has globally switched off the python USE flag[1] (I suspect that the issue is that one-time configuration utilities can pull in a whole Python stack that mostly duplicates Python content required for Gentoo to work at all). > Also right now besides the Python port group transition, the > project has been swamped with issues arising from the Xcode 4 > introduction for Lion, mandating the transition from gcc to clang > or llvm-gcc. Sure, I understand that kind of thing. That doesn't mean it improves the user experience with Python, especially Python 3. It helps if you can get widespread adoption at similar pace across the board rather than uneven diffusion with a few niches moving really fast. It's like Lao Tse didn't quite say: the most successful leaders are those who hustle and get a few steps ahead of the crowd wherever it's heading. But you need a crowd moving in the same direction to execute that strategy! So I'd like see people who *already* have the credibility with their distros to advocate Python 3. If Ubuntu's going to lead, now's a good time to join them. (Other things being equal, of course -- but then, other things are never equal, so it may as well be now anyway.) If that doesn't happen, well, Python and Python 3 will survive. But I'd rather to see them dominate. Footnotes: [1] According to the notes for the ibus ebuild. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 Release Manager
On Nov 22, 2011, at 07:50 PM, Larry Hastings wrote: >I've volunteered to be the Release Manager for Python 3.4. The FLUFL has >already given it his Sloppy Wet Kiss Of Approval, I think you mistook that for my slackjaw droolings when you repeatedly ignored my warnings to run as far from it as possible. But you're persistent, I'll give you that. Looks like that persistence will be punis^H^H^H^H^Hrewarded with your first RMship! Congratulations (?). >and we talked to Georg and he was for it too. There's no formal process for >selecting the RM, so I may already be stuck with the job, but I thought it >best to pipe up on python-dev in case someone had a better idea. > >But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's that? >Needs work? > >I look forward to seeing how the sausage is made, Undoubtedly it will make you a vegan, but hopefully not a Go programmer! :) Seriously though, I think it's great for you to work with Georg through the 3.3 process, so you can take over for 3.4. And I also think it's great that someone new wants to do it. I kid, but the mechanics of releasing really isn't very difficult these days as we've continually automated the boring parts. The fun part is really making the decisions about what is a showstopper, what changes can go in at the last minute, etc. Like the president of the USA, I just hope your hair is already gray! -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
Dirkjan Ochtman writes: > I'm sorry for the lack of response in the past. I looked at Gentoo's > Bugzilla and didn't find any related bugs you reported or were CC'ed > on, can you name some of them? This isn't about my bugs; I've been able to work through them satisfactorily. It's about what I perceive as a need for simultaneous improvement in Python 3 support across several distros, covering enough users to establish momentum. I don't think Python 3 needs to (or even can) replace Python 2 as the system python in the near future. But the "python" that is visible to users (at least on single-user systems) should be choosable by the user. eselect (on Gentoo) and port select (on MacPorts) *appear* to provide this, but it doesn't work very well. > > Is lack of Python 3-readiness considered a bug by Gentoo? > > Definitely. Again, we are trying to hard to make things better, but > there's a lot to do and going through version bumps sometimes wins out > over addressing the hard problems. Well, as I see it the two hard problems are (1) the stack-per-python- minor-version solution is ugly and unattractive to users, and (2) the "select python" utility needs to be safe. This probably means that python-using ebuilds need to complain if the Python they find isn't a Python 2 version by default. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyUnicode_Resize
> In Python 3.2, PyUnicode_Resize() expects a number of Py_UNICODE units, > whereas Python 3.3 expects a number of characters. Is that really the case? If the string is not ready (i.e. the kind is WCHAR_KIND), then it does count Py_UNICODE units, no? Callers are supposed to call PyUnicode_Resize only while the string is under construction, i.e. when it is not ready. If they resize it after it has been readied, changes to the Py_UNICODE representation wouldn't be reflected in the canonical representation, anyway. > Should we rename PyUnicode_Resize() in Python 3.3 to avoid surprising bugs? IIUC (and please correct me if I'm wrong) this issue won't cause memory corruption: if they specify a new size assuming it's Py_UNICODE units, but interpreted as code points, then the actual Py_UNICODE buffer can only be larger than expected - right? If so, callers could happily play with Py_UNICODE representation. It won't have the desired effect if the string was ready, but it won't crash Python, either. > The easiest solution is to do nothing in Python 3.3: the API changed, but it > doesn't really matter. Developers just have to be careful on this particular > issue (which is not well documented today). See above. I think there actually is no issue in the first place. Please do correct me if I'm wrong. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Nov 22, 2011, at 12:43 PM, Amaury Forgeot d'Arc wrote: > 2011/11/22 Philip Jenvey > One reason to target 3.2 for now is it's not a moving target. There's > overhead involved in managing modifications to the pure python standard lib > needed for PyPy, tracking 3.3 changes as they happen as well exacerbates this. > > The plans to split the standard lib into its own repo separate from core > CPython will of course help alternative implementations here. > > I don't see how it would help here. > Copying the CPython Lib/ directory is not difficult, even though PyPy made > slight modifications to the files, and even without any merge tool. Pulling in a separate stdlib as a subrepo under the PyPy repo would certainly make this whole process easier. But you're right, if we track CPython's default branch (3.3) we can make many if not all of the PyPy modifications upstream (until the 3.3rc1 code freeze) instead of in PyPy's modified-3.x directory. Maintaining that modified-3.x dir after every resync can be tedious. -- Philip Jenvey ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 380
Mea culpa for not keeping track, but what's the status of PEP 380? I really want this in Python 3.3! -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380
On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote: > Mea culpa for not keeping track, but what's the status of PEP 380? I > really want this in Python 3.3! There are two relevant tracker issues (both with me for the moment). The main tracker issue for PEP 380 is here: http://bugs.python.org/issue11682 That's really just missing the doc updates - I haven't had a chance to look at Zbyszek's latest offering on that front, but it shouldn't be far off being complete (the *text* in his previous docs patch actually seemed reasonable - I mainly objected to way it was organised). However, the PEP 380 test suite updates have a dependency on a new dis module feature that provides an iterator over a structured description of bytecode instructions: http://bugs.python.org/issue11816 I find Meador's suggestion to change the name of the new API to something involving the word "instruction" appealing, so I plan to do that, which will have a knock-on effect on the tests in the PEP 380 branch. However, even once I get that done, Raymond specifically said he wanted to review the dis module patch before I check it in, so I don't plan to commit it until he gives the OK (either because he reviewed it, or because he decides he's OK with it going in without his review and he can review and potentially update it in Mercurial any time before 3.3 is released). I currently plan to update my working branches for both of those on the 3rd of December, so hopefully they'll be ready to go within the next couple of weeks. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
