Re: [Python-Dev] Small RFEs and the Bug Tracker
On 2/23/08, Christian Heimes <[EMAIL PROTECTED]> wrote: > We have over 1,700 open issues - bug reports, feature requests and > patches - in our bug tracker. In my humble opinion it's a sure sign for > a problem. There is also 12000 closed tickets, with 1200 of them having been closed in the last 6 months (well, having had activity in the last 6 month, but I guess that's almost equivalent). The number of issues (open or closed) that have been created in the last 6 months is about 1050. The flow seems healthy to me. Virgil ___ 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] Backporting PEP 3127 to trunk
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)? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Small RFEs and the Bug Tracker
2008/2/23, Virgil Dupras <[EMAIL PROTECTED]>: > > The flow seems healthy to me. > What I don't see healthy is that we have, per week, around 30 issues more open (30 is the difference between those closed, and the new ones). So, the curve is always going up... fast. -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Small RFEs and the Bug Tracker
Facundo Batista wrote: > 2008/2/23, Virgil Dupras <[EMAIL PROTECTED]>: > >> The flow seems healthy to me. >> > > What I don't see healthy is that we have, per week, around 30 issues > more open (30 is the difference between those closed, and the new > ones). > > So, the curve is always going up... fast. > As Andrew says, the only way to "fix" this, if you think it needs fixing, is to recruit new developers and encourage all developers to treat outstanding issues as a higher priority than they currently do. Guido is happy with the current issue count, and relatively few of them are serious. Andrew has been organizing regular bug days. If the count keeps going up that's as much a measure of the increase in use as it is anything else. I do think it would be a good idea to have a crew continually working to address the outstanding issues, but it isn't glamorous work and the fact remains that you need a significant understanding of the ecosphere to fix things in a sanitary way that's acceptable to committers. It would be good to address that issue (shoud we put it in the tracker?), but it would take significant efforts in evangelism and training. Most developers would rather just write code ... Enlarging the pool of committers too quickly probably puts quality control at risk, something I'd be loath to see happen given Python's excellent record in this respect. A larger team (not necessarily all committers) could help us improve quality and reduce the issue count. Deleting issues purely on grounds of age is simply throwing away useful information to reduce a numeric metric that doesn't really relate directly to quality, and quality assurance is the real point of having the tracker. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Small RFEs and the Bug Tracker
2008/2/23, Steve Holden <[EMAIL PROTECTED]>: > A larger team (not necessarily all committers) could help us improve > quality and reduce the issue count. Deleting issues purely on grounds of Exactly, that's why I love Python bug days.. and I'm pushing this hard in Argentina! In the January one, two new argentinian developers worked closing issues, and today a new one is jumping on the train. Also, we did a small bug day, in a Python Camping in Argentina, where we closed 4 or 5 issues, and two more guys learned the whole process (more on this event on other post). This evangelization is very important, IMO. -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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-checkins] r60919 - peps/trunk/pep-0008.txt
On Fri, 22 Feb 2008 18:53:48 -0500 Barry Warsaw <[EMAIL PROTECTED]> wrote: now is > In 50 years, our grandchildren will be writing code with brain > implants and displays burned right into their retina, and they'll / > still/ be subject to 79 characters. I laugh every time I think that > they'll have no idea why it is, but they'll still be unable to change > it. :) There are reasons (other than antiquated media formats) for a coding standard to mandate a line length of 70-80 characters: to improve the readability of the source code. Depending on who (and how) you ask, the most comfortable line length for people to read will vary some, but 70 characters is close to the maximum you'll get, because it gets harder to track back across the page as lines get longer. While code is so ragged that that's probably not as much of a problem, comments aren't. Formatting those to a max of ~70 characters makes them easy to read. Formatting your program so that block comments and code are about the same makes optimal use of the display space. Whether the readability issue has anything to do with why 80 column cards dominated the industry (some were as short as 24 columns, and I could swear I saw a reference to 120-column cards *somewhere*) is left as an exercise for the reader. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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] future_builtins (was: Backporting PEP 3127 to trunk)
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 [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] Backporting PEP 3127 to trunk
On Sat, Feb 23, 2008 at 2:57 AM, Georg Brandl <[EMAIL PROTECTED]> 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)? Good idea, on both counts! These an just be imported from itertools anyway (except they should be wrapped in something that rejects a None function). And zip() ditto. I suggest that if you don't implement this right away (while the bug day is still on :), you at least add a feature request to the issue tracker, marked easy. -- --Guido van Rossum (home page: http://www.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] future_builtins (was: Backporting PEP 3127 to trunk)
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?) 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 > [email protected] > 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 [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] future_builtins
Guido van Rossum wrote: > I don't think a -3 warning for oct or hex would do any good. I'm curious as to why. oct and hex have different behavior in 3.0, which is what I thought -3 was for. hex might be overkill, as the only differences are the "L" and the __hex__ behavior. But oct is always different. ___ 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] future_builtins
On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I don't think a -3 warning for oct or hex would do any good. > > I'm curious as to why. oct and hex have different behavior in 3.0, > which is what I thought -3 was for. hex might be overkill, as the only > differences are the "L" and the __hex__ behavior. But oct is always > different. Well, yeah, but what are you going to do about it? Not use oct()? I expect that *most* programs using oct() or hex() will work just as well under 3.0; typically the output is just printed, not parsed or otherwise further processed. I think -3 should only warn about things where it's easy to modify the code so that it continues to work under 2.6 but will also work under 3.0. Forcing people to use "%o" just to get rid of the warning doesn't make sense to me. -- --Guido van Rossum (home page: http://www.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] future_builtins
Guido van Rossum wrote: > On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith > <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >> > I don't think a -3 warning for oct or hex would do any good. >> >> I'm curious as to why. oct and hex have different behavior in 3.0, >> which is what I thought -3 was for. hex might be overkill, as the only >> differences are the "L" and the __hex__ behavior. But oct is always >> different. > > Well, yeah, but what are you going to do about it? Not use oct()? I > expect that *most* programs using oct() or hex() will work just as > well under 3.0; typically the output is just printed, not parsed or > otherwise further processed. > > I think -3 should only warn about things where it's easy to modify the > code so that it continues to work under 2.6 but will also work under > 3.0. Forcing people to use "%o" just to get rid of the warning doesn't > make sense to me. > My thinking wast that using code that run under -3 without warnings would work exactly the same under 3.0, after running through 2to3. So if oct() gave me a warning, I'd switch to the future_builtins version, and do whatever it took to get my program running again under 2.6 (which might involve not caring that the output changed from 2.5 to 2.6). Maybe it's wishful thinking. I'm not too worried about this specific case, either. ___ 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] future_builtins
On Sat, Feb 23, 2008 at 11:34 AM, Eric Smith <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith > > <[EMAIL PROTECTED]> wrote: > >> Guido van Rossum wrote: > >> > I don't think a -3 warning for oct or hex would do any good. > >> > >> I'm curious as to why. oct and hex have different behavior in 3.0, > >> which is what I thought -3 was for. hex might be overkill, as the only > >> differences are the "L" and the __hex__ behavior. But oct is always > >> different. > > > > Well, yeah, but what are you going to do about it? Not use oct()? I > > expect that *most* programs using oct() or hex() will work just as > > well under 3.0; typically the output is just printed, not parsed or > > otherwise further processed. > > > > I think -3 should only warn about things where it's easy to modify the > > code so that it continues to work under 2.6 but will also work under > > 3.0. Forcing people to use "%o" just to get rid of the warning doesn't > > make sense to me. > My thinking wast that using code that run under -3 without warnings > would work exactly the same under 3.0, after running through 2to3. That's wishful thinking. :) > So if oct() gave me a warning, I'd switch to the future_builtins version, > and do whatever it took to get my program running again under 2.6 (which > might involve not caring that the output changed from 2.5 to 2.6). > Maybe it's wishful thinking. I'm not too worried about this specific > case, either. I think practicality says we should not warn about this. -- --Guido van Rossum (home page: http://www.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
[Python-Dev] Mutex module
Hi! In today's bug day, an Argentinian colleague called my attention over the issue 1746071. This issue is about mutex: """The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks. It does not require (or imply) threading or multi-tasking, though it could be useful for those purposes.""" The problem here is that mutex is NOT thread safe! Even when it says in the docs that it could be useful for threading! "Ok, let's make this mutex to be thread-safe", I thought, and my colleague reviewed the proposed patch, even finding and submitting a correction to it. But two points prevented me for further work here: - It has not test cases at all - It does something that could be easily done (today) using parts from the threading module. There're some comments in that issue that points towards a deprecation of this module. So, I'm asking here. Is it still working in 3k? What are the plans here? What do you think about this module? Is somebody using it? Thank you all! Regards, [1] http://bugs.python.org/issue1746071 [2] http://docs.python.org/dev/library/mutex.html -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Fwd: Mutex module
-- Forwarded message -- From: Guido van Rossum <[EMAIL PROTECTED]> Date: Sat, Feb 23, 2008 at 1:26 PM Subject: Re: [Python-Dev] Mutex module To: Facundo Batista <[EMAIL PROTECTED]> According to the docstring it's only meant to be used with sched.py. Please don't try to make it work with threads! Maybe this needs to be moved into a "simulations" package in 3.0? On Sat, Feb 23, 2008 at 1:22 PM, Facundo Batista <[EMAIL PROTECTED]> wrote: > Hi! > > In today's bug day, an Argentinian colleague called my attention over > the issue 1746071. > > This issue is about mutex: > > """The mutex module defines a class that allows mutual-exclusion via > acquiring and releasing locks. It does not require (or imply) > threading or multi-tasking, though it could be useful for those > purposes.""" > > The problem here is that mutex is NOT thread safe! Even when it says > in the docs that it could be useful for threading! > > "Ok, let's make this mutex to be thread-safe", I thought, and my > colleague reviewed the proposed patch, even finding and submitting a > correction to it. > > But two points prevented me for further work here: > > - It has not test cases at all > > - It does something that could be easily done (today) using parts from > the threading module. > > There're some comments in that issue that points towards a deprecation > of this module. > > So, I'm asking here. Is it still working in 3k? What are the plans > here? What do you think about this module? Is somebody using it? > > Thank you all! Regards, > > [1] http://bugs.python.org/issue1746071 > [2] http://docs.python.org/dev/library/mutex.html > > -- > .Facundo > > Blog: http://www.taniquetil.com.ar/plog/ > PyAr: http://www.python.org/ar/ > ___ > Python-Dev mailing list > [email protected] > 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/) -- --Guido van Rossum (home page: http://www.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] Fwd: Mutex module
2008/2/23, Guido van Rossum <[EMAIL PROTECTED]>: > According to the docstring it's only meant to be used with sched.py. > Please don't try to make it work with threads! Maybe this needs to be > moved into a "simulations" package in 3.0? Ok, I'll close the issue with this, and forward this mail to the stdlib reorg for proper handling. Thank you! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Fwd: Mutex module
2008/2/23, Facundo Batista <[EMAIL PROTECTED]>: > Ok, I'll close the issue with this, and forward this mail to the > stdlib reorg for proper handling. 1. Done 2. It was already taken care of in the stdlib reorg sheet (it will be removed, or at least its api hidden, in 3.0) Thank you! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Small RFEs and the Bug Tracker
Facundo Batista writes: > 2008/2/23, Virgil Dupras <[EMAIL PROTECTED]>: > > The flow seems healthy to me. +1 > What I don't see healthy is that we have, per week, around 30 issues > more open (30 is the difference between those closed, and the new > ones). > > So, the curve is always going up... fast. This merely means that Python users are applying Python to problems that the current set of developers never imagined. As long as the flow of solved issues is increasing, that's a symptom of strength, not weakness. If that curve ever turns down, it means that users are giving up on Python as a tool for solving ever harder problems. That's where it gets scarey. ___ 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-3000] Python 2.6 and 3.0
+1 to everything -- n On Fri, Feb 22, 2008 at 3:45 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > 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 :). I would like to get the next alpha releases of both > versions out before Pycon, so I propose next Friday, February 29 for > both. > > 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? > - -Barry > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.8 (Darwin) > > iQCVAwUBR79ek3EjvBPtnXfVAQJrmQP+KAzy0lSzake2BZsVxErD0kpFQJM+Iij0 > qN86wjH0NoqARMfYKVA6eUzEY8vZPu7sJl+SjCOmhnE/KP+l/ArOdis5smiSKwQI > klL4XKd/qdorTMqQ9mWgA0DeBb0Asvln9y64nxzNqgve+36q9j6ytPuRey1GjSI5 > nVWoJDb3WsM= > =4SRa > -END PGP SIGNATURE- > ___ > Python-3000 mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/nnorwitz%40gmail.com > ___ 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] Small RFEs and the Bug Tracker
2008/2/23, Stephen J. Turnbull <[EMAIL PROTECTED]>: > If that curve ever turns down, it means that users are giving up on > Python as a tool for solving ever harder problems. That's where it > gets scarey. It depends. If that happens because no new issues are found, maybe (it could happen also that Python gets more and more solid). But if we solve more issues than which are opened, that is good too, :) -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] can't set attributes of built-in/extension type
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?) ___ 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] can't set attributes of built-in/extension type
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. -- --Guido van Rossum (home page: http://www.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] future_builtins (was: Backporting PEP 3127 to trunk)
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] (Side note, shouldn't we change the names for filter/map?) n ___ 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] can't set attributes of built-in/extension type
> (Or, help me understand, what is the difference between a type that I create > using python C api and a python class?) Grepping for the specific error message would have answered that question: Python (new-style) classes have the Py_TPFLAGS_HEAPTYPE set, types declared as static structs in C don't. 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] Proposed revision of PEP 3 (using the issue tracker)
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. I'd prefer to keep an outright 'invalid' for the cases where the reporter was either genuinely wrong about the intended behaviour, or where the bug report itself is manifestly inadequate (e.g. "I tried to do xyz and it broke" with no further details). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Proposed revision of PEP 3 (using the issue tracker)
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? Ron > I'd prefer to keep an outright 'invalid' for the cases where the > reporter was either genuinely wrong about the intended behaviour, or > where the bug report itself is manifestly inadequate (e.g. "I tried to > do xyz and it broke" with no further details). > > Cheers, > Nick. > ___ 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] Proposed revision of PEP 3 (using the issue tracker)
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. -Brett ___ 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] can't set attributes of built-in/extension type
Neal Becker wrote: > (Or, help me understand, what is the difference between a type that I create > using python C api and a python class?) Classes that you create in Python have a __dict__ attribute holding a dictionary for arbitrary attributes to go in. Most types defined in C don't bother providing a __dict__, since one doesn't normally need to add arbitrary attributes to them, and the overhead would be almost completely wasted. -- Greg ___ 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
