Re: [Python-Dev] Summary of Tracker Issues
O.R.Senthil Kumaran writes: > :-) My idea was, a human got to answer it unscrambled as 'fourth' as he > "understands" what the question is and gives the proper answer. > Agreed, there could be confusion at first. But for any given user, there's only going to be a first. Either they pass the test the first time and after that authenticate via personal password, or they say WTF!! In that case we could lose all the bug reports they were ever going to write. If we're going to do CAPTCHA, what we're looking for is something that any 4 year old does automatically, but machines can't do at all. Visual recognition used to be one, but isn't any more. The CAPTCHA literature claims that segmentation still is (dividing complex images into letters), but that's nontrivial for humans, too, and I think that machines will eventually catch up. (Ie, within a handful of months.) I think it would be better to do content. URLs come to mind; without something clickable, most commercial spam would be hamstrung. But few bug reports and patches need to contain URLs, except for specialized local ones pointing to related issues. For example, how about requiring user interaction to display any post containing an URL, until an admin approves it? Or you could provide a preview containing the first two non-empty lines not containing an URL. This *would* be inconvenient for large attachments and other data where the reporter prefers to provide an URL rather than the literal data, but OTOH only people who indicate they really want to see spam would see 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
[Python-Dev] Need Survey Answers from Core Developers
Time is short and I'm still looking for answers to some questions about cPython, so that it makes a good showing in the Forrester survey. 1) How is the project governed? How does the community make decisions on what goes into a release? You know, I've been a member of the Python community for many years -- I know about PEPs, Guido as BDFL, and +1/-1. But I've never figured out exactly how -final- decisions are made on what goes into a release. I've never needed to, until now. Can someone explain in one paragraph? 2) Does the language have a formal defined release plan? I know Zope 3's release plan, every six months, but not that of Python. Is there a requirement to push a release out the door every N months, as some projects do, or is each release separately negotiated with developers around a planned set of features? 3) Some crude idea of how many new major and minor features were added in the last release? Yes, I know this is difficult -- the idea it so get some measure of the evolution/stability of cPython re features. Jython and IronPython are probably changing rapidly -- cPython, not such much. 4) How many committers to the cPython core are there? I don't have the necessary access to the pydotorg infrastructure to answer this -- can someone who does help me out here? Thanks for any one-line answers you can dash off to me today. Jeff Rush Python Advocacy Coordinator ___ 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] Need Survey Answers from Core Developers
On Fri, May 18, 2007 at 10:23:46AM -0500, Jeff Rush wrote: > Time is short and I'm still looking for answers to some questions about > cPython, so that it makes a good showing in the Forrester survey. > [snip] > > 4) How many committers to the cPython core are there? > >I don't have the necessary access to the pydotorg infrastructure >to answer this -- can someone who does help me out here? http://www.python.org/dev/committers If the last modified date can be trusted there are currently 77 committers. ___ 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] Wither PEP 335 (Overloadable Boolean Operators)?
While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean Operators) by Greg Ewing. I am of two minds of this -- on the one hand, it's been a long time without any working code or anything. OTOH it might be quite useful to e.g. numpy folks. It is time to reject it due to lack of interest, or revive it! -- --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
[Python-Dev] Mass PEP status changes
With the help of Neal Norwitz, Jeremy Hylton, Alex Martelli and Collin Winter, I've greatly reduced the set of open PEPs numbered less than 3000. Here's a summary. Please speak up if we've made a grave error; I take all responsibility for the final decisions. Positive Decisions (Marked Accepted or Final) - SF 237 Unifying Long Integers and Integers Zadka, GvR Marked as Final; there's no work left to be done. I 287 reStructuredText Docstring FormatGoodger Status changed from Draft to Active. SA 302 New Import Hooks JvR, Moore Marked Accepted. Should this be marked Final, or is there still an unimplemented part? SF 331 Locale-Independent Float/String Conversions Reis Marked Final; this was done years ago (Python 2.3?). Negative Decisions (Rejected, Withdrawn or Deferred) SW 228 Reworking Python's Numeric Model Zadka, GvR Withdrawn in favor of PEP 3141 (numeric ABCs). SR 256 Docstring Processing System FrameworkGoodger Rejected; seems to have run out of steam. SR 258 Docutils Design SpecificationGoodger Rejected; docutils is no longer slated for stdlib inclusion. SD 267 Optimized Access to Module NamespacesHylton Deferred; no-one has had time for this. SR 268 Extended HTTP functionality and WebDAV Stein Rejected for lack of interest or progress. SD 280 Optimizing access to globals GvR Deferred; no-one has had time for this. SW 296 Adding a bytes Object Type Gilbert Was withdrawn long ago in favor of PEP 358 (the bytes object). SR 297 Support for System Upgrades Lemburg Rejected; failed to generate support. SD 323 Copyable Iterators Martelli Deferred due to lack of interest. IR 350 Codetags Elliott Rejected for lack of will to standardize. XXX lives! SR 354 Enumerations in Python Finney Rejected; not enough interest, not sufficiently Pythonic. SR 355 Path - Object oriented filesystem paths Lindqvist Rejected as being the ultimate kitchen sink. SR 754 IEEE 754 Floating Point Special Values Warnes Rejected for lack of progress. -- --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] [PEPs] Mass PEP status changes
On 5/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: With the help of Neal Norwitz, Jeremy Hylton, Alex Martelli and Collin Winter, I've greatly reduced the set of open PEPs numbered less than 3000. Here's a summary. Please speak up if we've made a grave error; I take all responsibility for the final decisions. Positive Decisions (Marked Accepted or Final) - SF 237 Unifying Long Integers and Integers Zadka, GvR Marked as Final; there's no work left to be done. I 287 reStructuredText Docstring FormatGoodger Status changed from Draft to Active. SA 302 New Import Hooks JvR, Moore Marked Accepted. Should this be marked Final, or is there still an unimplemented part? Everything added by this PEP is not covered in the official docs. Otherwise the PEP is implemented. There is mention of a possible "part 2" where the built-in import gets refactored to use what this PEP introduces, but that can be a separate PEP for possible changes to import itself. -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] [PEPs] Mass PEP status changes
On 5/18/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > > > On 5/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > With the help of Neal Norwitz, Jeremy Hylton, Alex Martelli and Collin > > Winter, I've greatly reduced the set of open PEPs numbered less than > > 3000. Here's a summary. Please speak up if we've made a grave error; I > > take all responsibility for the final decisions. > > > > Positive Decisions (Marked Accepted or Final) > > - > > > > SF 237 Unifying Long Integers and Integers Zadka, GvR > > Marked as Final; there's no work left to be done. > > > > I 287 reStructuredText Docstring FormatGoodger > > Status changed from Draft to Active. > > > > SA 302 New Import Hooks > JvR, Moore > > Marked Accepted. Should this be marked Final, or is there still an > > unimplemented part? > > Everything added by this PEP is not covered in the official docs. Otherwise > the PEP is implemented. OK, I'll mark it final then. Docs are really not the PEP's business. > There is mention of a possible "part 2" where the built-in import gets > refactored to use what this PEP introduces, but that can be a separate PEP > for possible changes to import itself. Yes, please. -- --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] Need Survey Answers from Core Developers
On 5/18/07, Jeff Rush <[EMAIL PROTECTED]> wrote: Time is short and I'm still looking for answers to some questions about cPython, so that it makes a good showing in the Forrester survey. 1) How is the project governed? How does the community make decisions on what goes into a release? You know, I've been a member of the Python community for many years -- I know about PEPs, Guido as BDFL, and +1/-1. But I've never figured out exactly how -final- decisions are made on what goes into a release. I've never needed to, until now. Can someone explain in one paragraph? Concensus is reached on python-dev or Guido says so. =) Honestly someone proposes an idea to python-dev. It gets discussed. Either a concensus is reached and the person goes ahead and moves forward with it, or Guido explicitly says OK. Occasionally there is a minor revolt and Guido backs down, but usually that leads to the wrong decision winning out. =) How much extra work is needed to present to python-dev depends on the level of the change. PEP is needed for language changes. New additions to the stdlib require community concensus that it is best-of-breed. Small additions usually should get python-dev approval. Patches for fixes just happen. More details are in http://www.python.org/dev/intro . 2) Does the language have a formal defined release plan? I know Zope 3's release plan, every six months, but not that of Python. Is there a requirement to push a release out the door every N months, as some projects do, or is each release separately negotiated with developers around a planned set of features? Latter. We aim for every 12 - 18 months, but it depends on if there are any specific features we want in a release. 3) Some crude idea of how many new major and minor features were added in the last release? Yes, I know this is difficult -- the idea it so get some measure of the evolution/stability of cPython re features. Jython and IronPython are probably changing rapidly -- cPython, not such much. Going by http://www.python.org/download/releases/2.5/highlights/ , roughly 8 or so major features. Don't know what to say about minor since I don't know how you want to count stdlib additions. 4) How many committers to the cPython core are there? I don't have the necessary access to the pydotorg infrastructure to answer this -- can someone who does help me out here? According to http://www.ohloh.net/projects/26/analyses/latest/contributors , 92 people over the life of the project, but 51 over the last year. -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] Need Survey Answers from Core Developers
Jeff> 1) How is the project governed? How does the community make Jeff>decisions on what goes into a release? Jeff>You know, I've been a member of the Python community for many Jeff>years -- I know about PEPs, Guido as BDFL, and +1/-1. But I've Jeff>never figured out exactly how -final- decisions are made on Jeff>what goes into a release. I've never needed to, until now. Jeff>Can someone explain in one paragraph? Consensus (most of the time) and GvR pronouncements for significant changes. There are situations where Guido has simply pronounced when the community seemed unable to settle on one solution. Decorators come to mind. Jeff> 2) Does the language have a formal defined release plan? Jeff>I know Zope 3's release plan, every six months, but not that of Jeff>Python. Is there a requirement to push a release out the door Jeff>every N months, as some projects do, or is each release Jeff>separately negotiated with developers around a planned set Jeff>of features? PEP 6? PEP 101? PEP 102? There is no hard-and-fast time schedule. I believe minor releases leave the station approximately every 18-24 months, micro releases roughly every six months. Jeff> 3) Some crude idea of how many new major and minor features were Jeff>added in the last release? Yes, I know this is difficult -- the Jeff>idea it so get some measure of the evolution/stability of cPython Jeff>re features. Jython and IronPython are probably changing rapidly Jeff>-- cPython, not such much. Haven't the slightest idea. Check Andrew's What's New document. Jeff> 4) How many committers to the cPython core are there? 71, according to the Assignee menu in SourceForge. I suspect at most a quarter of them are active. 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] Need Survey Answers from Core Developers
Brett Cannon schrieb: > 4) How many committers to the cPython core are there? > >I don't have the necessary access to the pydotorg infrastructure >to answer this -- can someone who does help me out here? > > > According to > http://www.ohloh.net/projects/26/analyses/latest/contributors , 92 > people over the life of the project, but 51 over the last year. Heh. I was about to point that out too, but somehow 51 seemed a very large number to me... 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] Mass PEP status changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 18, 2007, at 1:40 PM, Guido van Rossum wrote: > SR 354 Enumerations in Python Finney > Rejected; not enough interest, not sufficiently Pythonic. I have a competing proposal for enumerations which I just haven't gotten around to spec'ing out yet. Check the the cheeseshop for the 'munepy' package if you're interested (mune == enum backwards, since 'enum' was already taken). Guido, can you tell me whether the concept of enums for Python is being rejected, or this specific proposal? My proposal would be quite different, and I think, more Pythonic. Should I bother submitting a PEP? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRk366XEjvBPtnXfVAQKL1wP8D/iUag8jCCjFTT1Qa+Z1iwFcGCFgHq7c +ZzR2PrqkG8+2f3MxEa31GMZZpyNyBxh50QSpSeEx/NLfFSLyWtrY1q58BwSfay2 b7ClZmvjC4wlLJzuTxpO05MXhu2nbS5TQ0h2ut+HDvKe8bCHVs1Me48mEYa/BYF0 rvSCShoa37o= =DAER -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
[Python-Dev] accepted peps that should be final?
Are the following accepted PEPs implemented and should be marked final: SA 358 The "bytes" Object Schemenauer, GvR SA 3106 Revamping dict.keys(), .values() & .items() GvR SA 3109 Raising Exceptions in Python 3000Winter SA 3110 Catching Exceptions in Python 3000 Winter SA 3111 Simple input built-in in Python 3000 Roberge SA 3112 Bytes literals in Python 3000Orendorff 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] Mass PEP status changes
On 5/18/07, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On May 18, 2007, at 1:40 PM, Guido van Rossum wrote: > > > SR 354 Enumerations in Python Finney > > Rejected; not enough interest, not sufficiently Pythonic. > > I have a competing proposal for enumerations which I just haven't > gotten around to spec'ing out yet. Check the the cheeseshop for the > 'munepy' package if you're interested (mune == enum backwards, since > 'enum' was already taken). > > Guido, can you tell me whether the concept of enums for Python is > being rejected, or this specific proposal? My proposal would be > quite different, and I think, more Pythonic. Should I bother > submitting a PEP? That's really up to the rest of the community. If their response to your proposal is going to be as lackluster as to PEP 354, don't bother. Perhaps you can test the waters on python-ideas or c.l.py. -- --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] accepted peps that should be final?
On 5/18/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: > Are the following accepted PEPs implemented and should be marked final: > > SA 358 The "bytes" Object Schemenauer, GvR > SA 3106 Revamping dict.keys(), .values() & .items() GvR Not yet -- the implementations of these two are incomplete. > SA 3109 Raising Exceptions in Python 3000Winter > SA 3110 Catching Exceptions in Python 3000 Winter I believe Collin is still working on a patch. > SA 3111 Simple input built-in in Python 3000 Roberge Final. > SA 3112 Bytes literals in Python 3000Orendorff Let's keep this open since it is still a subject of debate, e.g. some folks feel that b"..." should be immutable. -- --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] accepted peps that should be final?
On 5/18/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: > Are the following accepted PEPs implemented and should be marked final: > > SA 3109 Raising Exceptions in Python 3000Winter Not yet implemented, will be this weekend. > SA 3110 Catching Exceptions in Python 3000 Winter This is implemented (I'll update the PEP to reflect this). Has a decision been made as to whether 2.6 will support both "," and "as" in except statements? Collin Winter ___ 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] Mass PEP status changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 18, 2007, at 3:17 PM, Guido van Rossum wrote: >> Guido, can you tell me whether the concept of enums for Python is >> being rejected, or this specific proposal? My proposal would be >> quite different, and I think, more Pythonic. Should I bother >> submitting a PEP? > > That's really up to the rest of the community. If their response to > your proposal is going to be as lackluster as to PEP 354, don't > bother. Perhaps you can test the waters on python-ideas or c.l.py. I guess the first step would be to announce the package on c.l.py.a :). But cool, that tells me what I wanted to know. Thanks, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRk39RnEjvBPtnXfVAQJ+BAQAm5oc/gzHq1bcwUt961Rc/9Ga7SX0CQI3 qcpSgQTnUOQxOFgas71tfZ1KC0Hg8ceD/L+3OnTeANY+HVjN/3B+JFLTdELYrCu7 bjJNZvnlkq46/fjR8YXgPwoAH8LgFZgrOxaGLZw4IpTWU5p3MRJJXR9344lG/zR3 zKbtUssefZk= =bs9n -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] accepted peps that should be final?
On 5/18/07, Collin Winter <[EMAIL PROTECTED]> wrote: > > > SA 3110 Catching Exceptions in Python 3000 Winter > > This is implemented (I'll update the PEP to reflect this). Has a > decision been made as to whether 2.6 will support both "," and "as" in > except statements? I think 'except as' should go into 2.6. I haven't heard any reason not to make this change. It should be easy to implement. 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] Wither PEP 335 (Overloadable Boolean Operators)?
Guido van Rossum wrote: > While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean > Operators) by Greg Ewing. I am of two minds of this -- on the one > hand, it's been a long time without any working code or anything. OTOH > it might be quite useful to e.g. numpy folks. This kind of feature would also be useful for ORMs, to be able to map boolean operators to SQL. Johan ___ 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] accepted peps that should be final?
On 5/18/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 5/18/07, Collin Winter <[EMAIL PROTECTED]> wrote: > > > > > SA 3110 Catching Exceptions in Python 3000 Winter > > > > This is implemented (I'll update the PEP to reflect this). Has a > > decision been made as to whether 2.6 will support both "," and "as" in > > except statements? > > I think 'except as' should go into 2.6. I haven't heard any reason > not to make this change. It should be easy to implement. Just the syntax, right, or should the end-of-suite cleanup code be backported, too? Collin Winter ___ 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] accepted peps that should be final?
On 5/18/07, Collin Winter <[EMAIL PROTECTED]> wrote: > On 5/18/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > On 5/18/07, Collin Winter <[EMAIL PROTECTED]> wrote: > > > > > > > SA 3110 Catching Exceptions in Python 3000 Winter > > > > > > This is implemented (I'll update the PEP to reflect this). Has a > > > decision been made as to whether 2.6 will support both "," and "as" in > > > except statements? > > > > I think 'except as' should go into 2.6. I haven't heard any reason > > not to make this change. It should be easy to implement. > > Just the syntax, right, or should the end-of-suite cleanup code be > backported, too? Yes, just the syntax. That will make it similar to loop comprehension leaking the var in 2.6, but not 3.0. 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] Summary of Tracker Issues
"Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | I think it would be better to do content. URLs come to mind; without | something clickable, most commercial spam would be hamstrung. But | few bug reports and patches need to contain URLs, except for | specialized local ones pointing to related issues. A bug is a disparity between promise and performance. Promise is often best demonstrated by a link to the relevant section of the docs. Doc patches should also contain a such a link. So doc references should be included with local (to tracker) links and not filtered on. | For example, how about requiring user interaction to display any post | containing an URL, until an admin approves it? Why not simply embargo any post with an off-site link? Tho there might have been some, I can't remember a single example of such at SF. Anybody posting such could certainly understand "Because this post contains an off-site link, it will be embargoed until reviewed to ensure that it is legitimate." | Or you could provide a preview containing the first two non-empty lines | not containing an URL. | This *would* be inconvenient for large attachments and other | data where the reporter prefers to provide an URL rather than the | literal data, but OTOH only people who indicate they really want to | see spam would see it. ;-) I don't get this, but it sounds like more work than simple embargo. I think html attachments should also be embargoed (I believe this is what I saw a couple of months ago.) And perhaps the account uploading an html file. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
On 5/18/07, Terry Reedy <[EMAIL PROTECTED]> wrote: "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | I think it would be better to do content. URLs come to mind; without | something clickable, most commercial spam would be hamstrung. But | few bug reports and patches need to contain URLs, except for | specialized local ones pointing to related issues. A bug is a disparity between promise and performance. Promise is often best demonstrated by a link to the relevant section of the docs. Doc patches should also contain a such a link. So doc references should be included with local (to tracker) links and not filtered on. | For example, how about requiring user interaction to display any post | containing an URL, until an admin approves it? Why not simply embargo any post with an off-site link? Tho there might have been some, I can't remember a single example of such at SF. Anybody posting such could certainly understand "Because this post contains an off-site link, it will be embargoed until reviewed to ensure that it is legitimate." | Or you could provide a preview containing the first two non-empty lines | not containing an URL. | This *would* be inconvenient for large attachments and other | data where the reporter prefers to provide an URL rather than the | literal data, but OTOH only people who indicate they really want to | see spam would see it. ;-) I don't get this, but it sounds like more work than simple embargo. I think html attachments should also be embargoed (I believe this is what I saw a couple of months ago.) And perhaps the account uploading an html file. If you guys want to see any of this happen please take this discussion over to the tracker-discuss mailing list. -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] Py2.6 buildouts to the set API
Here some ideas that have been proposed for sets: * New method (proposed by Shane Holloway): s1.isdisjoint(s2). Logically equivalent to "not s1.intersection(s2)" but has an early-out if a common member is found. The speed-up is potentially large given two big sets that may largely overlap or may not intersect at all. There is also a memory savings since a new set does not have to be formed and then thrown away. * Additional optional arguments for basic set operations to allow chained operations. For example, s=s1.union(s2, s3, s4) would be logically equivalent to s=s1.union(s2).union(s3).union(s4) but would run faster because no intermediate sets are created, copied, and discarded. It would run as if written: s=s1.copy(); s.update(s2); s.update(s3); s.update(s4). * Make sets listenable for changes (proposed by Jason Wells): s = set(mydata) def callback(s): print 'Set %d now has %d items' % (id(s), len(s)) s.listeners.append(callback) s.add(existing_element) # no callback s.add(new_element)# callback 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
Re: [Python-Dev] Py2.6 buildouts to the set API
On 18-May-07, at 6:34 PM, Raymond Hettinger wrote: > Here some ideas that have been proposed for sets: > > * New method (proposed by Shane Holloway): s1.isdisjoint(s2). > Logically equivalent to "not s1.intersection(s2)" but has an early- > out if a common member is found. The speed-up is potentially large > given two big sets that may largely overlap or may not intersect at > all. There is also a memory savings since a new set does not have > to be formed and then thrown away. +1. Disjointness verification is one of my main uses for set(), and though I don't think that the early-out condition would trigger often in my code, it would increase readability. > * Additional optional arguments for basic set operations to allow > chained operations. For example, s=s1.union(s2, s3, s4) would be > logically equivalent to s=s1.union(s2).union(s3).union(s4) but > would run faster because no intermediate sets are created, copied, > and discarded. It would run as if written: s=s1.copy(); s.update > (s2); s.update(s3); s.update(s4). It's too bad that this couldn't work with the binary operator spelling: s = s1 | s2 | s3 | s4 > * Make sets listenable for changes (proposed by Jason Wells): > > s = set(mydata) > def callback(s): > print 'Set %d now has %d items' % (id(s), len(s)) > s.listeners.append(callback) > s.add(existing_element) # no callback > s.add(new_element)# callback -1 on the base set type: it seems too complex for a base set type. Also, there are various possible semantics that might be desirable, such as receiving the added element, or returning False to prevent addition. The proper place is perhaps a subclass of set with a magic method (analogous to defaultdict/__missing__). -Mike ___ 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] Wither PEP 335 (Overloadable Boolean Operators)?
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean | Operators) by Greg Ewing. I am of two minds of this -- on the one | hand, it's been a long time without any working code or anything. OTOH | it might be quite useful to e.g. numpy folks. | | It is time to reject it due to lack of interest, or revive it! Rejection would currently be fine with me, so I do not intend this to indicate 'revived interest'. But having looked at the PEP now, I have some comments in case anyone else has such. Rationale: if the only extra time without the overloads is the check of Py_TPFLAGS_HAVE_BOOLEAN_OVERLOAD then I suppose it might be 'not appreciable', but in my ignorance, I would be more persuaded by timing data ;-) Motivation: another 'workaround' is the one used in symbolic logic, dating back to Boole himself. '+' for 'or' and '*' for 'and'. But these are also needed as in in your motivating cases. A counter-motivation is that this proposal makes it even harder to reason about the behavior of Python programs. It adds one more caveat to stick in the back of ones mind. Other overloads do the same, but to me, overloading logic cuts a bit deeper. Special Methods: the proposal strikes me as clever but excessively baroque. In the absence of justification for the complexities, here is a *much* simpler version. Delete special casing of NonImplemented. __not__: substitute for default semantics when present. Delete NeedOtherOperand (where would it even live?). The current spelling is True for and and False for or, as with standard semantics. A class that does not want short circuiting, as in your motivating cases, simply defines __and1__ or __or1__ to return True or False. If the return value of __xxx1__ is not True/False, then it is the result. (I believe this matches your spec.) So the LOGICAL_XXX_1 bytecodes check for True/False identity without calling bool() on the result. Delete the reverse methods. They are only needed for mixed-type operations, like scaler*matrix. But such seems senseless here. In any case, they are not needed for any of your motivating applications, which would define both methods without mixing. If the second arg is evaluated, the result is __x2__(arg1,arg2) if defined, else arg2 as usual. Delete the 'As a special case' sentence. Type Slots: someone else can decide if a new flag and 5 new slots are a significant price. Python/C API: 5 more to learn or ignore, but that does not affect me. I do not understand what they would do or how they relate to the byte codes. Other Implementations: any possible problems? (I have no idea.) Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
Terry Reedy writes: > Why not simply embargo any post with an off-site link? Tho there might > have been some, I can't remember a single example of such at SF. Fine by me; if it doesn't happen often, then embargoing them would be fine. My occasional experience with distro reporting processes shows that they happen a fair amount there (often as a reference to an upstream or downstream bug report). The major ones can probably be special-cased easily as needed. > I don't get [the short preview idea], but it sounds like more work > than simple embargo. It would be. It is a use-case that according to your explanation doesn't apply to Python's tracker, so a YAGNI until proved otherwise. > I think html attachments should also be embargoed (I believe this is what I > saw a couple of months ago.) And perhaps the account uploading an html > file. Sounds OK to me, except that there are some modules that handle HTML (and XML? can that be practically distinguished from HTML?), and I would suppose people would want upload examples and test cases. ___ 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] Summary of Tracker Issues
> -Original Message- > From: [EMAIL PROTECTED] [mailto:python- > [EMAIL PROTECTED] On Behalf Of Stephen J. > Turnbull > Sent: Friday, May 18, 2007 3:10 AM > To: python-dev@python.org > Subject: Re: [Python-Dev] Summary of Tracker Issues > > O.R.Senthil Kumaran writes: > > > :-) My idea was, a human got to answer it unscrambled as 'fourth' as > he > > "understands" what the question is and gives the proper answer. > > > Agreed, there could be confusion at first. > > password, or they say WTF!! In that case we could lose all the bug > reports they were ever going to write. That's bad. > If we're going to do CAPTCHA, what we're looking for is something that > any 4 year old does automatically, but machines can't do at all. > Visual recognition used to be one, but isn't any more. The CAPTCHA > literature claims that segmentation still is (dividing complex images > into letters), but that's nontrivial for humans, too, and I think that > machines will eventually catch up. (Ie, within a handful of months.) Complex backgrounds used? Colorful foreground on a interior decorating background. Also gradient foreground, gradient background. > I think it would be better to do content. URLs come to mind; without > something clickable, most commercial spam would be hamstrung. But > few bug reports and patches need to contain URLs, except for > specialized local ones pointing to related issues. > > For example, how about requiring user interaction to display any post > containing an URL, until an admin approves it? Or you could provide a > preview containing the first two non-empty lines not containing an > URL. This *would* be inconvenient for large attachments and other > data where the reporter prefers to provide an URL rather than the > literal data, but OTOH only people who indicate they really want to > see spam would see it. ;-) Block spam or hide? Maybe a reader is what you want. "Posting a URL requires heavier spam-proofing. Click here to authenticate yourself." Takes you to ours- the PL question. ___ 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] Py2.6 buildouts to the set API
On Fri, May 18, 2007, Raymond Hettinger wrote: > > Here some ideas that have been proposed for sets: > > * New method (proposed by Shane Holloway): s1.isdisjoint(s2). > Logically equivalent to "not s1.intersection(s2)" but has an early-out > if a common member is found. The speed-up is potentially large given > two big sets that may largely overlap or may not intersect at all. > There is also a memory savings since a new set does not have to be > formed and then thrown away. +1 > * Additional optional arguments for basic set operations to allow > chained operations. For example, s=s1.union(s2, s3, s4) would be > logically equivalent to s=s1.union(s2).union(s3).union(s4) but would > run faster because no intermediate sets are created, copied, and > discarded. It would run as if written: s=s1.copy(); s.update(s2); > s.update(s3); s.update(s4). +1 > * Make sets listenable for changes (proposed by Jason Wells): > > s = set(mydata) > def callback(s): > print 'Set %d now has %d items' % (id(s), len(s)) > s.listeners.append(callback) > s.add(existing_element) # no callback > s.add(new_element)# callback -3 -- that's an ugly wart on what is currently a nice, clean object. This seems like a good opportunity for a Cookbook Recipe for a generic listenable proxy class for container objects. Note that I could argue for the callback to be called even when the set doesn't actually change, only when the set is attempted to be changed, which to my mind pushes strongly for a recipe instead of extending sets. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet ___ 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] Py2.6 buildouts to the set API
> -Original Message- > From: [EMAIL PROTECTED] [mailto:python- > [EMAIL PROTECTED] On Behalf Of Raymond > Hettinger > Sent: Friday, May 18, 2007 8:35 PM > To: python-dev@python.org > Subject: [Python-Dev] Py2.6 buildouts to the set API > > Here some ideas that have been proposed for sets: > > * New method (proposed by Shane Holloway): s1.isdisjoint(s2). Logically > equivalent to "not s1.intersection(s2)" but has an early-out if a common > member is found. The speed-up is potentially large given two big sets > that may largely overlap or may not intersect at all. There is also a > memory savings since a new set does not have to be formed and then thrown > away. It sounds -really- good. > * Additional optional arguments for basic set operations to allow chained > operations. For example, s=s1.union(s2, s3, s4) would be logically > equivalent to s=s1.union(s2).union(s3).union(s4) but would run faster > because no intermediate sets are created, copied, and discarded. It would > run as if written: s=s1.copy(); s.update(s2); s.update(s3); s.update(s4). This pleads for elsewhere adding operation in chains. Sort on multiple keys is addressed by itemgetter (IMO also should be built-in). But dict.update, a list append, a deque pop could use these. When-do-you-ever is out of stock and ships in a week. > * Make sets listenable for changes (proposed by Jason Wells): > > s = set(mydata) > def callback(s): > print 'Set %d now has %d items' % (id(s), len(s)) > s.listeners.append(callback) > s.add(existing_element) # no callback > s.add(new_element)# callback This one calls for subclassing, a la observer pattern. In that vein, some subclassing operation could use a list of pattern-matching / semantic membership. E.g. def every_add_op( self, op, ***data ): call_a_hook( ***data ) op( ***data ) Rings of ML. Support could be provided with def __init__... for x in ( add, update, intersection_update ): def my_x( self, ***data ): call_a_hook( ***data ) x( ***data ) setattr( self, x, my_x ) But you need to know which operations are destructive/constructive, but we can't go back and annotate the whole stdlib. Though I agree that some level of programmatic interference could be useful. Academic concern which shoots 50-50 in the real world. I may be tempered with too much beauty (Beautiful is better than ugly.), not enough market. You're all in it for money. ___ 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
