Re: [Python-Dev] Proposed revision of PEP 3 (using the issue tracker)
Brett Cannon wrote: > On Sat, Feb 23, 2008 at 10:17 PM, Ron Adam <[EMAIL PROTECTED]> wrote: >> >> Nick Coghlan wrote: >> > Martin v. Löwis wrote: >> >> One issue to consider is also politeness. People sometimes complain that >> >> they feel treated unfair if their report is declared "invalid" - they >> >> surely believed it was a valid report, at the time they made it. >> > >> > I agree with Martin for both of these - 'works for me' and 'out of date' >> > convey additional information to the originator of the bug, even if they >> > don't make a signifcant difference from a development point of view. >> >> The term 'works for me' can be confused with 'solution/patch works for me'. >> I've generally seen the phrase 'works for me' to mean agreement of a >> proposed action of some sort. >> >> Maybe something along the lines of 'can not reproduce' would be better? > > I have to agree with Ron. I honestly thought "works for me" meant the > solution worked. Something less ambiguous would be nice. > +1 for "cannot reproduce". regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed revision of PEP 3 (using the issue tracker)
Steve Holden wrote: > +1 for "cannot reproduce". "cannot reproduce" is ambiguous in a slightly different, more family oriented manner ... :] Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed revision of PEP 3 (using the issue tracker)
Ron Adam wrote: > Nick Coghlan wrote: > >> Martin v. Löwis wrote: >> >>> One issue to consider is also politeness. People sometimes complain that >>> they feel treated unfair if their report is declared "invalid" - they >>> surely believed it was a valid report, at the time they made it. >>> >> I agree with Martin for both of these - 'works for me' and 'out of date' >> convey additional information to the originator of the bug, even if they >> don't make a signifcant difference from a development point of view. >> > > The term 'works for me' can be confused with 'solution/patch works for me'. > I've generally seen the phrase 'works for me' to mean agreement of a > proposed action of some sort. > > Maybe something along the lines of 'can not reproduce' would be better? > > +1 for 'can not reproduce' or perhaps 'can not duplicate' # Steve ___ Python-Dev mailing list Python-Dev@python.org 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 2.6 and 3.0
Barry Warsaw wrote: > I'd also like for us to consider doing regular monthly releases. > Several other FLOSS projects I'm involved with are doing this to very > good success. The nice thing is that everyone knows well in advance > when the next release is going to happen, and so all developers and > users know what to expect and what is needed from them. > > I'd like to propose that we do a joint release the last Friday of > every month. For the alphas, it's basically what's in svn. This > gives us some time to experiment with the process out and see if we > like it enough to keep it going through the betas and final releases. Thanks for volunteering for the job, Barry! +1 for release early, release often but I want to point out a resource issue that may speak against a monthly release cycle. The Windows binaries still require a large amount of attention and human interaction. The last Windows binaries were build by me and I spent half the night ironing out issues and testing the installers. As far as I know the team only Martin and I have the infrastructure and tools to build the Windows binaries. We could cut down the time requirements by shipping only normal binaries instead of PGO (profile guided optimization) binaries. IMHO we could also skip the AMD64 builds until we have reached beta stage. But it's still going to cost either Martin or me the better half of a Friday night. I won't have time to assist with the Windows builds next Friday. I'm more than busy with personal life and job interviews. Hopefully I'm going to find a job that allows me to work on the Python core as much as during the past few months. That's for the Windows builds. Now I have a list of bugs and features I like to see fixed / applied before the next release: http://bugs.python.org/issue1692335 Fix exception pickling: Move initial args assignment to BaseException.__new__ http://bugs.python.org/issue1792 (trivial performance patch for marshal) http://bugs.python.org/issue1569 MS VCRT redist issue. IIRC Martin had a working solution for it in his sandbox. http://bugs.python.org/issue1657 my kqueue and epoll patch, just needs another review Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] can't set attributes of built-in/extension type
Guido van Rossum wrote: > On Sat, Feb 23, 2008 at 4:55 PM, Neal Becker <[EMAIL PROTECTED]> wrote: >> There is some discussion on this subject, archived here: >> http://permalink.gmane.org/gmane.comp.python.general/560661 >> >> I wonder if anyone could shed some light on this subject? >> >> (Or, help me understand, what is the difference between a type that I >> create using python C api and a python class?) > > This is prohibited intentionally to prevent accidental fatal changes > to built-in types (fatal to parts of the code that you never though > of). Also, it is done to prevent the changes to affect different > interpreters residing in the address space, since built-in types > (unlike user-defined classes) are shared between all such > interpreters. > Thanks for the info. I'm still curious. What if I wanted to create a 'real' python class using python c-api? How is that done? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] can't set attributes of built-in/extension type
On Sun, Feb 24, 2008 at 6:49 AM, Neal Becker <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > > On Sat, Feb 23, 2008 at 4:55 PM, Neal Becker <[EMAIL PROTECTED]> wrote: > >> There is some discussion on this subject, archived here: > >> http://permalink.gmane.org/gmane.comp.python.general/560661 > >> > >> I wonder if anyone could shed some light on this subject? > >> > >> (Or, help me understand, what is the difference between a type that I > >> create using python C api and a python class?) > > > > This is prohibited intentionally to prevent accidental fatal changes > > to built-in types (fatal to parts of the code that you never though > > of). Also, it is done to prevent the changes to affect different > > interpreters residing in the address space, since built-in types > > (unlike user-defined classes) are shared between all such > > interpreters. > > > > Thanks for the info. > > I'm still curious. What if I wanted to create a 'real' python class using > python c-api? How is that done? Use PyObject_Call() or one of its friends to call PyType_Type with the appropriate arguments (a name, a tuple of base classes, and a dict of methods etc.). This is the same as calling type(name, bases, namespace) from Python. The type object will be on the heap and fully mutable. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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-3000] Python 2.6 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 22, 2008, at 6:54 PM, Brett Cannon wrote: >> Hi everyone, >> >> I've volunteered to be the release manager for Python 2.6 and 3.0. >> It's been several years since I've RM'd a Python release, and I'm >> happy to do it again (he says while the medication is still >> working :). > > Can the PSF buy you more of the meds? =) Depends on the jurisdiction. :) >> I would like to get the next alpha releases of both >> versions out before Pycon, so I propose next Friday, February 29 for >> both. >> > > Since they are just alphas, sure. Not like I am going to make any > earth-shattering changes that soon. Cool. >> Guido reminded me that we released Python 1.6 and 2.0 together and it >> makes sense to both of us to do the same for Python 2.6 and 3.0. I >> don't think it will be that much more work (for me at least :) to >> release them in lockstep, so I think we should try it. I won't try >> to >> sync their pre-release version numbers except at the milestones (e.g. >> first beta, release candidates, final releases). >> >> I propose to change PEP 361 to outline the release schedule for both >> Python 2.6 and 3.0. I'm hoping we can work out a more definite >> schedule at Pycon, but for now I want to at least describe the >> lockstep release schedule and the Feb 29 date. >> >> I'd also like for us to consider doing regular monthly releases. >> Several other FLOSS projects I'm involved with are doing this to very >> good success. The nice thing is that everyone knows well in advance >> when the next release is going to happen, and so all developers and >> users know what to expect and what is needed from them. >> >> I'd like to propose that we do a joint release the last Friday of >> every month. For the alphas, it's basically what's in svn. This >> gives us some time to experiment with the process out and see if we >> like it enough to keep it going through the betas and final releases. >> >> Comments? > > If you want to do monthly alphas, go for it! But if you are going to > do that frequently is a source release going to make more sense than > doing binary builds? It very well might. See Christian Heimes's follow up re: Windows builds. OTOH, I'm okay if at least for the alphas, the binary builds lag behind the source releases, though I'd like to get the process as streamlined as possible. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8GunXEjvBPtnXfVAQIP0AQAo5F2tH1vXWbMAFGARZN576xopbQXSokX uVNXbeg5yjopCx38sHb5OCbublyIDOO8/2ubuuQ6uvAOJc3Br4BuMGHoC5ymQGqf 6pZYZLf4YUGLqFlYOB/huXpJPfH98RJJnK99zA8IQh4B7pN4xg14MF22gGij3Ybt z2hoy1EbYEk= =hW7b -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org 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-3000] Python 2.6 and 3.0
> It very well might. See Christian Heimes's follow up re: Windows > builds. OTOH, I'm okay if at least for the alphas, the binary builds > lag behind the source releases, though I'd like to get the process as > streamlined as possible. I can continue to provide Windows binaries if desired. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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-3000] Python 2.6 and 3.0
-On [20080224 19:57], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote: >I can continue to provide Windows binaries if desired. If need be, I can help testing the build infrastructure since I have access to various releases of Visual Studio as well. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ What's in a name? That which we call a rose by any other name would smell as sweet... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] future_builtins (was: Backporting PEP 3127 to trunk)
On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I don't think a -3 warning for oct or hex would do any good. > > I do think map() and filter() should issue a warning under -3 when the > first arg is None. (Or does 2to3 detect this now?) 2to3 does detect that: it will turn map(None, foo) into list(foo). > On Sat, Feb 23, 2008 at 6:06 AM, Eric Smith > <[EMAIL PROTECTED]> wrote: > > Georg Brandl wrote: > > > Eric Smith schrieb: > > >> Guido van Rossum wrote: > > >>> I wonder if, in order to change the behavior of various built-in > > >>> functions, it wouldn't be easier to be able to write > > >>> > > >>> from future_builtins import oct, hex # and who knows what else > > >> This makes sense to me, especially if we have a 2to3 fixer which > removes > > >> this line. I'll work on implementing future_builtins. > > > > > > Will the future map and filter also belong there (and if they are > imported > > > from future_builtins, 2to3 won't put a list() around them)? > > > > I can certainly do the mechanics of adding the new versions of map and > > filter to future_builtins, if it's seen as desirable. > > > > Maybe we could have 2to3 not put list() around map and filter, if > > there's been an import of future_builtins. I realize that there are > > pathological cases where 2to3 doesn't know that a usage of map or filter > > would really be the generator version from future_builtins, as opposed > > to the actual list-producing builtins. But would it be good enough to > > take an import of future_builtins as a hint that the author was aware > > that 2to3 wasn't going to change map and filter? > > > > Still an open issue in my mind is adding a -3 warning to oct and hex, > > and now conceivably map and filter. Would that be going too far? > > > > Eric. > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/collinw%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use Python 3.0 syntax for except and raise?
On Mon, Feb 18, 2008 at 3:44 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I don't know if you're done with this already, but there's a lot of > experience suggesting such sweeps are quite dangerous. In the past, > whenever a sweep across the entire stdlib was done, it's always caused > a few breakages, some of which didn't get caught until the next > release. > > Things to worry about with these two changes: > > raise X, y -> raise X(y): this is incorrect if y is a tuple; *only* if > it's a tuple, the correct translation is raise X(*y). But 2to3 can't > know that (unless the tuple is written out in place). Yep. That's something I'd eventually like to correct by adding an interactive mode (if 2to3 is unsure about a given fix, it can ask the user). It's on my todo list for PyCon. Collin Winter > except X as y: in 3.0 this has different semantics -- y is explicitly > deleted at the end of the except block. I don't know if this is also > the semantics implemented in 2.6 (I think it should be), but again > this can cause som equite subtle breakages that are hard to catch > automatically. > > And since both of these are about exceptions, there's a high > likelihood that some occurrences are not reached by a unittest. > > IOW, while I'm not dead set against it (I agree with your motivation > in principle) I worry that in practice it may destabilize things., and > would prefer a different approach where these things are only changed > when someone is revising the module anyway. > > --Guido > > > On Feb 17, 2008 8:57 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > > > > Good evening everybody! > > > > I like to run the 2to3 tool with raise and except fixers over the 2.6 > > sources. The raise fixer changes "raise Exception, msg" to "raise > > Exception(msg)" and the except fixer replaces "except Exception, err" by > > "except Exception as err". In my humble opinion the Python stdlib should > > give proper examples how write good code. > > > > During the migration period from the 2.x series to 3.x we have two > > obvious ways to write code. Let's stick to the new and preferred way. > > > > Oh and please use the new syntax for patches, too. It makes my job with > > svnmerge a little bit easier. > > > > Thanks! > > > > Christian > > > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/collinw%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org 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-3000] Python 2.6 and 3.0
Jeroen Ruigrok van der Werven: > -On [20080224 19:57], "Martin v. Lwis" ([EMAIL PROTECTED]) wrote: > >I can continue to provide Windows binaries if desired. > > If need be, I can help testing the build infrastructure since I have > access > to various releases of Visual Studio as well. Me too - I still regularly build the svn version of Python, and although I don't regularly turn them into .MSI files, I'm confident I could learn how to do that ;) I understand that over time the binary process will need some tweaking, but in the general case, I expect that turning the crank for a test build needn't be that much or a burden. I expect the biggest problem is that I could no longer ignore certain extensions I don't care about, such as Tk. Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Downloads Page
Hello all, The downloads page on python.org shows 2.5.1 as the latest release: http://python.org/download/ Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Downloads Page
Michael> The downloads page on python.org shows 2.5.1 as the latest Michael> release: Michael> http://python.org/download/ Thanks. I just checked in a change. I'm not sure how long it takes to update the website, but it should be fairly soon. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed revision of PEP 3 (usingthe issue tracker)
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] |Martin v. Löwis wrote: |> One issue to consider is also politeness. People sometimes complain that |> they feel treated unfair if their report is declared "invalid" - they |> surely believed it was a valid report, at the time they made it. |I agree with Martin for both of these - 'works for me' and 'out of date' |convey additional information to the originator of the bug, even if they |don't make a signifcant difference from a development point of view. It seems to me that the place to convey real information to the originator is in the closing comment -- as the PEP requires. "Works for me' can hardly work if we cannot agree on the meaning. And why is its usage restricted to 'developers' as opposes to 'reviewers' like me? In any case, I have a more radical proposal: drop the disposition field altogether and split the 'closed' status into two. First, closed because we have completed a non-empty set of actions (changes); in other words, 'finished'. Second, closed because we decide not to do anything; in other words, 'rejected'. This proposal eliminates altogether the impoliteness of 'invalid'. 'Invalid' is an possibly debateble opinion (even though backed by facts) about the originators issue. 'Rejected' is a non-debateble and truthful statement of a decision to not act. This proposal also eliminates the the redundancy between a non-empty disposition and the 'closed' status implied by such. It is not uncommon for people to mark a disposition and explain the reason for closure while leaving the status as 'open'. Or to close and explain and leave the disposition blank. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] optimizing out local variables
Short description (see http://bugs.python.org/issue2181 for the patch and more details): Optimize code like: x = any_expression return x to: return any_expression The local variable x is no longer set before returning. Is this appropriate for .pyc generation or should it only be done for .pyo files? n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] February bug day outcome
Yesterday's bug day was another success, closing 48 issues. Several committers were there: Facundo Bastista, Georg Brandl, and Christian Heimes. Facundo organized a local group of participants, and we committed a number of contributions from new people. Should we have one next month? The PyCon sprint will fall on Monday through Thursday, and few people not at PyCon will be available during the work week. OTOH, if we scheduled a bug day for the 29th, that's two weeks after the conference, and we may have recovered from our PyCon burnout at that point. What do people think? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] optimizing out local variables
On Sun, Feb 24, 2008 at 6:27 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > Short description (see http://bugs.python.org/issue2181 for the patch > and more details): > > Optimize code like: >x = any_expression >return x > > to: >return any_expression > > The local variable x is no longer set before returning. Is this > appropriate for .pyc generation or should it only be done for .pyo > files? I don't see how this is any more aggressive than what the peepholer already does, so I see no issue with it being used in .pyc files. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] optimizing out local variables
Let's only do it for -O; the optimization may interfere with debugging the code. On Sun, Feb 24, 2008 at 6:27 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > Short description (see http://bugs.python.org/issue2181 for the patch > and more details): > > Optimize code like: >x = any_expression >return x > > to: >return any_expression > > The local variable x is no longer set before returning. Is this > appropriate for .pyc generation or should it only be done for .pyo > files? > > n > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] future_builtins (was: Backporting PEP 3127 to trunk)
On Sat, Feb 23, 2008 at 5:59 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > I do think map() and filter() should issue a warning under -3 when the > > first arg is None. (Or does 2to3 detect this now?) > > What's wrong with filter(None, seq)? That currently works in 3k: > > >>> filter(None, range(5)) > > >>> [x for x in _] > [1, 2, 3, 4] But that's a bug -- it's been spec'ed that this will stop working. (Can't remember where, perhaps PEP 3100?) > (Side note, shouldn't we change the names for filter/map?) Huh? What? Why? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] future_builtins (was: Backporting PEP 3127 to trunk)
On Sun, Feb 24, 2008 at 6:57 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Sat, Feb 23, 2008 at 5:59 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <[EMAIL PROTECTED]> > wrote: > > > > > > I do think map() and filter() should issue a warning under -3 when the > > > first arg is None. (Or does 2to3 detect this now?) > > > > What's wrong with filter(None, seq)? That currently works in 3k: > > > > >>> filter(None, range(5)) > > > > >>> [x for x in _] > > [1, 2, 3, 4] > > But that's a bug -- it's been spec'ed that this will stop working. > (Can't remember where, perhaps PEP 3100?) I looked in 3100 and didn't see it. > > (Side note, shouldn't we change the names for filter/map?) > > Huh? What? Why? The function name returned by repr: itertools.ifilter. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] February bug day outcome
On Sun, Feb 24, 2008 at 6:52 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > Yesterday's bug day was another success, closing 48 issues. Several > committers were there: Facundo Bastista, Georg Brandl, and Christian > Heimes. Facundo organized a local group of participants, and we > committed a number of contributions from new people. > > Should we have one next month? The PyCon sprint will fall on Monday > through Thursday, and few people not at PyCon will be available during > the work week. OTOH, if we scheduled a bug day for the 29th, that's > two weeks after the conference, and we may have recovered from our > PyCon burnout at that point. What do people think? I'd rather push it out to mid-month assuming Barry starts releasing alphas at the end of each month. That should provide some time to stabalize. Any one see the buildbots recently? :-( http://www.python.org/dev/buildbot/all/ n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] future_builtins (was: Backporting PEP 3127 to trunk)
On Sun, Feb 24, 2008 at 7:02 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On Sun, Feb 24, 2008 at 6:57 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Sat, Feb 23, 2008 at 5:59 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > > On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <[EMAIL PROTECTED]> > wrote: > > > > > > > > I do think map() and filter() should issue a warning under -3 when > the > > > > first arg is None. (Or does 2to3 detect this now?) > > > > > > What's wrong with filter(None, seq)? That currently works in 3k: > > > > > > >>> filter(None, range(5)) > > > > > > >>> [x for x in _] > > > [1, 2, 3, 4] > > > > But that's a bug -- it's been spec'ed that this will stop working. > > (Can't remember where, perhaps PEP 3100?) > > I looked in 3100 and didn't see it. Hm. Well, it's still the plan. > > > (Side note, shouldn't we change the names for filter/map?) > > > > Huh? What? Why? > > The function name returned by repr: itertools.ifilter. I see. Yes, that's a bug. You could say that the way map and filter are implemented in py3k at the moment is a prototype. I'll file bugs for both of these. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] optimizing out local variables
On 2/24/08, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Let's only do it for -O; the optimization may interfere with debugging the > code. Does anyone ever actually bother to use -O? On Sun, Feb 24, 2008 at 6:27 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > > Short description (see http://bugs.python.org/issue2181 for the patch > > and more details): > > > > Optimize code like: > >x = any_expression > >return x > > > > to: > >return any_expression > > > > The local variable x is no longer set before returning. Is this > > appropriate for .pyc generation or should it only be done for .pyo > > files? > > > > n > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > http://mail.python.org/mailman/listinfo/python-dev > > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
