Re: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
Skip Montanaro wrote: > Why not just skip the specifics except to say < 80 characters for all > lines? Don't mention 72, 79 or any other number than 80: I often run "svn diff" in a console limited to 80 characters. Because of the leading "+", lines longer than 78 wrap, and the output is more difficult to read. -- Amaury Forgeot d'Arc ___ 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-checkins] r60919 - peps/trunk/pep-0008.txt
And this is then compounded if you then proceed to diff those diff outputs. Maybe we should just use vertical spacing? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Amaury Forgeot d'Arc > Sent: Friday, February 22, 2008 08:01 > To: Skip Montanaro > Cc: python-dev Dev > Subject: Re: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep- > 0008.txt > > Skip Montanaro wrote: > > Why not just skip the specifics except to say < 80 characters for all > > lines? Don't mention 72, 79 or any other number than 80: > > I often run "svn diff" in a console limited to 80 characters. > Because of the leading "+", lines longer than 78 wrap, and the output > is more difficult to read. > ___ 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] int/float freelists vs pymalloc
Vladimir Marangozov wrote: > May I chime in? :-) Please do! > Gents, the current implementation of Python's memory management > is really fine and most problems it used to have in the past > have been fixed in recent years (at least the ones I know of). > > Probably the only one left, indeed, is the potential unbounded > growth of int/float objects' freelists (beyond the shared cache > of small ints). Yet, this seems to be a questionable problem > because any change in the freelists' management will invariably > slow down their allocation. By how much, I don't know, but > whether you fallback to pymalloc above a certain threshold or > use something else, the change will have a generic perf hit. The performance hit is there, but my testing indicates its mostly not dramatic (& when its dramatic it only shows in microbenchmarks...). For me, "dramatic" is more than 10% gain/loss in non-trivial benchmarks. > The explanation is simple: you can't beat the free list scheme > performance when you have frequent short bursts of allocations > and deallocations, which is the typical Python pattern observed > on New() & DECREF() calls. I never expected that it could be beaten. I set out to find out how close simple alloc/dealloc via PyMalloc was to the freelists, and my testing suggests its pretty close, to the point that only the int & tuple freelists have IMO a clear-cut claim to retention. > BTW if you have 2 AMD combos showing speedups noone can explain > in an obvious way, then it's a cache effect. Figured as much. No-one with an intel CPU (or a different compiler) has as yet offered any equivalent test results - I would very much like to see them, but I'm not prepared ATM to buy another box to find out... > Optimizing pymalloc for non-standard byte-sizes is a no go, and > although I've seen suggestions for further optimizations tailored > to ints and floats, I haven't seen anyone spelling out what that > optimization of pymalloc would consist of. I figured Tim Peters would have done pretty much anything that could have been done when he polished PyMalloc up for default use in 2.3. > MAL's suggestion to preallocate a pymalloc pool cache for certain > object sizes is something I actually implemented in the earliest > versions of pymalloc, but eventually dropped in favor of the > current dynamic, on-request allocation because pre-allocating pools > (and initializing the free lists) costs time and in general leads > to degraded performance in the average case. I can't perf this > now to prove it, but that was very clear at the time when I wrote > the original stuff and applied the regression test on it. Good to know that alley has been checked and found a dead end. > So I would kindly suggest to get down to the only problem (if any) > which is the uncontrolled growth of the specialized freelists, the > shared int cache notwithstanding. If you can limit a degenerative > growth without a noticeable generic perf sacrifice, that would > sound like an improvement to me, but so far I haven't seen any > convincing arguments. Christian's compaction routine will get the job done, but IMO it should be (as he himself has proposed) called from gc.collect() rather than callable as a function in sys. > And, of course, if the int/float freelist scheme was a real issue > we would have probably heard of it by now in a very sound way. Not much noise has been made here, but I've come across 2 separate complaints in different mailing lists in the last month (one of the complainants had some hope that gc.collect() might help...) Is it a deafening roar? No, but I doubt the volume will do anything but increase... Regards, Andrew. -- - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ 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] Small RFEs and the Bug Tracker
Gregory P. Smith wrote: > I'm always faced with a tiny quandry when closing a fixed bug that had a > patch to fix it attached because both seem to apply. ;-) I try to use 'fixed' for those, with my closure comment indicating whether the fix used the attached patch (or a variant thereof) or something completely different. Combining 'fixed' and 'accepted' into something generic like 'resolved' is no good, since 'not a bug' is also a resolution from our point of view, even if the original author of the issue may not particularly like the answer :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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
Re: [Python-Dev] Small RFEs and the Bug Tracker
2008/2/21, Brett Cannon <[EMAIL PROTECTED]>: > Something like "handle" or "resolved". An issue is an issue and we > wanting a single way to say the issue was closed because what is was > about was handled seems reasonable. +1 to resolved. -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Small RFEs and the Bug Tracker
2008/2/21, "Martin v. Löwis" <[EMAIL PROTECTED]>: > It's possible to "retire" objects in Roundup: certain resolution values > would still be present and referenced by issues that use it, but they > would not appear anymore in the drop-down list. We can go one step further: If we change "fixed" and "accepted" as "resolved" (for example), we can change all the values directly in the database, so they all appear as "resolved" now. I don't want to propose anything specific regarding words, I'm just saying that having eleven options to close an issue are too many if we want to keep consistency. Note that they're not clear enough to make them obvious, otherwise the consensus in this thread would have been faster, ;) Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Small RFEs and the Bug Tracker
2008/2/22, Nick Coghlan <[EMAIL PROTECTED]>: > Combining 'fixed' and 'accepted' into something generic like 'resolved' > is no good, since 'not a bug' is also a resolution from our point of > view, even if the original author of the issue may not particularly like > the answer :) First two definitions of "resolve" from the American Heritage dict: 1. To make a firm decision about. 2. To cause (a person) to reach a decision. I think it applies quite well. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Small RFEs and the Bug Tracker
Facundo Batista wrote: > First two definitions of "resolve" from the American Heritage dict: > > 1. To make a firm decision about. > 2. To cause (a person) to reach a decision. > > I think it applies quite well. It only tells you that a resolution was reached, not what that resolution was. "Resolution: resolved" is meaningless repetition - what matters is *how* the issue was resolved, and simply saying 'resolved' doesn't tell anybody that. 'Fixed', 'accepted', 'invalid', 'rejected' , etc are resolutions since they give you some idea of how the issue was resolved - the only thing missing is a definition of just how they should be used.* Now, dropping 'later', 'postponed' and 'remind' from the list of available resolutions is something I could wholeheartedly support. If we want to postpone something to a later release, we should put an appropriate entry in the version list. My stab at definitions for the other resolutions: # Feature request resolutions accepted - feature request accepted (possibly via attached patch) rejected - feature request rejected # Bug report resolutions fixed - reported bug fixed (possibly via attached patch) invalid - reported behaviour is intentional and not a bug works for me - bug could not be replicated from bug report out of date - bug is already fixed in later Python version wont fix - valid bug, but not fixable in CPython (very rare) # Common resolutions duplicate - same as another issue (refer to other issue in a comment) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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
Re: [Python-Dev] Small RFEs and the Bug Tracker
2008/2/22, Nick Coghlan <[EMAIL PROTECTED]>: > Now, dropping 'later', 'postponed' and 'remind' from the list of > available resolutions is something I could wholeheartedly support. If we > want to postpone something to a later release, we should put an > appropriate entry in the version list. > > My stab at definitions for the other resolutions: > ># Feature request resolutions >accepted - feature request accepted (possibly via attached patch) >rejected - feature request rejected > ># Bug report resolutions >fixed - reported bug fixed (possibly via attached patch) >invalid - reported behaviour is intentional and not a bug >works for me - bug could not be replicated from bug report >out of date - bug is already fixed in later Python version >wont fix - valid bug, but not fixable in CPython (very rare) > ># Common resolutions >duplicate - same as another issue (refer to other issue in a comment) Fair enough. There's missing one use case: how we mark an issue that is not such? I'm talking about issues opened without an explanation, nothing saying what is wrong, or which behaviour is strange or wrong for the original poster, etc. Those issues that you want to answer "go back and learn how to explain yourself". Thanks! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Tomorrow's bug day and issue #1858
Hello, I have prepared a request for enhancement for distutils, together with its patch that also adds more tests for the package. This was discussed in catalog-sig, and explained here : http://wiki.python.org/moin/EnhancedPyPI (see pypirc section). I have followed Brett Cannon's slides to make the patch on the 2.6 trunk (great doc thanks!). I would like to propose this rfe tomorrow at the bug day, amongst other bugs I can try to work on. But I don't know if I should propose it here first since it was previously discussed on catalog-sig, so here it is :) Regards Tarek Ziadé -- View this message in context: http://www.nabble.com/Tomorrow%27s-bug-day-and-issue--1858-tp15634227p15634227.html Sent from the Python - python-dev mailing list archive at Nabble.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] Small RFEs and the Bug Tracker
Nick Coghlan schrieb: > Facundo Batista wrote: >> First two definitions of "resolve" from the American Heritage dict: >> >> 1. To make a firm decision about. >> 2. To cause (a person) to reach a decision. >> >> I think it applies quite well. > > It only tells you that a resolution was reached, not what that > resolution was. > > "Resolution: resolved" is meaningless repetition - what matters is *how* > the issue was resolved, and simply saying 'resolved' doesn't tell > anybody that. 'Fixed', 'accepted', 'invalid', 'rejected' , etc are > resolutions since they give you some idea of how the issue was resolved > - the only thing missing is a definition of just how they should be used.* > > Now, dropping 'later', 'postponed' and 'remind' from the list of > available resolutions is something I could wholeheartedly support. If we > want to postpone something to a later release, we should put an > appropriate entry in the version list. +1 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 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-checkins] r60919 - peps/trunk/pep-0008.txt
>> Why not just skip the specifics except to say < 80 characters for all >> lines? Don't mention 72, 79 or any other number than 80: Amaury> I often run "svn diff" in a console limited to 80 characters. Amaury> Because of the leading "+", lines longer than 78 wrap, and the Amaury> output is more difficult to read. There will always be certain cases which present probems. I use "svn annotate" from time-to-time which adds an even wider margin to the left. In those situations I either grin and bear it or stretch my window enough to view it without wrapping. 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] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
On Fri, Feb 22, 2008 at 10:12:16AM -0600, [EMAIL PROTECTED] wrote: > I use "svn > annotate" from time-to-time which adds an even wider margin to the left. > In those situations I either grin and bear it or stretch my window enough to > view it without wrapping. svn blame | less -S Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Backporting PEP 3127 to trunk
On Thu, Feb 21, 2008 at 6:54 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Eric Smith] > > > Speaking for myself, these features are generally useful, > > and are so even without the new integer literal syntax. > > I'm curious how these are useful to you in Py2.6 where > they are not invertible. In Py3.0, we can count on > > x == int(bin(x), 2) > x == eval(bin(x)) > > I don't see how these could work in Py2.6 without > changing the parser and changing the int() function. And it needn't work. Nobody actually ever *uses* eval() on repr() output (well, practically nobody :-). > Why would you ever want to create a string like > '0o144' when there is no way to convert the string > back into a value? > > Having both 0123 and 0o123 in the same version of > language will create a confused mess, IMO. I don't see why. 2.6 already has b'...' as an alias for '...', and 'except E as v' as an alias for 'except E, v'. > We should draw the line on Py3.0 backports whenever > the two different models would be conflated > (i.e. str/unicode vs bytes/text or 0123 vs 0o123). I draw the line differently. Backports are absolutely not allowed to break working code that used to work in 2.5. Apart from that, there is no great harm in 2.6 supporting both the old and the new way. After all we already have lots of places where Python 2.x supports an old and a new way (e.g. string exceptions up to 2.5, classic classes, old and rich comparisons). -- --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] int/float freelists vs pymalloc
On Fri, Feb 22, 2008, Andrew MacIntyre wrote: > Vladimir Marangozov wrote: >> >> And, of course, if the int/float freelist scheme was a real issue >> we would have probably heard of it by now in a very sound way. > > Not much noise has been made here, but I've come across 2 separate > complaints in different mailing lists in the last month (one of the > complainants had some hope that gc.collect() might help...) Is it a > deafening roar? No, but I doubt the volume will do anything but > increase... Actually, it's a regular issue that crops up on c.l.py, but almost always in the context of range(bignum). Because there's an easy workaround and Python 3.0 changes the semantics of range(), there hasn't been much clamor to fix it. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ 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-checkins] r60919 - peps/trunk/pep-0008.txt
On Fri, Feb 22, 2008, [EMAIL PROTECTED] wrote: > > > >> Why not just skip the specifics except to say < 80 characters for all > >> lines? Don't mention 72, 79 or any other number than 80: > > Amaury> I often run "svn diff" in a console limited to 80 characters. > Amaury> Because of the leading "+", lines longer than 78 wrap, and the > Amaury> output is more difficult to read. > > There will always be certain cases which present probems. I use "svn > annotate" from time-to-time which adds an even wider margin to the left. > In those situations I either grin and bear it or stretch my window enough to > view it without wrapping. Yes, but svn/cvs diff is a particularly common use case. I agree with Amaury. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ 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-checkins] r60919 - peps/trunk/pep-0008.txt
On Fri, Feb 22, 2008 at 8:20 AM, Aahz <[EMAIL PROTECTED]> wrote: > On Fri, Feb 22, 2008, [EMAIL PROTECTED] wrote: > > > > > > >> Why not just skip the specifics except to say < 80 characters for > all > > >> lines? Don't mention 72, 79 or any other number than 80: > > > > Amaury> I often run "svn diff" in a console limited to 80 characters. > > Amaury> Because of the leading "+", lines longer than 78 wrap, and the > > Amaury> output is more difficult to read. > > > > There will always be certain cases which present probems. I use "svn > > annotate" from time-to-time which adds an even wider margin to the left. > > In those situations I either grin and bear it or stretch my window enough > to > > view it without wrapping. > > Yes, but svn/cvs diff is a particularly common use case. I agree with > Amaury. -1. There's just no way that 78 is enforceable. At Google, sticking to 80 is a continuous battle, and we use 2-space indents! -- --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] Backporting PEP 3127 to trunk
[GvR] >. After > all we already have lots of places where Python 2.x supports an old > and a new way (e.g. string exceptions up to 2.5, classic classes, old > and rich comparisons). I thought the whole point of 3.0 was a recognition that all that doubling-up was a bad thing and to be rid of it. Why make the situation worse? ISTM that we need two versions of oct() like we need a hole in the head. Heck, there's potentially a case to be made that we don't need oct() at all. IIRC, unix permissions like 0666 were the only use case that surfaced. Also, I thought that the only reason you allowed b'' to be an alias for '' in 2.6 was that it was the only way 2-to-3 converter would work. That same rationale doesn't seem to apply here. I don't really see why the necessity of b'' should be seen as opening the flood gates to backport everything without regard to whether it makes Py2.6 better. Raymond ___ 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] Summary of Tracker Issues
ACTIVITY SUMMARY (02/15/08 - 02/22/08) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1732 open (+27) / 12258 closed (+11) / 13990 total (+38) Open issues with patches: 456 Average duration of open issues: 742 days. Median duration of open issues: 1095 days. Open Issues Breakdown open 1708 (+27) pending24 ( +0) Issues Created Or Reopened (39) ___ libffi needs an update to support mips64, arm and armeabi on lin 02/21/08 http://bugs.python.org/issue1292reopened theller BaseHTTPServer.py fails long POST from IE02/16/08 http://bugs.python.org/issue2126created juneaftn sqlite3 docs should mention utf8 requirement 02/16/08 http://bugs.python.org/issue2127created resolve1 sys.argv is wrong for unicode strings02/16/08 http://bugs.python.org/issue2128created giovannibajo Link error of gethostbyaddr and gethostname in Python Manuals (t 02/16/08 http://bugs.python.org/issue2129created juneaftn [feature-request] Please add bool data type to "optparse" module 02/16/08 http://bugs.python.org/issue2130created Technologov easy "codecs" module on Windows uses incorrect end-of-line, wiriting 02/16/08 CLOSED http://bugs.python.org/issue2131created Technologov Blocking sockets take entirely too long to timeout 02/17/08 http://bugs.python.org/issue2132created khiltd a typo in pydoc.py causes modules to be cyan instead of white02/17/08 CLOSED http://bugs.python.org/issue2133created elliotth function generate_tokens at tokenize.py yields wrong token for c 02/17/08 http://bugs.python.org/issue2134created gpolo patch Restructure import.c into PEP 302 importer objects 02/17/08 http://bugs.python.org/issue2135created dgreiman patch urllib2 basic auth handler doesn't handle realm names in single- 02/18/08 http://bugs.python.org/issue2136created varmaa test_crasher in test_struct uses 8 GB memory on 64 bit systems 02/18/08 CLOSED http://bugs.python.org/issue2137created schmir Factorial02/18/08 http://bugs.python.org/issue2138created dtorp sqlite3 module needs upgrading 02/18/08 CLOSED http://bugs.python.org/issue2139created carloverre calculation bug in long() function 02/18/08 CLOSED http://bugs.python.org/issue2140created must21 Pydoc interactive browser misses some docs 02/18/08 http://bugs.python.org/issue2141created moreilcon naive use of ''.join(difflib.unified_diff(...)) results in bogus 02/18/08 http://bugs.python.org/issue2142created trentm patch smtplib.SSLFakeFile hangs forever if "\n" is not encountered 02/19/08 http://bugs.python.org/issue2143created giampaolo.rodola os.environ should inherit dict
Re: [Python-Dev] Small RFEs and the Bug Tracker
On Fri, Feb 22, 2008 at 4:57 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: ># Feature request resolutions >accepted - feature request accepted (possibly via attached patch) >rejected - feature request rejected Can we make the names a little longer? "feature accepted" and "feature rejected" are more obvious than simply "accepted" and "rejected". Same for some of the bug ones. ># Bug report resolutions >fixed - reported bug fixed (possibly via attached patch) >invalid - reported behaviour is intentional and not a bug >works for me - bug could not be replicated from bug report >out of date - bug is already fixed in later Python version >wont fix - valid bug, but not fixable in CPython (very rare) > ># Common resolutions >duplicate - same as another issue (refer to other issue in a comment) -- Adam Olsen, aka Rhamphoryncus ___ 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] Backporting PEP 3127 to trunk
On Fri, Feb 22, 2008 at 9:06 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [GvR] > > >. After > > all we already have lots of places where Python 2.x supports an old > > and a new way (e.g. string exceptions up to 2.5, classic classes, old > > and rich comparisons). > > I thought the whole point of 3.0 was a recognition that all that > doubling-up was a bad thing and to be rid of it. Why make the > situation worse? ISTM that we need two versions of oct() like > we need a hole in the head. Raymond, I am getting really sick and tired of your strong language like this. It feels like a personal attack to me, over and over. You seem to be the only one advocating 2.6 stay lean and mean (except of course when *you* want something new). I don't want to go over this discussion again. I've drawn the line at breaking code that works under 2.5; you need to be satisfied with that. > Heck, there's potentially a case to be > made that we don't need oct() at all. IIRC, unix permissions like > 0666 were the only use case that surfaced. > > Also, I thought that the only reason you allowed b'' to be an alias for '' > in 2.6 was that it was the only way 2-to-3 converter would work. > That same rationale doesn't seem to apply here. I don't really see > why the necessity of b'' should be seen as opening the flood gates > to backport everything without regard to whether it makes Py2.6 better. Again with the colorful language. Nobody is opening floodgates. Enough said or I start using colorful language myself. -- --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] Backporting PEP 3127 to trunk
Raymond Hettinger wrote: > [GvR] >> . After >> all we already have lots of places where Python 2.x supports an old >> and a new way (e.g. string exceptions up to 2.5, classic classes, old >> and rich comparisons). > > I thought the whole point of 3.0 was a recognition that all that > doubling-up was a bad thing and to be rid of it. Why make the > situation worse? ISTM that we need two versions of oct() like > we need a hole in the head. Heck, there's potentially a case to be > made that we don't need oct() at all. IIRC, unix permissions like > 0666 were the only use case that surfaced. > > Also, I thought that the only reason you allowed b'' to be an alias for '' > in 2.6 was that it was the only way 2-to-3 converter would work. > That same rationale doesn't seem to apply here. I don't really see > why the necessity of b'' should be seen as opening the flood gates > to backport everything without regard to whether it makes Py2.6 better. > It certainly doesn't seem to have the same urgency for cases where 2to3 can unambiguously do the right thing. 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] trunk-math
On 2/16/08, Mark Dickinson <[EMAIL PROTECTED]> wrote: > * New float methods: is_finite, is_inf, is_integer and is_nan. Just a question... is_integer or is_integral? -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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] int/float freelists vs pymalloc
> And, of course, if the int/float freelist scheme was a real issue > we would have probably heard of it by now in a very sound way. As Aahz says: people run into this problem frequently, and then report it. 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] Small RFEs and the Bug Tracker
> We can go one step further: If we change "fixed" and "accepted" as > "resolved" (for example), we can change all the values directly in the > database, so they all appear as "resolved" now. > > I don't want to propose anything specific regarding words, I'm just > saying that having eleven options to close an issue are too many if we > want to keep consistency. I'd like to point out that there is only one way to close an issue: set it to "closed" state. What you (and everybody else) here is talking about the resolution (i.e. an indication how the issue was resolved). If you propose that there is only one possible resolution, namely "resolved", then wouldn't it be best to remove the resolution entirely? > Note that they're not clear enough to make them obvious, otherwise the > consensus in this thread would have been faster, ;) Right. I wish this discussion had taken place before the tracker switchover. 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] Backporting PEP 3127 to trunk
Raymond Hettinger wrote: > I thought the whole point of 3.0 was a recognition that all that > doubling-up was a bad thing and to be rid of it. Why make the > situation worse? ISTM that we need two versions of oct() like > we need a hole in the head. Heck, there's potentially a case to be > made that we don't need oct() at all. IIRC, unix permissions like > 0666 were the only use case that surfaced. Postgres bytea coercion is a frequent use case for oct() in my world. But I agree we don't need two versions. Robert Brewer [EMAIL PROTECTED] ___ 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] Small RFEs and the Bug Tracker
> Can we make the names a little longer? Somebody really needs to take lead here. I won't change anything unless somebody tells me precisely what to do, so I can blame somebody. Messages like this (which I picked just arbitrarily) I will ignore wrt. specific action. Of course I *can* make the names a little longer - it's a thirty-second edit. The question is whether I should. Again, taking your message just arbitrarily. The same remark applies to anything else declared as a proposal - I can only act on specifications, not on proposals. 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] Small RFEs and the Bug Tracker
> First two definitions of "resolve" from the American Heritage dict:
>
> 1. To make a firm decision about.
> 2. To cause (a person) to reach a decision.
>
> I think it applies quite well.
That's why the entire field is called "Resolution". "duplicate",
"invalid", "out of date", "wont fix" and "works for me" are also
firm decisions.
("later", "postponed", and "remind" might not be firm decisions -
they were just inherited from SF).
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
[Python-Dev] boilerplate.tex
This message has been popping up in the buildbot mails for several days: > Conflict detected in commontex/boilerplate.tex. Doc build skipped. I have no idea what it means. I don't see it within the core distribution. Can someone take a look at this? 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] Backporting PEP 3127 to trunk
Robert Brewer wrote: > Raymond Hettinger wrote: >> I thought the whole point of 3.0 was a recognition that all that >> doubling-up was a bad thing and to be rid of it. Why make the >> situation worse? ISTM that we need two versions of oct() like >> we need a hole in the head. Heck, there's potentially a case to be >> made that we don't need oct() at all. IIRC, unix permissions like >> 0666 were the only use case that surfaced. > > Postgres bytea coercion is a frequent use case for oct() in my world. > But I agree we don't need two versions. Unless you're trying to write code to work with both 2.6 and 3.0. ___ 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] boilerplate.tex
[EMAIL PROTECTED] schrieb: > This message has been popping up in the buildbot mails for several days: > > > Conflict detected in commontex/boilerplate.tex. Doc build skipped. > > I have no idea what it means. I don't see it within the core distribution. > Can someone take a look at this? Neal will have to fix it locally in his checkout. The message is generated by his automatic doc building script. 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 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] Backporting PEP 3127 to trunk
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. ___ 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] Backporting PEP 3127 to trunk
Raymond Hettinger wrote: > ISTM that we need two versions of oct() like > we need a hole in the head. I don't know about oct(), but I found hex() to be quite useful the other day when I was using the interactive interpreter to to some hex calculations. It would have been quite tedious having to say "%x".format(_) or some such all the time to see the results in hex. An alternative might be to have some variable that can be set to control the format of numbers printed by the interactive shell. -- Greg ___ 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] ssl - how to switch back to a plain text socket?
I provided a patch for adding TLS support to ftplib: http://bugs.python.org/issue2054 Bill, could you please take a look at it? ___ 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] ssl - how to switch back to a plain text socket?
It's on my list. Bill ___ 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] [ANN] Python 2.5.2 released
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.5.2 (FINAL). This is the second bugfix release of Python 2.5. Python 2.5 is now in bugfix-only mode; no new features are being added. According to the release notes, over 100 bugs and patches have been addressed since Python 2.5.1, many of them improving the stability of the interpreter, and improving its portability. This is a production release of Python, and should be a painless upgrade from 2.5.1 or 2.5. Since the release candidate, we have backed out test cases that were incorrect on 64-bit systems, and fixed another stability problem. See the release notes for more. For more information on Python 2.5.2, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.5.2/ Highlights of this new release include: Bug fixes. According to the release notes, at least 100 have been fixed. Highlights of the previous major Python release (2.5) are available from the Python 2.5 page, at http://www.python.org/2.5/highlights.html Enjoy this release, Martin Martin v. Loewis [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) ___ 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] [ANN] Python 2.5.2 released
> On behalf of the Python development team and the Python community, I'm > happy to announce the release of Python 2.5.2 (FINAL). As a bug day is upcoming, I'm now thawing the 2.5 branch. 2.5.3 should be released in ca. 6 month, or shortly after 2.6 final (whatever happens earlier); if it follows 2.6, it would be the last bugfix release for 2.5 (with security releases still possible). I'm still working on source-only releases of 2.4 and 2.3. 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] Backporting PEP 3127 to trunk
Eric Smith wrote: > Robert Brewer wrote: > > Raymond Hettinger wrote: > >> I thought the whole point of 3.0 was a recognition that all that > >> doubling-up was a bad thing and to be rid of it. Why make the > >> situation worse? ISTM that we need two versions of oct() like > >> we need a hole in the head. Heck, there's potentially a case to be > >> made that we don't need oct() at all. IIRC, unix permissions like > >> 0666 were the only use case that surfaced. > > > > Postgres bytea coercion is a frequent use case for oct() in my world. > > But I agree we don't need two versions. > > Unless you're trying to write code to work with both 2.6 and 3.0. Who would try that when PEP 3000 says (in bold type no less): There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset. ? And why should python-dev support such people? Robert Brewer [EMAIL PROTECTED] ___ 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] Small RFEs and the Bug Tracker
On Fri, Feb 22, 2008 at 10:01 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Can we make the names a little longer? > > Somebody really needs to take lead here. I won't change > anything unless somebody tells me precisely what to do, > so I can blame somebody. Messages like this (which I > picked just arbitrarily) I will ignore wrt. specific > action. Of course I *can* make the names a little > longer - it's a thirty-second edit. The question is > whether I should. > > Again, taking your message just arbitrarily. The same > remark applies to anything else declared as a proposal - > I can only act on specifications, not on proposals. I think Martin is right that someone needs to take the lead and do a complete review of how issues are handled. That way we can do a change in one big batch to something that works better for Python. I have always planned to take the lead on this, but it will have to wait until probably Python 3.0 is out the door. If someone else wants to go through and really look at how we handle issues and propose a new schema that's fine by me. -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] Backporting PEP 3127 to trunk
Greg Ewing <[EMAIL PROTECTED]> writes: > I don't know about oct(), but I found hex() to be quite useful > the other day when I was using the interactive interpreter to > to some hex calculations. It would have been quite tedious > having to say "%x".format(_) or some such all the time to > see the results in hex. > > An alternative might be to have some variable that can be > set to control the format of numbers printed by the interactive > shell. Something like this? >>> import sys >>> import __builtin__ >>> def myhook(o): ... if isinstance(o, int): ... print hex(o) ... else: ... print repr(o) ... __builtin__._ = o ... >>> sys.displayhook = myhook >>> 123 0x7b Bernhard ___ 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] Small RFEs and the Bug Tracker
On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote: > I think Martin is right that someone needs to take the lead and do a > complete review of how issues are handled. That way we can do a change > in one big batch to something that works better for Python. Are we, as a development community, really running into problems with how we handle bugs? There are certainly small cleanups possible, such as dropping the 'postponed' and 'later' resolutions that we don't seem to use very much, but the flow seems reasonably efficient to me. I suggest just updating PEP 3 to actually describe the life cycle we currently follow. --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] Small RFEs and the Bug Tracker
On Fri, Feb 22, 2008 at 1:21 PM, Facundo Batista <[EMAIL PROTECTED]> wrote: > 2008/2/22, Brett Cannon <[EMAIL PROTECTED]>: > > > > I think Martin is right that someone needs to take the lead and do a > > complete review of how issues are handled. That way we can do a change > > in one big batch to something that works better for Python. > > +1 > > What about a couple of hours in the Python Core sprinting in a month? > I won't be there (in that specific sprint), but I trust your decision. Maybe. Could possibly take an hour or so after a lunch and just have everyone at the sprint give feedback or something. But my personal priorities for the sprint is being a good sprint coach first, and finish getting my bootstrap of my import rewrite second. -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] Small RFEs and the Bug Tracker
On Fri, Feb 22, 2008 at 1:28 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote: > > I think Martin is right that someone needs to take the lead and do a > > complete review of how issues are handled. That way we can do a change > > in one big batch to something that works better for Python. > > Are we, as a development community, really running into problems with > how we handle bugs? There are certainly small cleanups possible, such > as dropping the 'postponed' and 'later' resolutions that we don't seem > to use very much, but the flow seems reasonably efficient to me. > It's reasonable, but I wonder if it could be better. I am not sure as I have not had that much time to sit down and really think it through. I do know, though, that I like how Django has it structured: http://www.djangoproject.com/documentation/contributing/#ticket-triage . -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] Backporting PEP 3127 to trunk
Robert Brewer wrote: > Eric Smith wrote: >> Robert Brewer wrote: >>> Postgres bytea coercion is a frequent use case for oct() in my > world. >>> But I agree we don't need two versions. >> Unless you're trying to write code to work with both 2.6 and 3.0. > > Who would try that when PEP 3000 says (in bold type no less): > > There is no requirement that Python 2.6 code will run unmodified > on Python 3.0. Not even a subset. > > ? Yes, but it also describes the "recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously". That is to run 2to3 on 2.6 code (which is -3 clean), and not edit the resulting code. I'm trying to enable that for code which wants to use some (small) 3.0 features. I don't see the harm in that. I think this means that the existing oct and hex builtins should raise a -3 warning. The future_builtins version would not raise a warning. 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/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
2008/2/22, Brett Cannon <[EMAIL PROTECTED]>: > I think Martin is right that someone needs to take the lead and do a > complete review of how issues are handled. That way we can do a change > in one big batch to something that works better for Python. +1 What about a couple of hours in the Python Core sprinting in a month? I won't be there (in that specific sprint), but I trust your decision. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Unicode <--> UTF-8 in CPython extension modules
I've uncovered what seems to me to a problem with python Unicode string objects passed to extension modules. Or perhaps it's revealing a misunderstanding on my part :-) So I would like to get some clarification. Extension modules written in C receive strings from python via the PyArg_ParseTuple family. Most extension modules use the 's' or 's#' format parameter. Many C libraries in Linux use the UTF-8 encoding. The 's' format when passed a Unicode object will encode the string according to the default encoding which is immutably set to 'ascii' in site.py. Thus a C library expecting UTF-8 which uses the 's' format in PyArg_ParseTuple will get an encoding error when passed a Unicode string which contains any code points outside the ascii range. Now my questions: * Is the use of the 's' or 's*' format parameter in an extension binding expecting UTF-8 fundamentally broken and not expected to work? Instead should the binding be using a format conversion which specifies the desired encoding, e.g. 'es' or 'es#'? * The extension modules could successfully use the 's' or 's#' format conversion in a UTF-8 environment if the default encoding was UTF-8. Changing the default encoding to UTF-8 would in one easy stroke "fix" most extension modules, right? Why is the default encoding 'ascii' in UTF-8 environments and why is the default encoding prohibited from being changed from ascii? * Did Python 2.5 introduce anything which now makes this issue visible whereas before it was masked by some other behavior? Summary: Python programs which use Unicode string objects for their i18n and which "link" to C libraries expecting UTF-8 but which have a CPython binding which only uses 's' or 's#' formats programs seem to often fail with encoding errors. However, I have yet to see a CPython binding which does explicitly define it's encoding requirements. This suggests to me I either do not understand the issue in it's entirety or many CPython bindings in Linux UTF-8 environments are broken with respect to their i18n handling and the problem is currently not addressed. -- John Dennis <[EMAIL PROTECTED]> ___ 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] Small RFEs and the Bug Tracker
"Martin v. Löwis" writes:
> That's why the entire field is called "Resolution". "duplicate",
> "invalid", "out of date", "wont fix" and "works for me" are also
> firm decisions.
>
> ("later", "postponed", and "remind" might not be firm decisions -
> they were just inherited from SF).
These latter three are not resolutions, and IMO should be removed.
Items with those "resolutions" should be considered still active (or
perhaps "pending" auto-closure).
Specifically, the "name" field of the corresponding items in the
relevant class should be edited so that in legacy issues containing
them they are displayed as "- not yet resolved -" or "- no selection -".
(I'm not sure it's wise, or even possible, for multiple items to have
identical names, though. If not, they can be uniquified in some way.)
Then these items should be retired so that they won't appear at all in
menus.
___
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] boilerplate.tex
On Fri, Feb 22, 2008 at 11:15 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] schrieb: > > > This message has been popping up in the buildbot mails for several days: > > > > > Conflict detected in commontex/boilerplate.tex. Doc build skipped. > > > > I have no idea what it means. I don't see it within the core distribution. > > Can someone take a look at this? > > Neal will have to fix it locally in his checkout. The message is generated by > his automatic doc building script. Yeah, I fixed it. I have an outstanding change that is set to today so the docs show the correct date. But when I release is made, a conflict arises, so I have to fix manually each time the file is modified. 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] Unicode <--> UTF-8 in CPython extension modules
> I've uncovered what seems to me to a problem with python Unicode > string objects passed to extension modules. Or perhaps it's revealing > a misunderstanding on my part :-) So I would like to get some > clarification. It seems to me that there is indeed one or more misunderstandings on your part. Please discuss them on comp.lang.python. > Extension modules written in C receive strings from python via the > PyArg_ParseTuple family. Most extension modules use the 's' or 's#' > format parameter. > > Many C libraries in Linux use the UTF-8 encoding. > > The 's' format when passed a Unicode object will encode the string > according to the default encoding which is immutably set to 'ascii' in > site.py. Thus a C library expecting UTF-8 which uses the 's' format in > PyArg_ParseTuple will get an encoding error when passed a Unicode > string which contains any code points outside the ascii range. The C library isn't expecting using the 's' format. A Python module wrapping the C library is. So whatever conversion is necessary should be done by that Python module. > Now my questions: > > * Is the use of the 's' or 's*' format parameter in an extension >binding expecting UTF-8 fundamentally broken and not expected to >work? Instead should the binding be using a format conversion which >specifies the desired encoding, e.g. 'es' or 'es#'? Yes. Alternatively, require the callers to pass UTF-8 byte strings, not Unicode strings. > * The extension modules could successfully use the 's' or 's#' format >conversion in a UTF-8 environment if the default encoding was >UTF-8. Changing the default encoding to UTF-8 would in one easy >stroke "fix" most extension modules, right? Wrong. This assumes that "most" libraries do indeed specify their APIs in terms of UTF-8. I don't think that is a fact; not in the world of 2008. > Why is the default >encoding 'ascii' in UTF-8 environments and why is the default >encoding prohibited from being changed from ascii? There are several reasons, all off-topic for python-dev. ASCII was considered the most safe assumption: when converting between byte and Unicode strings in the absence of an encoding specification, you can't assume anything but ASCII (technically, not even that, as the bytes may be EBCDIC, but ASCII is safe for the majority of the systems - unlike UTF-8). The encoding can't be changed because that would break hash(). > * Did Python 2.5 introduce anything which now makes this issue visible >whereas before it was masked by some other behavior? I don't know. Can you please be a bit more specific (on comp.lang.python) where you suspect such a change? 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
[Python-Dev] Python 2.6 and 3.0
-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-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] Unicode <--> UTF-8 in CPython extension modules
On Fri, Feb 22, 2008 at 4:23 PM, John Dennis <[EMAIL PROTECTED]> wrote: > Python programs which use Unicode string objects for their i18n and > which "link" to C libraries expecting UTF-8 but which have a CPython > binding which only uses 's' or 's#' formats programs seem to often > fail with encoding errors. One thing to be aware of is that PyGTK+ actually sets the Python Unicode object encoding to UTF-8. http://bugzilla.gnome.org/show_bug.cgi?id=132040 I mention this because PyGTK is a very popular library related to Python and Linux. So currently if you "import gtk", then libraries which are using UTF-8 (as you say, the vast majority) will work with Python unicode objects unmodified. ___ 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-checkins] r60919 - peps/trunk/pep-0008.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 22, 2008, at 11:28 AM, Guido van Rossum wrote: > On Fri, Feb 22, 2008 at 8:20 AM, Aahz <[EMAIL PROTECTED]> wrote: >> On Fri, Feb 22, 2008, [EMAIL PROTECTED] wrote: >>> >>> > Why not just skip the specifics except to say < 80 characters > for all > lines? Don't mention 72, 79 or any other number than 80: >>> >>>Amaury> I often run "svn diff" in a console limited to 80 >>> characters. >>>Amaury> Because of the leading "+", lines longer than 78 wrap, >>> and the >>>Amaury> output is more difficult to read. >>> >>> There will always be certain cases which present probems. I use >>> "svn >>> annotate" from time-to-time which adds an even wider margin to the >>> left. >>> In those situations I either grin and bear it or stretch my window >>> enough to >>> view it without wrapping. >> >> Yes, but svn/cvs diff is a particularly common use case. I agree >> with >> Amaury. > > -1. There's just no way that 78 is enforceable. At Google, sticking to > 80 is a continuous battle, and we use 2-space indents! At my last job, I had a hard enough time getting people to stick with / any/ limit! I even saw lines > 120 characters! Fortunately, we made a workable compromise; the C code could be whatever and the Python code had to be PEP 8. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR79fB3EjvBPtnXfVAQLBNAP7BD1FG5bOjkP0iys2r6f6nK98D9XZhK3J Qm+Cjm6tmnqEv92R9rEVYOIH0KE21oGhJFliOccYZzuE0WFPk9T6KXrRIAmggBrf ZtAwcj//0dfkq/7XGWwKgx9B7BoCymyyKGo16svj/jGeBQM6dLSoKUP+Fbw6zJEF n04bAwAqFp0= =3kW3 -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-checkins] r60919 - peps/trunk/pep-0008.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 22, 2008, at 11:20 AM, Aahz wrote: > On Fri, Feb 22, 2008, [EMAIL PROTECTED] wrote: >> >> Why not just skip the specifics except to say < 80 characters for all lines? Don't mention 72, 79 or any other number than 80: >> >>Amaury> I often run "svn diff" in a console limited to 80 >> characters. >>Amaury> Because of the leading "+", lines longer than 78 wrap, >> and the >>Amaury> output is more difficult to read. >> >> There will always be certain cases which present probems. I use "svn >> annotate" from time-to-time which adds an even wider margin to the >> left. >> In those situations I either grin and bear it or stretch my window >> enough to >> view it without wrapping. > > Yes, but svn/cvs diff is a particularly common use case. I agree with > Amaury. My main concern is that we have only one line length limit for everything. If we want that to be 78 or 72 or whatever, okay (though I still think 79 works well :) but I don't see much point in there being more than one limit. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR79g/HEjvBPtnXfVAQJCCQP/Qd7nWrSC3Wm6Y4+dPgv0ls1Td3ZTuf7n ZzE6cIiV0h2tgKsS+olRHE2e/ttKNVRask2FPrhUClj4eXG6k3bVU/KsH9JR4wjH Ha1ayDb74ZHqqdSZKrKCcsak5fismBv2Vsn8aDI3eslzFVEd0FF1dU+qQYf/m3je 2gjt9Fx6wYU= =6WAr -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] Unicode <--> UTF-8 in CPython extension modules
On 2008-02-23 00:46, Colin Walters wrote: > On Fri, Feb 22, 2008 at 4:23 PM, John Dennis <[EMAIL PROTECTED]> wrote: > >> Python programs which use Unicode string objects for their i18n and >> which "link" to C libraries expecting UTF-8 but which have a CPython >> binding which only uses 's' or 's#' formats programs seem to often >> fail with encoding errors. > > One thing to be aware of is that PyGTK+ actually sets the Python > Unicode object encoding to UTF-8. > > http://bugzilla.gnome.org/show_bug.cgi?id=132040 > > I mention this because PyGTK is a very popular library related to > Python and Linux. So currently if you "import gtk", then libraries > which are using UTF-8 (as you say, the vast majority) will work with > Python unicode objects unmodified. Are you suggesting that John should rely on a bug in some 3rd party extension instead of fixing the Python extension to use "es#" where needed ? There's a good reason why we don't allow setting the default encoding outside site.py. Trying to play tricks to change the default encoding later on will only cause problems, e.g. the cached default encoded versions of Unicode objects will then use different encodings - the one set in site.py and later the ones with the new encoding. As a result, all kind of weird things can happen. Using the Python Unicode C API really isn't all that hard and it's well documented too, so please use it instead of trying to design software based on workarounds. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 23 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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-checkins] r60919 - peps/trunk/pep-0008.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 21, 2008, at 12:30 PM, Guido van Rossum wrote: > On Thu, Feb 21, 2008 at 9:15 AM, Barry Warsaw <[EMAIL PROTECTED]> > wrote: >> Why should docstrings and comments be limited to 72 characters when >> code is limited to 79 characters? I ask because there is an ongoing >> debate at my company about this. > > People in your company have too much time on their hands. :-) C'mon, bike shedding is so much fun! :) >> Personally, I see no justification for it, and further, it's a pita >> to >> support automatically because tools like Emacs only have one auto- >> wrapping variable (fill-column). Emacs doesn't know that it should >> fill comments and docstrings different than code lines, so you have >> to >> do a bunch of manual crud to support these guidelines. >> >> I recommend removing the guideline of 72 characters, and just say >> everything, code, comments, and docstrings should be no wider than 79 >> characters. > > I'm fine with getting rid of this, but since that originally comes > from me, here's my justification. Somehow my Emacs usually defaults to > 72 for its fill column. That means that when I reflow text in a block > comment or docstring, it'll use this limit. OTOH I don't use anything > to automatically fold long code lines: when they start wrapping I > manually decide on the best place to break it (and my windows are > typically 80 chars wide so I can have several side by side(*)). I do the same thing sometimes too. > However there are occasions where I manually format docstrings or > comments, and then I will again use 79 as the limit. Yep. > (*) When is Emacs going to fix the bug where it decides to fold a line > that's exactly as wide as the window? This 79 business is really > silly, and had to impose on people using other editors. 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. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR79gjHEjvBPtnXfVAQLn/AQApsNQ7KvoBM6wJgKUDHkS97Sd0qTYeRCy qjFQE/hUtAGebqic3fcAEP3ASPp12fOnBpOWOxm0aQURoDdTi+ClTsXp6v/1aztf 9yC1xT3BH022Te82d3vLgRhixxregHZ+5i8ravb3Tb/xdUa3gouql+DyJw8tEAek MGMdcrqoEfE= =FiB+ -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
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 :). Can the PSF buy you more of the meds? =) > 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. > 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? -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] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 21, 2008, at 12:33 PM, Ron Adam wrote: > Barry Warsaw wrote: > >> Why should docstrings and comments be limited to 72 characters when >> code is limited to 79 characters? I ask because there is an ongoing >> debate at my company about this. > > I'm not sure if this is the main reason, but when using pydoc to view > docstrings, the 72 character width allows for the added indent in > class and > method sections. Interesting. Maybe because I almost always put doctests in separate files, I don't run into this too much. Having an indent of 4 for doctest code never really bothers me too much. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR79fdnEjvBPtnXfVAQKL0gP8DiLPO6bQEIwvcg9M7ke9Dl8QYMf3+KSV TY7o20ogh54mnm66YElJ3HFU1iomOx6CsP0gNJ2mioKCJj3iBAdGKmPb0KhJKiDa bLZc0y2Pmzw//ePspkIGZrEjDm8vps5A/iRGF58tnMdYg6f/OzfJPAmGNo6rzOl8 pI27IxE4XX4= =Xe/I -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 2.6 and 3.0
[Barry] > I'd also like for us to consider doing regular monthly releases. +1 ___ 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] Unicode <--> UTF-8 in CPython extension modules
Colin Walters wrote: > On Fri, Feb 22, 2008 at 4:23 PM, John Dennis <[EMAIL PROTECTED]> wrote: > >> Python programs which use Unicode string objects for their i18n and >> which "link" to C libraries expecting UTF-8 but which have a CPython >> binding which only uses 's' or 's#' formats programs seem to often >> fail with encoding errors. > > One thing to be aware of is that PyGTK+ actually sets the Python > Unicode object encoding to UTF-8. > > http://bugzilla.gnome.org/show_bug.cgi?id=132040 > > I mention this because PyGTK is a very popular library related to > Python and Linux. So currently if you "import gtk", then libraries > which are using UTF-8 (as you say, the vast majority) will work with > Python unicode objects unmodified. Thank you Colin, your input was very helpful. The fact PyGTK's i18n handling worked was the counter example which made me doubt my analysis was correct but I can see from the Gnome bug report and Martin's subsequent comment that the analysis was sound. It had perplexed me enormously why in some circumstances i18n handling worked but failed in others. Apparently it was a side effect of importing gtk, a problem exacerbated when either the sequence of imports or the complete set of imports was not taken into account. I am aware of other python bindings (libxml2 is one example) which share the same mistake of not using the 'es' family of format conversions when the underlying library is UTF-8. At least I now understand why incorrectly coded bindings in some circumstances produced correct results when logic dictated they shouldn't. -- John Dennis <[EMAIL PROTECTED]> ___ 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] Small RFEs and the Bug Tracker
A.M. Kuchling wrote: > Are we, as a development community, really running into problems with > how we handle bugs? There are certainly small cleanups possible, such > as dropping the 'postponed' and 'later' resolutions that we don't seem > to use very much, but the flow seems reasonably efficient to me. 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. 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] Small RFEs and the Bug Tracker
On Fri, Feb 22, 2008 at 4:55 PM, 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. I don't think so. I think it's a sign of healthy software. Now, if there were 1700 *serious* bugs, we'd have a problem. :-) -- --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-checkins] r60919 - peps/trunk/pep-0008.txt
Barry Warsaw wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Feb 21, 2008, at 12:33 PM, Ron Adam wrote: > >> Barry Warsaw wrote: >> >>> Why should docstrings and comments be limited to 72 characters when >>> code is limited to 79 characters? I ask because there is an ongoing >>> debate at my company about this. >> I'm not sure if this is the main reason, but when using pydoc to view >> docstrings, the 72 character width allows for the added indent in >> class and >> method sections. > > Interesting. Maybe because I almost always put doctests in separate > files, I don't run into this too much. Having an indent of 4 for > doctest code never really bothers me too much. I think the 72 character limit refers to the length of the doc string, not the length of the line. Pydoc, ie...the help() function, strips leading white space off and then adds it's own margin, 4 characters for function doc strings, and 8 characters with a vertical bar for class method doc strings. Longer than 72 character doc strings in class methods wrap and break up the output of the help function. Ron ___ 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] Small RFEs and the Bug Tracker
On Sat, Feb 23, 2008 at 01:55:06AM +0100, Christian Heimes 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. Sure, but is that because the bug life cycle is sub-optimal, or because we don't have enough people handling bugs? I think for a long time we haven't been actively recruiting new developers, and the pool of people with commit privileges remained about the same. Some committers go away, and some get caught up in other projects, so the number of people who actually do work is much smaller. I think that's the primary problem to solve, and the bug life cycle is much less significant. I'm not against changing the bug cycle, just doubtful that changing it will be a magic bullet for reducing the size of our backlog. --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
[Python-Dev] Please sign up for the PyCon sprint if you are attending!
With the PyCon sprint approaching I would like all attendees to be signed up on the wiki page for the sprint: http://wiki.python.org/moin/PyCon2008/SprintSignups/Python . I am going to be using that list to send out an email about what is exactly expected of people in terms of setup ahead of time, etc. And even if you do know what you are doing, I still would appreciate people adding themselves so I can have a head count. That will let the sprint coordinators make sure we have a space big enough for us. -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
[Python-Dev] Proposed revision of PEP 3 (using the issue tracker)
I've attached a proposed revision of PEP 3 below. Feedback would be appreciated, and once we have a reasonable consensus that it accurately describes our current processes I can check it in and Martin can update the tracker to reflect any changes. It is intentional that the current non-resolution resolutions like 'later' are missing - I think those should definitely be retired. I also left out the 'compile error' type - I would prefer to see the Compiler added to the Components list so we can attach feature requests to it as well as bugs. One question I did have is whether or not access to 'security' type issues is automatically limited to a small subset of the developers. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org PEP: 3 Title: Guidelines for Handling Tracker Issues Version: $Revision: 59412 $ Last-Modified: $Date: 2007-12-08 20:48:07 +1000 (Sat, 08 Dec 2007) $ Author: [EMAIL PROTECTED] (Jeremy Hylton), [EMAIL PROTECTED] (Nick Coghlan) Status: Active Type: Process Content-Type: text/x-rst Created: 25-Sep-2000 Post-History: 23-Feb-2008 Introduction This PEP contains guidelines for handling bug reports and feature requests for the Python project using the tracker at bugs.python.org [1]. These are guidelines for the developers of Python, not the submitters of bugs. Those are included as part of the documentation so they are available in the offline documentation as well as being available online [2]. Tracker Issues == All bug reports and feature requests are handled as issues in the tracker. Whether they are bugs or requests for new features is indicated by the type of issue. Title - This should be a short description of the problem or request. It is worth correcting it if the originator's title turns out to be misleading. Type This attribute describes the kind of issue being reported. It should be adjusted if the originator has not set it correctly. The possible issue types are: *feature request* the issue is not a bug, but a request for additional functionality *behavior* this covers most bugs (including all documentation bugs), where the behaviour is not desirable or not what the user expected *crash* a bug that causes the Python interpreter to crash (segfault/access violation/bus error) *resource usage* a bug that causes Python to handle limited resources (memory, file handles, etc) poorly *security* a bug that may allow the Python interpreter to be used to gain unauthorised access to information in memory or on the file system (either locally or remotely) (XXX: is public access to security bugs limited by default?) Severity This attribute allows the originator to indicate how important the issue is to them. It should not be adjusted (set the Priority instead). Components -- The originator and developers can use the components list to indicate which areas of Python or its development tools are affected by the issue. Eventually developers will be able to subscribe to the tracker so that it automatically adds them to the nosy list when issues are registered against components they are interested in. For discrepancies between the documentation and the actual behavior, the components list should be updated if the problem is determined to be an error in the documentation (and vice-versa if the issue was originally reported as a documentation problem, but it is later determined that the documentation accurately describes the desired behavior). Versions This field is primarily of importance for bug reports - it should indicate which versions of Python exhibit the problem. Problems which are seen in a development version should also be flagged appropriately (currently Python 2.6 for the trunk and Python 3.0 for the py3k branch). For feature requests this field is used to flag the target version for the feature (following a major version release, all open features should be bumped to target the next version). Status -- Open issues are still under consideration. Closed issues have been resolved, and the resolution field should indicate their final disposition. Pending issues are intended to be closed soon, but are being held open for a short period to allow time for some other event (e.g. additional details from the originator or a decision on whether or not a fix should be backported to the current maintenance branch). Resolution -- For closed and pending issues, indicates how the issue was (or will be) resolved. This field should not be set for open issues. In all cases, a comment should be added when closing the issue to provide additional detail as to the rationale behind the resolution. *accepted* the feature request has been implemented for the next version *rejected* the feature request was either not described clearly enoug
Re: [Python-Dev] Proposed revision of PEP 3 (using the issue tracker)
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | *invalid* | the reported bug was either not described clearly enough to be reproduced, | or is actually the intended behaviour | | *works for me* | the reported bug could not be replicated by the developers This strikes me as a near duuplicate of 'invalid'. Do we really need this? | *out of date* | the reported bug applies only to versions of Python which are no longer | supported, or the bug has already been fixed in all versions where it is | possible to fix it (some fixes require new features and hence cannot be | backported to maintenance branches) This is another form of 'invalid' though more different than 'works for me'. But does anyone really care other than this being a holdover from SF? It seems to me that 'fixed', 'invalid', and 'duplicate' (of valid report) seem a good enough resolution of closed bug reports. Thanks for a definite proposal that we can discuss and pass on to Martin. tjr ___ 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] Small RFEs and the Bug Tracker
> 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. As a historical record: people said the same thing when there were 500 and 1000 open issues. 5 years from now, when we have 5000 open issues, you will look back to the good old days when we were below 2000 :-) 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] Proposed revision of PEP 3 (using the issue tracker)
> One question I did have is whether or not access to 'security' type > issues is automatically limited to a small subset of the developers. No. Reports requiring privacy should be sent to [EMAIL PROTECTED] 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] Proposed revision of PEP 3 (using the issue tracker)
Terry Reedy wrote: > "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | *invalid* > | the reported bug was either not described clearly enough to be > reproduced, > | or is actually the intended behaviour > | > | *works for me* > | the reported bug could not be replicated by the developers > > This strikes me as a near duuplicate of 'invalid'. Do we really need this? In the past, "invalid" was used when the behavior reported could be reproduced, and was the intended behavior. "works for me" was used when the steps to reproduce it were clearly spelled out - just the outcome was different from what the reporter claimed it to be. Possible causes could be platform differences, or that the bug had been fixed meanwhile; in either case, the original report might have been valid. > | *out of date* > | the reported bug applies only to versions of Python which are no longer > | supported, or the bug has already been fixed in all versions where it is > | possible to fix it (some fixes require new features and hence cannot be > | backported to maintenance branches) > > This is another form of 'invalid' though more different than 'works for > me'. But does anyone really care other than this being a holdover from SF? 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. 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
