Showing content from https://mail.python.org/pipermail/python-dev/2000-February.txt below:
From Moshe Zadka Tue Feb 1 02:20:41 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 1 Feb 2000 04:20:41 +0200 (IST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: Message-ID: On Mon, 31 Jan 2000 gvwilson@nevex.com wrote: > > It (?:) would allow you to incorporate logic into expressions. > > There are contexts where only expressions are allowed, such as: > > - lambdas > > - DTML expr attributes > > in which I'd very much like to incorporate tests. > > Don't know much about DTML, but believe that being able to put > conditionals in lambdas would make the latter much more useful. Giving Guido one less reason to dislike ?: Seriously, I disagree with the basic premise of you and Jim: you can *already* have control structures inside experessions with and/or, so even for Jim's twisted meanings for "add new functionality to the language" it's not true. > Is anything easier with ?: --- yes. For the reader, for the writer or for the cp4e-newbie learning Python? cluttering-another-mailing-list-ly y'rs, Z. -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From esr@thyrsus.com Tue Feb 1 02:33:18 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 31 Jan 2000 21:33:18 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: ; from Moshe Zadka on Tue, Feb 01, 2000 at 04:20:41AM +0200 References: Message-ID: <20000131213317.A25109@thyrsus.com> Moshe Zadka : > > Don't know much about DTML, but believe that being able to put > > conditionals in lambdas would make the latter much more useful. > > Giving Guido one less reason to dislike ?: You laugh, but this was in fact in my mind. -- Eric S. Raymond Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln From tim_one@email.msn.com Tue Feb 1 03:03:59 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 31 Jan 2000 22:03:59 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <200001311436.JAA15213@eric.cnri.reston.va.us> Message-ID: <000801bf6c60$fc41e3a0$d709143f@tim> [Guido] > ... > The solution can be the same as what Algol used: 'if' outside > parentheses is a statement, and inside parentheses is an expression. > It's a bit of a grammar rearrangement, but totally unambiguous. If I didn't know better , I'd say there's an actual consensus here: it seems we would all agree to "(if cond then true else false)" spelling. Not to be overlooked is Christian's enhancement, allowing "elif" too (beats all heck out of guessing how ?: nests!). Eric, are you also in agreement? > However, the added keyword means it won't be in 1.6. I had already channeled that for the group's benefit . For 1.6, without absurd overloading of some other keyword (like "if cond def true ..."), that seems to leave (if cond: true else false) How much is that hated? I hate it myself, not least because I'd have to change IDLE's parser to guarantee it couldn't get confused by the colon here: big = ( if x >= y: x else y) Given the genesis of these things, Barry would probably have to commit similar hackery on pymode. That shouldn't drive it, but it's worth a thought. The best argument against any enhancement of this nature was Jim Fulton's argument for it: it makes lambda more attractive . BTW, I'm not entirely convinced "then" would have to be a keyword to make "if x then y else z" work: couldn't the grammar use WORD and verify it's specifically "then" later? I'm not impressed by "but that would allow 'then = (if then then else then)'!" arguments (yes, it would; no, nobody would *do* that except in an hysterical c.l.py posting <0.1 wink>). From gvwilson@nevex.com Tue Feb 1 03:13:07 2000 From: gvwilson@nevex.com (gvwilson@nevex.com) Date: Mon, 31 Jan 2000 22:13:07 -0500 (EST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: Message-ID: > Moshe Zadka wrote: > Seriously, I disagree with the basic premise of you and Jim: you can > *already* have control structures inside experessions with and/or, so > even for Jim's twisted meanings for "add new functionality to the > language" it's not true. Have you ever tried to teach this to relatively experienced programmers (never mind novices) whose background is Fortran, Modula-2, Ada, or anything other than C/C++/Java? It's *really* hard to get the idea across. I tried it in the first Python course I taught at LANL, and wound up spending 15 minutes trying to unconfuse people (and failed). Afterward, one guy said that it made even less sense than using integer offsets to fake linked lists in Fortran-77... Greg From Moshe Zadka Tue Feb 1 03:17:53 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 1 Feb 2000 05:17:53 +0200 (IST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: Message-ID: On Mon, 31 Jan 2000 gvwilson@nevex.com wrote: > > Moshe Zadka wrote: > > Seriously, I disagree with the basic premise of you and Jim: you can > > *already* have control structures inside experessions with and/or, so > > even for Jim's twisted meanings for "add new functionality to the > > language" it's not true. > You're most certainly right. This, however, refers to usability, not functionality. It makes existing functionality usable by non-timbots. A worthy goal, but it's not the same as adding new functionality. -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From esr@thyrsus.com Tue Feb 1 03:25:01 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 31 Jan 2000 22:25:01 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <000801bf6c60$fc41e3a0$d709143f@tim>; from Tim Peters on Mon, Jan 31, 2000 at 10:03:59PM -0500 References: <200001311436.JAA15213@eric.cnri.reston.va.us> <000801bf6c60$fc41e3a0$d709143f@tim> Message-ID: <20000131222501.B25299@thyrsus.com> Tim Peters : > > ... > > The solution can be the same as what Algol used: 'if' outside > > parentheses is a statement, and inside parentheses is an expression. > > It's a bit of a grammar rearrangement, but totally unambiguous. > > If I didn't know better , I'd say there's an actual consensus here: > it seems we would all agree to "(if cond then true else false)" spelling. > Not to be overlooked is Christian's enhancement, allowing "elif" too (beats > all heck out of guessing how ?: nests!). > > Eric, are you also in agreement? I'm not sure. I'm concerned that this syntax will actually be more viually confusing that ?:. That having been said, I am more interested in having ternary-select be in the language than I am in arguing about its exact syntax. -- Eric S. Raymond Men trained in arms from their infancy, and animated by the love of liberty, will afford neither a cheap or easy conquest. -- From the Declaration of the Continental Congress, July 1775. From ping@lfw.org Tue Feb 1 03:56:28 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 31 Jan 2000 21:56:28 -0600 (EST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <000801bf6c60$fc41e3a0$d709143f@tim> Message-ID: On Mon, 31 Jan 2000, Tim Peters wrote: > If I didn't know better , I'd say there's an actual consensus here: > it seems we would all agree to "(if cond then true else false)" spelling. Actually, i'm afraid i don't. I initially chose the "then/else" spelling specifically because "if" flags the eye to the beginning of a statement. My line of thinking was, "'then' for expressions, 'if' for statements." > I had already channeled that for the group's benefit . For 1.6, > without absurd overloading of some other keyword (like "if cond def true > ..."), that seems to leave > > (if cond: true else false) Sorry, i like that even less. It seems to abuse the colon, for the colon (to me) signals both (a) This Is A Statement and (b) This Begins A Block, neither of which are true here. > How much is that hated? I hate it myself, not least because I'd have to > change IDLE's parser to guarantee it couldn't get confused by the colon > here: > > big = ( > if x >= y: > x else y) I consider this a symptom of the colon-abuse i just described... > BTW, I'm not entirely convinced "then" would have to be a keyword to make > "if x then y else z" work: couldn't the grammar use WORD and verify it's > specifically "then" later? Quite possibly, yes -- though i figured it wouldn't be *too* large an issue to make "then" a keyword, since i can't imagine anyone naming a symbol "then" except under the most freakish of circumstances. A quick check shows no symbol by that name in any of the Python scripts or modules we have here. -- ?!ng From ping@lfw.org Tue Feb 1 04:05:45 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 31 Jan 2000 22:05:45 -0600 (EST) Subject: [Python-Dev] timelocal Message-ID: I noticed that there doesn't currently seem to be a function that takes a tuple of date information (like that returned by localtime()) and turns it into a Unix time -- effectively, the reverse operation to localtime() or gmtime(). It's a very useful operation to have when working with dates and times. Perl has it in the timelocal.pl script and i was thinking of stealing the logic in it to add a similar function to Python. So, before i go reinvent the wheel -- have i missed the fact that we already have this function? Would anyone care if it was added? Thanks for your thoughts... -- ?!ng From fdrake@acm.org Tue Feb 1 03:49:47 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 31 Jan 2000 22:49:47 -0500 (EST) Subject: [Python-Dev] timelocal In-Reply-To: References: Message-ID: <14486.22491.791218.69042@weyr.cnri.reston.va.us> Ka-Ping Yee writes: > So, before i go reinvent the wheel -- have i missed the > fact that we already have this function? Would anyone > care if it was added? I'd love to see this added! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From tim_one@email.msn.com Tue Feb 1 03:49:57 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 31 Jan 2000 22:49:57 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: Message-ID: <000a01bf6c67$680a4cc0$d709143f@tim> [Tim] >> If I didn't know better , I'd say there's an actual >> consensus here: it seems we would all agree to "(if cond then >> true else false)" spelling. [Ka-Ping Yee] > Actually, i'm afraid i don't. I initially chose the "then/else" > spelling specifically because "if" flags the eye to the beginning > of a statement. My line of thinking was, "'then' for expressions, > 'if' for statements." OK, I'm baffled. I probably don't recall your suggestion -- the implication is that it didn't use the word "if"? If so, I probably read it and assumed you left out the "if" my mistake . Seriously, "excessively novel" isn't called for here: *tons* of languages have used if/then/else for this purpose without difficulty. ... >> ... couldn't the grammar use WORD and verify it's >> specifically "then" later? > Quite possibly, yes -- though i figured it wouldn't be *too* > large an issue to make "then" a keyword, since i can't imagine > anyone naming a symbol "then" except under the most freakish > of circumstances. A quick check shows no symbol by that name > in any of the Python scripts or modules we have here. No keyword has been added to Python since "lambda", and you can be certain Guido will never add another (at least not to Python1) -- this is an absolute non-starter. Ping, *you* used to know this better than anyone . From gvwilson@nevex.com Tue Feb 1 04:00:56 2000 From: gvwilson@nevex.com (gvwilson@nevex.com) Date: Mon, 31 Jan 2000 23:00:56 -0500 (EST) Subject: [Python-Dev] Re: ternary operators (fwd) Message-ID: So I asked Simon Peyton-Jones and Phil Wadler how languages other than C and its derivatives did conditional expressions; one of the replies was: On Mon, 31 Jan 2000, Philip Wadler wrote: > Tony Hoare had a nice ternary `if'. He writes > > if c then d else e > > as > > d e > > This satisfies an associative law: > > d (e f) = d f = (d e) f > > The paper appeared, I think, in CACM circa 1982. Perhaps this would be a good time to ask around and see what else people have in their back pockets? A-week-of-coding-can-sometimes-save-an-hour-in-the-library'ly yours, Greg From ping@lfw.org Tue Feb 1 04:27:02 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 31 Jan 2000 22:27:02 -0600 (EST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <000a01bf6c67$680a4cc0$d709143f@tim> Message-ID: On Mon, 31 Jan 2000, Tim Peters wrote: > [Tim] > >> If I didn't know better , I'd say there's an actual > >> consensus here: it seems we would all agree to "(if cond then > >> true else false)" spelling. > > [Ka-Ping Yee] > > Actually, i'm afraid i don't. I initially chose the "then/else" > > spelling specifically because "if" flags the eye to the beginning > > of a statement. My line of thinking was, "'then' for expressions, > > 'if' for statements." > > OK, I'm baffled. I probably don't recall your suggestion -- the implication > is that it didn't use the word "if"? If so, I probably read it and assumed > you left out the "if" my mistake . Yeah, my suggestion was, e.g. def abs(x): return x > 0 then x else -x Might as well summarize the other suggestions so far: return x > 0 ? x else -x return x > 0 ? x : -x return if x > 0: x else -x Have i missed any? Oh, yes, and here is the control group. return x > 0 and x or -x return (x > 0 and [x] or [-x])[0] if x > 0: return x else: return -x > Seriously, "excessively novel" isn't called for here: > *tons* of languages have used if/then/else for this > purpose without difficulty. Yes, you're right about that. > No keyword has been added to Python since "lambda", and you can be certain > Guido will never add another (at least not to Python1) -- this is an > absolute non-starter. Ping, *you* used to know this better than anyone > . Okay, okay. You probably have a better memory about this than i do. :) Assuming that "then" will never be made a keyword, i would probably go with "x > 0 ? x else -x". "if" seems to shout "statement" too loudly at me, and colons seem too loaded. Another issue with the last suggestion: how do you explain putting a colon after the condition but not after the "else"? -- ?!ng From ping@lfw.org Tue Feb 1 04:29:40 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 31 Jan 2000 22:29:40 -0600 (EST) Subject: [Python-Dev] Re: ternary operators (fwd) In-Reply-To: Message-ID: On Mon, 31 Jan 2000 gvwilson@nevex.com wrote: > So I asked Simon Peyton-Jones and Phil Wadler how languages other than C > and its derivatives did conditional expressions; one of the replies was: > > On Mon, 31 Jan 2000, Philip Wadler wrote: > > > Tony Hoare had a nice ternary `if'. He writes > > > > if c then d else e > > > > as > > > > d e Wait -- how the heck is this supposed to parse if 'c' is an arbitrary expression? I think we've run out of bracket-like thingies. (Yes, that would be the technical term). It also looks pretty opaque -- even if you do intuit that it's ternary-select (which i wouldn't if you hadn't told me) it still isn't really obvious which side is which. -- ?!ng From gvwilson@nevex.com Tue Feb 1 04:15:58 2000 From: gvwilson@nevex.com (gvwilson@nevex.com) Date: Mon, 31 Jan 2000 23:15:58 -0500 (EST) Subject: [Python-Dev] Re: ternary operators (fwd) In-Reply-To: Message-ID: > > On Mon, 31 Jan 2000, Philip Wadler wrote: > > > Tony Hoare had a nice ternary `if'. He writes > > > if c then d else e > > > as > > > d e > Ka-Ping Yee writes: > Wait -- how the heck is this supposed to parse if 'c' is an > arbitrary expression? Replace '<' and '>' with the symbols of your choice --- embedding the conditional in the middle is still an interesting idea... > I think we've run out of bracket-like thingies. (Yes, that > would be the technical term). > -- ?!ng Well, if people are going to spell there names like *that*, it's no wonder we've run out of bracket-like thingies... :-) save-the-punctionally yours Greg From esr@thyrsus.com Tue Feb 1 04:24:13 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 31 Jan 2000 23:24:13 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: ; from Ka-Ping Yee on Mon, Jan 31, 2000 at 10:27:02PM -0600 References: <000a01bf6c67$680a4cc0$d709143f@tim> Message-ID: <20000131232413.A26454@thyrsus.com> Ka-Ping Yee : > Might as well summarize the other suggestions so far: > > return if x > 0: x else -x > return x > 0 ? x else -x Mixing ? or : with a keyword is just *ugly*. Yes, I know I said I wasn't that interested in arguing syntax, but these make my gorge rise. > return x > 0 ? x : -x I think the other suggestions are making this one look better. At this point I have to like either this or the algol68 style Guido mentioned. -- Eric S. Raymond The conclusion is thus inescapable that the history, concept, and wording of the second amendment to the Constitution of the United States, as well as its interpretation by every major commentator and court in the first half-century after its ratification, indicates that what is protected is an individual right of a private citizen to own and carry firearms in a peaceful manner. -- Report of the Subcommittee On The Constitution of the Committee On The Judiciary, United States Senate, 97th Congress, second session (February, 1982), SuDoc# Y4.J 89/2: Ar 5/5 From da@ski.org Tue Feb 1 05:33:41 2000 From: da@ski.org (David Ascher) Date: Mon, 31 Jan 2000 21:33:41 -0800 Subject: [Python-Dev] Re: ternary operators (fwd) References: Message-ID: <003d01bf6c75$e6700e20$0100000a@ski.org> From: > > > > d e > Replace '<' and '>' with the symbols of your choice --- embedding the > conditional in the middle is still an interesting idea... Which brings us back to if and else: a = condition ? truecase : falsecase would be a = truecase if condition else falsecase What's unintuitive at this point is the shortcutting, assuming that it would still apply. 'condition' would get evaluated before truecase, and truecase might not get evaluated at all. Still, it 'reads' good to me. Not sure it's all that Pythonic though. --david From Moshe Zadka Tue Feb 1 05:51:08 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 1 Feb 2000 07:51:08 +0200 (IST) Subject: [Python-Dev] Re: ternary operators (fwd) In-Reply-To: Message-ID: On Mon, 31 Jan 2000 gvwilson@nevex.com wrote: > So I asked Simon Peyton-Jones and Phil Wadler how languages other than C > and its derivatives did conditional expressions; one of the replies was: > Perhaps this would be a good time to ask around and see what else people > have in their back pockets? Adding nothing to the discussion, let me just mention how Scheme (my second favourite language) does it: (if bool true-result else-result) Well, of course this isn't relevant to Python because statements are not expressions, but there might be something in it: if could be also used as a function taking three arguments: print if(long_answer, "Very good!", "correct") I have no idea how this will play with the parser. Anyone? -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From gstein@lyra.org Tue Feb 1 07:15:04 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 31 Jan 2000 23:15:04 -0800 (PST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: Message-ID: On Mon, 31 Jan 2000, Ka-Ping Yee wrote: > On Mon, 31 Jan 2000, Tim Peters wrote: >... > > No keyword has been added to Python since "lambda", and you can be certain > > Guido will never add another (at least not to Python1) -- this is an > > absolute non-starter. Ping, *you* used to know this better than anyone > > . > > Okay, okay. You probably have a better memory about this than i do. :) Actually, Tim's memory is failing. "assert" was added in 1.5. :-) Not that this adds to the debate at all :-), but I figured that I am obligated to knock a chair leg out from under Tim every now and then. Cheers, -g p.s. I'm against a ternary operator. use an if/else statement. use def instead of lambda (lambda is the only rational basis given so far to add the operator, but it is bogus to start with) -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Tue Feb 1 07:45:42 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 1 Feb 2000 02:45:42 -0500 Subject: [Python-Dev] Re: ternary operators (fwd) In-Reply-To: Message-ID: <000301bf6c88$579e2fc0$242d153f@tim> [Moshe Zadka] > ... > Adding nothing to the discussion, let me just mention how Scheme (my > second favourite language) does it: > > (if bool true-result else-result) > > Well, of course this isn't relevant to Python because statements are not > expressions, but there might be something in it: if could be also used > as a function taking three arguments: "if" is a special form in Scheme; all Python functions are strict; short-circuiting is essential here. > print if(long_answer, "Very good!", "correct") > > I have no idea how this will play with the parser. Anyone? if(a, b, c) can't be distiguished from if (a, b, c): before the colon is seen, so it requires more lookahead than Python's parser is comfortable doing. From tim_one@email.msn.com Tue Feb 1 07:50:06 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 1 Feb 2000 02:50:06 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: Message-ID: <000401bf6c88$f4ed2ec0$242d153f@tim> [Tim] >> No keyword has been added to Python since "lambda" ... [Greg Stein] > Actually, Tim's memory is failing. "assert" was added in 1.5. :-) > > Not that this adds to the debate at all :-), but I figured that I am > obligated to knock a chair leg out from under Tim every now and then. Actually, in 1.5 Guido *removed* lambda; then he added assert; then he had second thoughts about lambda and added it again. That's why it's the last one added. You're right: the older I get the less effective my bullshit gets . Done well, young one! > p.s. I'm against a ternary operator. use an if/else statement. use > def instead of lambda (lambda is the only rational basis given so far to > add the operator, but it is bogus to start with) Ah, there's nothing like the smell of consensus in the morning! Except maybe napalm. From tim_one@email.msn.com Tue Feb 1 08:15:08 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 1 Feb 2000 03:15:08 -0500 Subject: [Python-Dev] Re: ternary operators (fwd) In-Reply-To: Message-ID: <000601bf6c8c$73eb87a0$242d153f@tim> [Greg Wilson, quoting Philip Wadler] > Tony Hoare had a nice ternary `if'. He writes > > if c then d else e > > as > > d e Noting that he first wrote "if c then d else e" so it would be *clear* what the heck he was talking about. So that's exactly the point at which Python should stop. After that, it's no longer clear, just formally elegant. I love Haskell too (and thank Philip for that), but it ain't Python. > This satisfies an associative law: > > d (e f) = d f = (d e) f Nobody writes nested ?: using the same condition twice; it's more interesting as an endcase absorption law. Does x (y z) = (x y) z ? Nope (e.g., suppose c1 is true and c2 is false). From tim_one@email.msn.com Tue Feb 1 08:28:42 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 1 Feb 2000 03:28:42 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: Message-ID: <000701bf6c8e$592adb80$242d153f@tim> [Ping] > Yeah, my suggestion was, e.g. > > def abs(x): > return x > 0 then x else -x Yup, I *did* mentally insert an "if" for you. You're welcome . > Might as well summarize the other suggestions so far: > > return x > 0 ? x else -x Toss it -- *nobody* wants it (if that's one I suggested, I get to retract it). > return x > 0 ? x : -x Has anyone other than Eric come out explicitly in favor of this spelling (I know others have come out in favor of a ternary operator, but don't recall much love for this syntax)? > return if x > 0: x else -x I get to retract that too (heck, I said I hated that one in the same sentence I tossed it out ...). > Have i missed any? Yes, the utterly conventional and perfectly clear one: return (if x > 0 then x else -x) If we don't buy into Guido's keyword argument, it's feasible. There was also some Perlish atrocity (not that I'm judging ...) like return x if x > 0 else -x > Assuming that "then" will never be made a keyword, i would probably > go with "x > 0 ? x else -x". "if" seems to shout "statement" too > loudly at me, and colons seem too loaded. Too late: it was mine & I retracted it . "if" doesn't really *shout* stmt unless it's at the start of a line. Wrap it in parens too and it's barely a whisper. > Another issue with the last suggestion: how do you explain putting a > colon after the condition but not after the "else"? The truth: "Because Guido is afraid of new keywords" . From gvwilson@nevex.com Tue Feb 1 13:07:26 2000 From: gvwilson@nevex.com (gvwilson@nevex.com) Date: Tue, 1 Feb 2000 08:07:26 -0500 (EST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <000701bf6c8e$592adb80$242d153f@tim> Message-ID: Maybe this would be a good time to write a dozen or so examples using alternative syntaxes (syntaxii?), and stick 'em in front of a bunch of people who haven't been part of this discussion, and ask 'em "what does this do"? (Footnote: check out David Scanlan's article in the Sept. 1989 issue of "IEEE Software". Turns out that flowcharts are actually more readable than pseudocode --- the research that claimed to show otherwise was biased by (among other things) comparing structured pseudocode with spaghetti flowcharts... One li'l bit of sloppy science, and the world turns its back on something useful...) Ellipsistically yours, Greg From guido@CNRI.Reston.VA.US Tue Feb 1 13:31:59 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 01 Feb 2000 08:31:59 -0500 Subject: [Python-Dev] timelocal In-Reply-To: Your message of "Mon, 31 Jan 2000 22:05:45 CST." References: Message-ID: <200002011331.IAA18515@eric.cnri.reston.va.us> > I noticed that there doesn't currently seem to be a > function that takes a tuple of date information (like > that returned by localtime()) and turns it into a > Unix time -- effectively, the reverse operation to > localtime() or gmtime(). To go from a local time tuple to Unix time, there's time.mktime(). To go from a gm time tuple to Unix time, there's calendar.timegm(). (The latter only exists in the CVS version.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Tue Feb 1 13:37:46 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 01 Feb 2000 08:37:46 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: Your message of "Mon, 31 Jan 2000 22:27:02 CST." References: Message-ID: <200002011337.IAA18548@eric.cnri.reston.va.us> > Yeah, my suggestion was, e.g. > > def abs(x): > return x > 0 then x else -x > > Might as well summarize the other suggestions so far: > > return x > 0 ? x else -x > > return x > 0 ? x : -x > > return if x > 0: x else -x > > Have i missed any? return if x > 0 then x else -x In some contexts, parentheses must be used, e.g. (if c then a else b)[0] = 1 > > No keyword has been added to Python since "lambda", and you can be certain > > Guido will never add another (at least not to Python1) -- this is an > > absolute non-starter. Ping, *you* used to know this better than anyone > > . > > Okay, okay. You probably have a better memory about this than i do. :) Hm, I was just thinking that 'then' wouldn't be the hardest keyword to add... But I should probably stick with Tim's suggestion. > Assuming that "then" will never be made a keyword, i would probably > go with "x > 0 ? x else -x". "if" seems to shout "statement" too > loudly at me, and colons seem too loaded. But "if" is in good company. > Another issue with the last suggestion: how do you explain putting a > colon after the condition but not after the "else"? Whoever proposed that was terribly confused. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas.heller@ion-tof.com Tue Feb 1 15:35:17 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue, 1 Feb 2000 16:35:17 +0100 Subject: [Python-Dev] Proposal: Registry access for Python on Windows Message-ID: <02a501bf6cc9$f1681620$4500a8c0@thomasnotebook> I propose to include functions to access the windows registry into the python 1.6 core. I have thrown together some code which I will post hopefully tomorrow, but I would like to hear some comments before. ---------------------------------------------------------------------- winreg - registry access module Constants: HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_USERS - bases of registry KEY_READ, KEY_WRITE, KEY_ALL_ACCESS - access rights REG_SZ, REG_DWORD, REG_BINARY - typecodes for values Exception: error - raised when a function fails. Will usually contain a windows error code and a textual description. Functions: OpenKey (base, subkey, [, rights=KEY_READ]) -> integer Opens an existing key with the specified access rights and returns an integer handle. The handle must be closed by a call to CloseKey(). CreateKey (base, subkey [, sam=KEY_ALL_ACCESS]) -> integer Creates a new subkey or opens an exsiting one and returns an integer handle. base must be one of the HKEY_ constants or an integer handle. The handle must be closed by a call to CloseKey(). CloseKey (handle) Closes a key handle. EnumValues (handle, subkey) -> sequence Returns a sequence containing name, value, typecode triples for each existing value. EnumKeys (handle, subkey) -> sequence Returns a sequence containing the names of all subkeys. QueryValue (handle, subkey) -> tuple Returns a tuple containing name, value and typecode. SetValue (handle, name, typecode, value) Sets the value of a name to value. value must be a string for REG_SZ or REG_BINARY, an integer for REG_DWORD. DeleteValue (handle, valuename) Deletes the value. DeleteKey (handle, name [,recursive=0) Deletes the named key if no subkeys exist. If recursive is given as a true value, subkeys are recursively deleted. This is done with Reg* calls, NOT with SHDeleteKey and SHDeleteEmptyKey functions, so should work under any flavor of NT and Win9x. Note: To use the SetValue and Delete* functions, the key must have been opened with KEY_WRITE_ACCESS or KEY_ALL_ACCESS. ---------------------------------------------------------------------- Open Questions: Is the recursive-flag for DeleteKey() too dangerous? Should I switch from an integer handle to a full blown python-object, which would call CloseKey() automatically in the destructor? A higher level interface would be nice, but this should probably implemented on top of this module in python. Comments appreciated! Thomas Heller ION-TOF GmbH From guido@CNRI.Reston.VA.US Tue Feb 1 16:11:03 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 01 Feb 2000 11:11:03 -0500 Subject: [Python-Dev] Proposal: Registry access for Python on Windows In-Reply-To: Your message of "Tue, 01 Feb 2000 16:35:17 +0100." <02a501bf6cc9$f1681620$4500a8c0@thomasnotebook> References: <02a501bf6cc9$f1681620$4500a8c0@thomasnotebook> Message-ID: <200002011611.LAA18829@eric.cnri.reston.va.us> > I propose to include functions to access the windows registry > into the python 1.6 core. > > I have thrown together some code which I will post hopefully > tomorrow, but I would like to hear some comments before. > > ---------------------------------------------------------------------- > winreg - registry access module > > Constants: > HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, > HKEY_USERS - bases of registry > KEY_READ, KEY_WRITE, KEY_ALL_ACCESS - access rights > REG_SZ, REG_DWORD, REG_BINARY - typecodes for values > > Exception: > error - raised when a function fails. Will usually contain > a windows error code and a textual description. > > Functions: > OpenKey (base, subkey, [, rights=KEY_READ]) -> integer > Opens an existing key with the specified access rights > and returns an integer handle. The handle must be closed > by a call to CloseKey(). > > CreateKey (base, subkey [, sam=KEY_ALL_ACCESS]) -> integer > Creates a new subkey or opens an exsiting one > and returns an integer handle. > base must be one of the HKEY_ constants or an integer handle. > The handle must be closed by a call to CloseKey(). > > CloseKey (handle) > Closes a key handle. > > EnumValues (handle, subkey) -> sequence > Returns a sequence containing name, value, typecode triples > for each existing value. > > EnumKeys (handle, subkey) -> sequence > Returns a sequence containing the names of all subkeys. > > QueryValue (handle, subkey) -> tuple > Returns a tuple containing name, value and typecode. > > SetValue (handle, name, typecode, value) > Sets the value of a name to value. > value must be a string for REG_SZ or REG_BINARY, > an integer for REG_DWORD. > > DeleteValue (handle, valuename) > Deletes the value. > > DeleteKey (handle, name [,recursive=0) > Deletes the named key if no subkeys exist. If recursive is > given as a true value, subkeys are recursively deleted. > This is done with Reg* calls, NOT with SHDeleteKey and > SHDeleteEmptyKey functions, so should work under any > flavor of NT and Win9x. > > Note: To use the SetValue and Delete* functions, the key must have > been opened with KEY_WRITE_ACCESS or KEY_ALL_ACCESS. > ---------------------------------------------------------------------- > Open Questions: > Is the recursive-flag for DeleteKey() too dangerous? > Should I switch from an integer handle to a full blown > python-object, which would call CloseKey() automatically in the > destructor? > A higher level interface would be nice, but this should probably > implemented > on top of this module in python. > > Comments appreciated! As long as we're redesigning the API and not just copying the registry access functions fromn win32api, shouldn't this be made a little bit more OO? Things that return a handle should return an object, and things taking a handle should be methods of that object. Also, the structured return values should probably be turned into objects with attributes. It might be acceptable to do this as a Python wrapper; in that case perhaps the C module should be called _winreg. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@acm.org Tue Feb 1 16:42:44 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 1 Feb 2000 11:42:44 -0500 (EST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: References: Message-ID: <14487.3332.466772.754653@weyr.cnri.reston.va.us> Greg Stein writes: > p.s. I'm against a ternary operator. use an if/else statement. use > def instead of lambda (lambda is the only rational basis given so far to > add the operator, but it is bogus to start with) Actually, the places I'd use it most would be probably be in constructing parameters to string formatting operations. Grepping back in my memory, that's usually where I've wanted it. I very rarely use lambda, and usually change it on the next iteration on those cases when I do. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From gmcm@hypernet.com Tue Feb 1 16:46:36 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 1 Feb 2000 11:46:36 -0500 Subject: [Python-Dev] Proposal: Registry access for Python on Windows In-Reply-To: <02a501bf6cc9$f1681620$4500a8c0@thomasnotebook> Message-ID: <1262698908-4003053@hypernet.com> Thomas Heller wrote: > I propose to include functions to access the windows registry > into the python 1.6 core. > > I have thrown together some code which I will post hopefully > tomorrow, but I would like to hear some comments before. [snip API - which appears to be a fairly low level wrap] > Open Questions: > Is the recursive-flag for DeleteKey() too dangerous? As long as it defaults to non-recursive, it's fine by me. > Should I switch from an integer handle to a full blown > python-object, which would call CloseKey() automatically in the > destructor? Absodefiposilutely Yes. Not so sure you need typecode. There are 10 types defined, but most tools only do 3 (string, dword and binary) and most usage is of 2 (dword and string - which can hold binary data). So I'd think you could infer pretty safely. Actually, I guess this boils down to intent - "Python as a complete registry tool" would require all the types, but "Python can use the registry" could automatically use dword or string, as appropriate. - Gordon From gmcm@hypernet.com Tue Feb 1 16:53:30 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 1 Feb 2000 11:53:30 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <14487.3332.466772.754653@weyr.cnri.reston.va.us> References: Message-ID: <1262698493-4028008@hypernet.com> Fred L. Drake, Jr. writes: > Greg Stein writes: > > p.s. I'm against a ternary operator. use an if/else statement. use > > def instead of lambda (lambda is the only rational basis given so far to > > add the operator, but it is bogus to start with) > > Actually, the places I'd use it most would be probably be in > constructing parameters to string formatting operations. Grepping > back in my memory, that's usually where I've wanted it. Boy does that ring a big bell. Was ambivalent, now I'm all for it (either C syntax or "then" syntax, don't care). > I very rarely use lambda, and usually change it on the next > iteration on those cases when I do. Use them mostly in GUIs where no smarts are required. - Gordon From tismer@tismer.com Tue Feb 1 17:22:15 2000 From: tismer@tismer.com (Christian Tismer) Date: Tue, 01 Feb 2000 18:22:15 +0100 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? References: <1262698493-4028008@hypernet.com> Message-ID: <38971647.D03FC543@tismer.com> Gordon McMillan wrote: > > Fred L. Drake, Jr. writes: > > Greg Stein writes: > > > p.s. I'm against a ternary operator. use an if/else statement. use > > > def instead of lambda (lambda is the only rational basis given so far to > > > add the operator, but it is bogus to start with) > > > > Actually, the places I'd use it most would be probably be in > > constructing parameters to string formatting operations. Grepping > > back in my memory, that's usually where I've wanted it. > > Boy does that ring a big bell. Was ambivalent, now I'm all for it > (either C syntax or "then" syntax, don't care). So am I! Conditional expressions make very much sense for constructing objects on-the-fly. It is quite common to denote tuples, lists and dicts directly in Python code, like so: mapping_table = { 1: "one", 2: "two", } and so on. To parameterise them, we can either use different tables embedded in an if, or use an expression inside the denotation: language = 1 mapping_table = { 1: ("one", "eins")[language], 2: ("two", "zwei")[language], } but with expressions, we get to mapping_table = { 1: language == 0 ? "one" : "eins", 2: language == 0 ? "two" : "zwei", } Well, maybe I had better chosen a different example, since the language example looks better with indexing here. How would we spell an elif? Would we at all? # languages: 0 - English 1 - German 2 - Finnish mapping_table = { 1: language == 0 ? "one" : language == 1 ? "eins", "yksi", 2: language == 0 ? "two" : language == 2 ? "zwei", "kaksi", 3: language == 0 ? "three" : language == 2 ? "drei", "kolme", } (yes the zero slot is missing - forgot what that is in Finnish:) Would conditionals also be valid on the LHS of assignments? target ? a : b = language ? "one" : "eins" grmbl - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Düppelstr. 31 : *Starship* http://starship.python.net 12163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From Moshe Zadka Tue Feb 1 19:59:27 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 1 Feb 2000 21:59:27 +0200 (IST) Subject: [Python-Dev] __contains__ hook Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-851401618-949435167=:17780 Content-Type: TEXT/PLAIN; charset=US-ASCII Here's a very preliminary, very hackish version of a hook for the "in" operator. Basically, use like: class spam: def __contains__(self, o): return 1 6 in spam() (answers 1) I must say I was horrified by the current way the operator was handled: very non-OO-ish. I'd much rather there'd be a slot in the sequence interface for this method. This is why there's still no way to use the hook with regular C extension types. Have fun! (BTW: I've tested it only minimally, so it might break your Python. Use with caution). PS. Eric, you can implement sets the *right* way this time. -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. ---559023410-851401618-949435167=:17780 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=1 Content-ID: Content-Description: Content-Transfer-Encoding: BASE64 KioqIC4uLy4uLy4uL3B5dGhvbi9kaXN0L3NyYy9PYmplY3RzL2Fic3RyYWN0 LmMJRnJpIE9jdCAxNSAxNDowOTowMiAxOTk5DQotLS0gT2JqZWN0cy9hYnN0 cmFjdC5jCVR1ZSBGZWIgIDEgMTA6MzQ6MzQgMjAwMA0KKioqKioqKioqKioq KioqDQoqKiogMTExMCwxMTE1ICoqKioNCi0tLSAxMTEwLDExNDAgLS0tLQ0K ICAJCX0NCiAgCQlyZXR1cm4gMDsNCiAgCX0NCisgCS8qIHNwZWNpYWwgY2Fz ZSBmb3IgaW5zdGFuY2VzLiBCYXNpY2FsbHkgZW11bGF0aW5nIFB5dGhvbiBj b2RlLA0KKyAJICAgYnV0IG9wdGltaXphdGlvbnMgd2lsbCBjb21lIGxhdGVy ICovDQorIAlpZiAoUHlJbnN0YW5jZV9DaGVjayh3KSkgew0KKyAJCVB5T2Jq ZWN0ICpweV9fY29udGFpbnNfXywgKnB5X3JldCwgKnB5X2FyZ3M7DQorIAkJ aW50IHJldDsNCisgDQorIAkJcHlfX2NvbnRhaW5zX18gPSBQeU9iamVjdF9H ZXRBdHRyU3RyaW5nKHcsICJfX2NvbnRhaW5zX18iKTsNCisgCQlpZihweV9f Y29udGFpbnNfXyA9PSBOVUxMKSANCisgCQkJcmV0dXJuIC0xOw0KKyAJCXB5 X2FyZ3MgPSBQeVR1cGxlX05ldygxKTsNCisgCQlpZihweV9hcmdzID09IE5V TEwpIHsNCisgCQkJUHlfREVDUkVGKHB5X19jb250YWluc19fKTsNCisgCQkJ cmV0dXJuIC0xOw0KKyAJCX0NCisgCQlQeV9JTkNSRUYodik7DQorIAkJUHlU dXBsZV9TRVRfSVRFTShweV9hcmdzLCAwLCB2KTsNCisgCQlweV9yZXQgPSBQ eU9iamVjdF9DYWxsT2JqZWN0KHB5X19jb250YWluc19fLCBweV9hcmdzKTsN CisgCQlQeV9ERUNSRUYocHlfX2NvbnRhaW5zX18pOw0KKyAJCVB5X0RFQ1JF RihweV9hcmdzKTsNCisgCQlpZihweV9yZXQgPT0gTlVMTCkgDQorIAkJCXJl dHVybiAtMTsNCisgCQlyZXQgPSBQeU9iamVjdF9Jc1RydWUocHlfcmV0KTsN CisgCQlQeV9ERUNSRUYocHlfYXJncyk7DQorIAkJcmV0dXJuIHJldDsNCisg CX0NCiAgDQogIAlzcSA9IHctPm9iX3R5cGUtPnRwX2FzX3NlcXVlbmNlOw0K ICAJaWYgKHNxID09IE5VTEwgfHwgc3EtPnNxX2l0ZW0gPT0gTlVMTCkgew0K ---559023410-851401618-949435167=:17780-- From tim_one@email.msn.com Wed Feb 2 07:35:02 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 2 Feb 2000 02:35:02 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: Message-ID: <000601bf6d50$0424e000$28a0143f@tim> [Greg Wilson] > (Footnote: check out David Scanlan's article in the Sept. 1989 issue of > "IEEE Software". Turns out that flowcharts are actually more readable > than pseudocode --- the research that claimed to show otherwise was > biased by (among other things) comparing structured pseudocode with > spaghetti flowcharts... One li'l bit of sloppy science, and the world > turns its back on something useful...) Oh, I don't know -- "visual programming" systems keep getting reinvented, so I doubt they'll be lost to us forever: executable flowcharts are at least as sensible as executable pseudocode (which latter Python partly aimed for). I'm old enough that I actually suffered many textbooks that used flowcharts. As I recall, they were absolutely worthless -- and in reviewing a few of them just now, I see that this assessment was far too generous . Lines crossing willy-nilly, dozens of single- and two(!)-letter "off page connectors", ... yikes! If the study used spaghetti flowcharts, I expect they used what was simply common practice at the time. I have seen a few good flowcharts, though, and they were cool. How about a "folding" graphical editor, so we could find & expand the logic levels of particular interest without losing the big picture ... oops-just-realized-this-has-nothing-to-do-with-1.6 -ly y'rs - tim From tim_one@email.msn.com Wed Feb 2 07:35:04 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 2 Feb 2000 02:35:04 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <200002011337.IAA18548@eric.cnri.reston.va.us> Message-ID: <000701bf6d50$05624200$28a0143f@tim> [Tim, makes a huge production over Guido's supposed intractability on the issue of new keywords] [Guido] > Hm, I was just thinking that 'then' wouldn't be the hardest keyword to > add... Man, you *are* Unfathomable <0.9 wink>! Even if true, you should never have admitted to it <0.1 wink>. > But I should probably stick with Tim's suggestion. Tim would. [Ping] >> Another issue with the last suggestion: how do you explain putting a >> colon after the condition but not after the "else"? > Whoever proposed that was terribly confused. That was me. It was just brainstorming, so you wouldn't have to . i-disowned-it-in-the-same-paragraph-i-introduced-it-but- all-ideas-take-on-a-hideous-life-of-their-own-ly y'rs - tim From ping@lfw.org Wed Feb 2 11:19:11 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 2 Feb 2000 06:19:11 -0500 (EST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <200002011337.IAA18548@eric.cnri.reston.va.us> Message-ID: On Tue, 1 Feb 2000, Guido van Rossum wrote: > > Hm, I was just thinking that 'then' wouldn't be the hardest keyword to > add... But I should probably stick with Tim's suggestion. Wow, maybe i shouldn't have given in so fast. Oh, well. :) -- ?!ng From Vladimir.Marangozov@inrialpes.fr Wed Feb 2 11:30:51 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 2 Feb 2000 12:30:51 +0100 (CET) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <200001301332.IAA12252@eric.cnri.reston.va.us> from "Guido van Rossum" at Jan 30, 2000 08:32:18 AM Message-ID: <200002021130.MAA07517@python.inrialpes.fr> Guido van Rossum wrote: > > Dear developers, > > Eric Raymond has sent me the following patch, which adds conditional > expressions to Python. I'd like to hear opinions on whether this is a > good thing to add to Python, and whether this is the right syntax. > Although Eric's patch is cute, I think this language shortcut is unnecessary for Python. I'd support a do/while shortcut though ;-) It's more popular and would fit "naturally" into the language for most programmers. Overall, it seems to me that the next major version of Python needs to be cleaned, instead of being enriched. Both the language and the internals. We have enough experience already for moving in this direction. (I'm not speaking about new packages/libs or additional core facilities, like Unicode, that need to integrated). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gvwilson@nevex.com Wed Feb 2 13:26:31 2000 From: gvwilson@nevex.com (gvwilson@nevex.com) Date: Wed, 2 Feb 2000 08:26:31 -0500 (EST) Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <000701bf6d50$05624200$28a0143f@tim> Message-ID: > [Tim] > Man, you *are* Unfathomable <0.9 wink>! Even if true, you should > never have admitted to it <0.1 wink>. I think that's supposed to be , isn't it? Greg From fredrik@pythonware.com Wed Feb 2 13:56:40 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 2 Feb 2000 14:56:40 +0100 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? References: Message-ID: <00d901bf6d85$5577dd60$f29b12c2@secret.pythonware.com> Greg Wilson wrote: > > [Tim] > > Man, you *are* Unfathomable <0.9 wink>! Even if true, you should > > never have admitted to it <0.1 wink>. >=20 > I think that's supposed to be , isn't it? not in this case. quoting a leading bot implementor: "We did requirements and task analysis, iterative design, and user testing. You'd almost think emails were an interface between people and bots." and I can assure you that proving that human beings don't like weird but formally well designed syntaxes was the easy part of that project... (but don't tell the schemers ;-) "Larry Wall should be shot. Along with Bill Joy and Eric Allman." -- Daniel Finster, on comp.lang.lisp "Why, just because you guys frittered away a 20-year headstart?" -- Larry Wall From Vladimir.Marangozov@inrialpes.fr Wed Feb 2 14:19:43 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 2 Feb 2000 15:19:43 +0100 (CET) Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <200001210129.UAA28292@eric.cnri.reston.va.us> from "Guido van Rossum" at Jan 20, 2000 08:29:30 PM Message-ID: <200002021419.PAA07712@python.inrialpes.fr> Guido van Rossum wrote: > > As an experiment, I've collected about 40 messages with suggested > patches in them that I found in my inbox; the oldest are nearly two > years old. > > You can access these from this address: > > http://www.python.org/~guido/patch/ > > I would love any help I could get in responding with these, and taking > action in the form of patches. Is this just for the sake of the experiment or this patch selection is the one you really haven't had the time to deal with? I see a couple of patches proposing GC implementations (a very delicate issue) of which only half a single patch would be acceptable for now (the one renaming malloc to PyMem_Malloc). There's one message (No 8) suggesting modifications to README and to the python.org Web page. How can we help with that? I have problems understanding two patches submitted by Gerrit Holl. They mention "Hallo Guido". :-) > I propose that if you decide that a particular patch is worth checking > in, you ask the author for the bugrelease or wetsign disclaimer and let > me know that I can check it in; if changes to the patch are needed, > I propose that you negotiate these with the author first. Understood. Sharing your collection of suggested patches definitely increases your chances to get some help and answer the authors in time! -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@CNRI.Reston.VA.US Wed Feb 2 14:23:03 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 09:23:03 -0500 Subject: [Python-Dev] Python 1.6 timing In-Reply-To: Your message of "Wed, 02 Feb 2000 15:19:43 +0100." <200002021419.PAA07712@python.inrialpes.fr> References: <200002021419.PAA07712@python.inrialpes.fr> Message-ID: <200002021423.JAA21511@eric.cnri.reston.va.us> > > http://www.python.org/~guido/patch/ > > > > I would love any help I could get in responding with these, and taking > > action in the form of patches. > > Is this just for the sake of the experiment or this patch selection > is the one you really haven't had the time to deal with? These are ones that I really haven't had the time to deal with (witness the dates on some). > I see a couple of patches proposing GC implementations (a very delicate > issue) of which only half a single patch would be acceptable for now > (the one renaming malloc to PyMem_Malloc). Maybe you can help me formulate a reply? I guess the patch collection isn't just about patches -- it's about the general level of effort that some patches require. I just don't feel comfortable with saying "no" without a good reason, and "no time" isn't a good enough reason. So I welcome any form of comments on these patch proposals. > There's one message (No 8) suggesting modifications to README and to the > python.org Web page. How can we help with that? The README is checked into the CVS. For the web page I will gladly accept patches to the HTML. > I have problems understanding two patches submitted by Gerrit Holl. > They mention "Hallo Guido". :-) Oops, sorry. The first one is proposing a validate() function for pathnames. In the second one, the patch code speaks for itself -- it makes an exception class conform to the rule that exceptions must inherit from Exception. > > I propose that if you decide that a particular patch is worth checking > > in, you ask the author for the bugrelease or wetsign disclaimer and let > > me know that I can check it in; if changes to the patch are needed, > > I propose that you negotiate these with the author first. > > Understood. > > Sharing your collection of suggested patches definitely increases > your chances to get some help and answer the authors in time! Thanks. Apart from Tim Peters who immediately tackled a typo in the FAQ, no-one else has offered any help with these. I'm glad that you've at least taken the time to look at them. I'm still being inundated with patches... But as long as this experiment hasn't shown more success I will keep them in my inbox. Or is there a better idea? Should I forward all patches I get to python-dev? To a separate list? --Guido van Rossum (home page: http://www.python.org/~guido/) From Vladimir.Marangozov@inrialpes.fr Wed Feb 2 15:54:13 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 2 Feb 2000 16:54:13 +0100 (CET) Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <200002021423.JAA21511@eric.cnri.reston.va.us> from "Guido van Rossum" at Feb 02, 2000 09:23:03 AM Message-ID: <200002021554.QAA07902@python.inrialpes.fr> Guido van Rossum wrote: > > I guess the patch collection isn't just about patches -- it's about > the general level of effort that some patches require. I just don't > feel comfortable with saying "no" without a good reason, and "no time" > isn't a good enough reason. So I welcome any form of comments on > these patch proposals. Understood. > > Or is there a better idea? Should I forward all patches I get to > python-dev? Certainly not. This isn't the purpose of the list, except maybe if a patch is too fundamental to be just a patch. :-) > To a separate list? This would be fine. A public list discussing all submitted patches would be helpful. There are some patches that require routine testing that few people here would find the time to perform. Others require "critical mass" of opinions to be adopted, rejected or deferred. Maybe we could set the gross operation mode of such a list as follows: You publish systematically all patches (except those that get checked in directly) The discussion focuses patches submitted during the past month. Some of them are accepted, some are rejected, many are "deferred" (for various reasons). Deferred patches are those that have an undecided future and get archived. In this case, a mail notification is sent to the author explaining the situation. If the author thinks the patch is worthy and "decidable", s/he has to resubmit the patch for reviving the discussion on the list and for trying to gain more proponents/favorable opinions. (because the list is discussing 1 month old patches only). If the author pushes real hard, either a decision would be taken, either s/he will end up convinced that the patch is "undecidable" for the time being :-). Besides, all serious patchers would become members of this list, which isn't so bad (given that presently, you're the only contact person for patch related material/submissions and you're mainly discussing a subset of the submissions, one-by-one, with the authors in person). This operation mode would ensure that the "light" patches, mostly the various bug fixes, will end up with a decision. The "hard" ones, those that introduce new functionality or behavior, will be seriously discussed and will eventually end up deferred (and archived) for future consideration. Thus, the archive would constitute yet another "memory" of the development process, accessible to all interested parties. This forum, like python-dev, would have a consultative mission, preserving your decision rights, so it's something you'd probably want to try (provided that you fix the rules of the game at its creation). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@CNRI.Reston.VA.US Wed Feb 2 16:35:03 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 11:35:03 -0500 Subject: [Python-Dev] __contains__ hook In-Reply-To: Your message of "Tue, 01 Feb 2000 21:59:27 +0200." References: Message-ID: <200002021635.LAA22671@eric.cnri.reston.va.us> Moshe seems eager to get comments on this post :-) > Here's a very preliminary, very hackish version of a hook for the "in" > operator. > > Basically, use like: > > class spam: > def __contains__(self, o): > return 1 > 6 in spam() (answers 1) > > I must say I was horrified by the current way the operator was handled: > very non-OO-ish. I'd much rather there'd be a slot in the sequence > interface for this method. This is why there's still no way to use the > hook with regular C extension types. > > Have fun! > > (BTW: I've tested it only minimally, so it might break your Python. Use > with caution). > > PS. > Eric, you can implement sets the *right* way this time. For those who, like me, are too lazy to unpack attachments, here's the text of Moshe's patch: > *** ../../../python/dist/src/Objects/abstract.c Fri Oct 15 14:09:02 1999 > --- Objects/abstract.c Tue Feb 1 10:34:34 2000 > *************** > *** 1110,1115 **** > --- 1110,1140 ---- > } > return 0; > } > + /* special case for instances. Basically emulating Python code, > + but optimizations will come later */ > + if (PyInstance_Check(w)) { > + PyObject *py__contains__, *py_ret, *py_args; > + int ret; > + > + py__contains__ = PyObject_GetAttrString(w, "__contains__"); > + if(py__contains__ == NULL) > + return -1; > + py_args = PyTuple_New(1); > + if(py_args == NULL) { > + Py_DECREF(py__contains__); > + return -1; > + } > + Py_INCREF(v); > + PyTuple_SET_ITEM(py_args, 0, v); > + py_ret = PyObject_CallObject(py__contains__, py_args); > + Py_DECREF(py__contains__); > + Py_DECREF(py_args); > + if(py_ret == NULL) > + return -1; > + ret = PyObject_IsTrue(py_ret); > + Py_DECREF(py_args); > + return ret; > + } > > sq = w->ob_type->tp_as_sequence; > if (sq == NULL || sq->sq_item == NULL) { I like the idea of overloading 'in' (and 'not in') with __contains__. There are several issues with this patch though (apart from the fact that he left out the disclaimer from http://www.python.org/1.5/bugrelease.html :-). First of all, it actually breaks 'in' for descendants of UserList, and other classes that define __getitem__ but not __contains__. That's easily fixed by clearing the error and jumping forward instead of returning an error when the GetAttrString() call fails. Second, it's customary to define a static object variable initialized to NULL, which is set to the interned string object; this speeds up the lookup a bit using PyObject_GetAttr(). Micro-nit: I want a space between 'if' and '('. It just looks better. But the real issue is what Moshe himself already brings up: contains should have a slot in the type struct, so extension types can also define this. Moshe, do you feel like doing this right? --Guido van Rossum (home page: http://www.python.org/~guido/) From gward@cnri.reston.va.us Wed Feb 2 16:44:48 2000 From: gward@cnri.reston.va.us (Greg Ward) Date: Wed, 2 Feb 2000 11:44:48 -0500 Subject: [Python-Dev] __contains__ hook In-Reply-To: <200002021635.LAA22671@eric.cnri.reston.va.us>; from guido@cnri.reston.va.us on Wed, Feb 02, 2000 at 11:35:03AM -0500 References: <200002021635.LAA22671@eric.cnri.reston.va.us> Message-ID: <20000202114447.A18515@cnri.reston.va.us> On 02 February 2000, Guido van Rossum said: > I like the idea of overloading 'in' (and 'not in') with __contains__. > There are several issues with this patch though (apart from the fact > that he left out the disclaimer from > http://www.python.org/1.5/bugrelease.html :-). I agree at a language level; the current way to "overload" 'in' is... ummm... weird. It seems like there's a a simple and natural "magic method" corresponding to almost every operator, so any operators that *don't* get that treatment are second-class citizens. As for the implementation of __contains__, I'm just not familiar enough with Python internals to comment. I'll let the rest of you argue over that. Greg From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Feb 2 16:56:43 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 2 Feb 2000 11:56:43 -0500 (EST) Subject: [Python-Dev] Python 1.6 timing References: <200002021419.PAA07712@python.inrialpes.fr> <200002021423.JAA21511@eric.cnri.reston.va.us> Message-ID: <14488.25035.985792.589165@anthem.cnri.reston.va.us> >>>>> "Guido" == Guido van Rossum writes: Guido> The README is checked into the CVS. For the web page I Guido> will gladly accept patches to the HTML. I'm willing to put the entire python.org web site under CVS. This would at least make it easier for others to send us patches to the .ht files against the latest revisions. Is there any interest in this? It wouldn't take me long. Guido> Or is there a better idea? Should I forward all patches I Guido> get to python-dev? To a separate list? Probably a separate list. xemacs.org runs a xemacs-patches mailing list with a replybot on it that scans for patches. It sends back a different response based on whether it finds a patch or not. Then there's a group of lieutenants that keep an eye on the patches and work out their applicability. We could set something like that up fairly easily. -Barry From guido@CNRI.Reston.VA.US Wed Feb 2 17:00:47 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 12:00:47 -0500 Subject: [Python-Dev] Python 1.6 timing In-Reply-To: Your message of "Wed, 02 Feb 2000 11:56:43 EST." <14488.25035.985792.589165@anthem.cnri.reston.va.us> References: <200002021419.PAA07712@python.inrialpes.fr> <200002021423.JAA21511@eric.cnri.reston.va.us> <14488.25035.985792.589165@anthem.cnri.reston.va.us> Message-ID: <200002021700.MAA22997@eric.cnri.reston.va.us> > Guido> Or is there a better idea? Should I forward all patches I > Guido> get to python-dev? To a separate list? > > Probably a separate list. xemacs.org runs a xemacs-patches mailing > list with a replybot on it that scans for patches. It sends back a > different response based on whether it finds a patch or not. Then > there's a group of lieutenants that keep an eye on the patches and > work out their applicability. We could set something like that up > fairly easily. This sounds like a useful idea. It should also check for the disclaimer text and send an appropriate apply if a patch is found without a disclaimer. Of course, the replybot would need to be smart enough to find things like patches hiding in BASE64-encoded attachments... On the other hand, perhaps it would be better to deal with patches the same way as with bug reports -- the Jitterbug database isn't perfect, but it makes it possible to check regularly whether something has been dealt with or not, much better than a simple mailing list. (There are already lieutenants scanning the bugs traffic, so that part doesn't change.) --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@acm.org Wed Feb 2 17:27:42 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 2 Feb 2000 12:27:42 -0500 (EST) Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <200002021423.JAA21511@eric.cnri.reston.va.us> References: <200002021419.PAA07712@python.inrialpes.fr> <200002021423.JAA21511@eric.cnri.reston.va.us> Message-ID: <14488.26894.735522.942609@weyr.cnri.reston.va.us> Guido van Rossum writes: > Oops, sorry. The first one is proposing a validate() function for > pathnames. In the second one, the patch code speaks for itself -- it I did have a thought on this, but hadn't gotten back to it. Essentially, I'm not sure how to implement this correctly; things like MAXPATHLEN aren't always easy to root out the "right" way to get the *real* definition from C. pathconf(_PC_PATH_MAX) could be used to get that, and pathconf(_PC_NAME_MAX) can get the maximum length of an individual name within the path, but I don't know if the concepts are even meaningful on all systems. I wouldn't be surprised if validity on some systems is highly specific to the actual filesystem that's being referred to, and that requires the name be valid on the local system. I've noticed that the functions in the os.path implementations fall into two categories: "abstract" functions like join(), split(), and the like, which are bound to the "path algebra" syntax rules, and the "local-access" functions like isfile() and abspath(), which require the paths relate to the local system. This isn't a problem, but something we should probably keep in mind. > makes an exception class conform to the rule that exceptions must > inherit from Exception. I don't think this is valuable for 1.6, but might be interesting for 1.7; the documentation can include a notice that this relationship will be required in the future. That would allow people to define exceptions with the required inheritance before the last minute. On the other hand, I'm not sure it really matters that exceptions inherit from a specific base class. *That* seems unnecessary. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From Moshe Zadka Wed Feb 2 18:37:15 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 2 Feb 2000 20:37:15 +0200 (IST) Subject: [Python-Dev] __contains__ hook In-Reply-To: <200002021635.LAA22671@eric.cnri.reston.va.us> Message-ID: On Wed, 2 Feb 2000, Guido van Rossum wrote: > I like the idea of overloading 'in' (and 'not in') with __contains__. > There are several issues with this patch though (apart from the fact > that he left out the disclaimer from > http://www.python.org/1.5/bugrelease.html :-). Sorry: I'd d/l it and mail it later... > Micro-nit: I want a space between 'if' and '('. It just looks better. Sorry: old habits die hard. Change as you will. > But the real issue is what Moshe himself already brings up: contains > should have a slot in the type struct, so extension types can also > define this. > > Moshe, do you feel like doing this right? Yes, but not in the near future. Wouldn't adding a new slot break old extension types? I'm a bit ignorant on the subject -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From guido@CNRI.Reston.VA.US Wed Feb 2 18:49:54 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 13:49:54 -0500 Subject: [Python-Dev] __contains__ hook In-Reply-To: Your message of "Wed, 02 Feb 2000 20:37:15 +0200." References: Message-ID: <200002021849.NAA23092@eric.cnri.reston.va.us> > > But the real issue is what Moshe himself already brings up: contains > > should have a slot in the type struct, so extension types can also > > define this. > > > > Moshe, do you feel like doing this right? > > Yes, but not in the near future. Wouldn't adding a new slot break old > extension types? I'm a bit ignorant on the subject There are some spare slots in PyTypeObject: /* More spares */ long tp_xxx5; long tp_xxx6; long tp_xxx7; long tp_xxx8; These can be used for binary compatibility; old extensions will simply not have the new feature. There's also a more sophisticated feature, implemented through tp_flags, which can indicate that an extension is aware of a particular feature. These comments in object.h may explain this: /* Type flags (tp_flags) These flags are used to extend the type structure in a backwards-compatible fashion. Extensions can use the flags to indicate (and test) when a given type structure contains a new feature. The Python core will use these when introducing new functionality between major revisions (to avoid mid-version changes in the PYTHON_API_VERSION). Arbitration of the flag bit positions will need to be coordinated among all extension writers who publically release their extensions (this will be fewer than you might expect!).. Python 1.5.2 introduced the bf_getcharbuffer slot into PyBufferProcs. Type definitions should use Py_TPFLAGS_DEFAULT for their tp_flags value. Code can use PyType_HasFeature(type_ob, flag_value) to test whether the given type object has a specified feature. */ --Guido van Rossum (home page: http://www.python.org/~guido/) From Moshe Zadka Wed Feb 2 19:03:45 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 2 Feb 2000 21:03:45 +0200 (IST) Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <14488.25035.985792.589165@anthem.cnri.reston.va.us> Message-ID: On Wed, 2 Feb 2000, Barry A. Warsaw wrote: > I'm willing to put the entire python.org web site under CVS. This > would at least make it easier for others to send us patches to the .ht > files against the latest revisions. Is there any interest in this? > It wouldn't take me long. Ummmm...would this be the wrong time to ask how the redesign contest is going on? > Probably a separate list. xemacs.org runs a xemacs-patches mailing > list with a replybot on it that scans for patches. It sends back a > different response based on whether it finds a patch or not. Then > there's a group of lieutenants that keep an eye on the patches and > work out their applicability. We could set something like that up > fairly easily. A definite aye vote, though perhaps that's an overkill. As long as we're comparing other Free Software projects, let me just note that on linux-kernel, patches are part of the regular discussion. Whoever feels like it, runs a modified kernel, and reports the result. Patches are then chosen (in part) by the responses of people who have tried them out -- a very good QA mechanism. Just to brainstorm about the process. -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From guido@CNRI.Reston.VA.US Wed Feb 2 19:07:07 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 14:07:07 -0500 Subject: [Python-Dev] Python 1.6 timing In-Reply-To: Your message of "Wed, 02 Feb 2000 12:27:42 EST." <14488.26894.735522.942609@weyr.cnri.reston.va.us> References: <200002021419.PAA07712@python.inrialpes.fr> <200002021423.JAA21511@eric.cnri.reston.va.us> <14488.26894.735522.942609@weyr.cnri.reston.va.us> Message-ID: <200002021907.OAA23326@eric.cnri.reston.va.us> > Guido van Rossum writes: > > Oops, sorry. The first one is proposing a validate() function for > > pathnames. In the second one, the patch code speaks for itself -- it > > I did have a thought on this, but hadn't gotten back to it. > Essentially, I'm not sure how to implement this correctly; things like > MAXPATHLEN aren't always easy to root out the "right" way to get the > *real* definition from C. pathconf(_PC_PATH_MAX) could be used to get > that, and pathconf(_PC_NAME_MAX) can get the maximum length of an > individual name within the path, but I don't know if the concepts are > even meaningful on all systems. I wouldn't be surprised if validity > on some systems is highly specific to the actual filesystem that's > being referred to, and that requires the name be valid on the local > system. I personally think there is very little merit in a validate() function -- it's not going to be a very useful predictor of whether an open may succeed or not. > I've noticed that the functions in the os.path implementations fall > into two categories: "abstract" functions like join(), split(), and > the like, which are bound to the "path algebra" syntax rules, and the > "local-access" functions like isfile() and abspath(), which require > the paths relate to the local system. This isn't a problem, but > something we should probably keep in mind. > > > makes an exception class conform to the rule that exceptions must > > inherit from Exception. > > I don't think this is valuable for 1.6, but might be interesting for > 1.7; the documentation can include a notice that this relationship > will be required in the future. That would allow people to define > exceptions with the required inheritance before the last minute. > On the other hand, I'm not sure it really matters that exceptions > inherit from a specific base class. *That* seems unnecessary. This is valuable mostly as an example; plus in that specific case I think he noticed that the module defines an exception class from scratch with functionality that is already present in the standard Exception class. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Wed Feb 2 19:12:57 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 14:12:57 -0500 Subject: [Python-Dev] Python 1.6 timing In-Reply-To: Your message of "Wed, 02 Feb 2000 21:03:45 +0200." References: Message-ID: <200002021912.OAA23362@eric.cnri.reston.va.us> > Ummmm...would this be the wrong time to ask how the redesign contest is > going on? I haven't seen any submissions. Maybe Barry has? > > Probably a separate list. xemacs.org runs a xemacs-patches mailing > > list with a replybot on it that scans for patches. It sends back a > > different response based on whether it finds a patch or not. Then > > there's a group of lieutenants that keep an eye on the patches and > > work out their applicability. We could set something like that up > > fairly easily. > > A definite aye vote, though perhaps that's an overkill. As long as we're > comparing other Free Software projects, let me just note that on > linux-kernel, patches are part of the regular discussion. Whoever feels > like it, runs a modified kernel, and reports the result. Patches are then > chosen (in part) by the responses of people who have tried them out -- a > very good QA mechanism. Just to brainstorm about the process. Good point. At the moment I am the sole arbiter for patches, and I'm tired of it. --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@cnri.reston.va.us Wed Feb 2 19:14:52 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 2 Feb 2000 14:14:52 -0500 (EST) Subject: [Python-Dev] Python 1.6 timing References: <14488.25035.985792.589165@anthem.cnri.reston.va.us> Message-ID: <14488.33324.334870.763850@anthem.cnri.reston.va.us> >>>>> "MZ" == Moshe Zadka writes: MZ> Ummmm...would this be the wrong time to ask how the redesign MZ> contest is going on? It isn't, AFAICT. I had two people come up to me at the conference and ask a few questions, with a promise to have something "soon". I had one other person email me a few weeks before the conference. But we've seen nothing, so I'm not very hopeful. MZ> A definite aye vote, though perhaps that's an overkill. As MZ> long as we're comparing other Free Software projects, let me MZ> just note that on linux-kernel, patches are part of the MZ> regular discussion. Whoever feels like it, runs a modified MZ> kernel, and reports the result. Patches are then chosen (in MZ> part) by the responses of people who have tried them out -- a MZ> very good QA mechanism. Just to brainstorm about the process. Mine's just one vote, but I really do not want to see patches floated on python-dev. -Barry From bwarsaw@CNRI.Reston.VA.US Wed Feb 2 19:17:30 2000 From: bwarsaw@CNRI.Reston.VA.US (bwarsaw@CNRI.Reston.VA.US) Date: Wed, 2 Feb 2000 14:17:30 -0500 (EST) Subject: [Python-Dev] Python 1.6 timing References: <200002021419.PAA07712@python.inrialpes.fr> <200002021423.JAA21511@eric.cnri.reston.va.us> <14488.25035.985792.589165@anthem.cnri.reston.va.us> <200002021700.MAA22997@eric.cnri.reston.va.us> Message-ID: <14488.33482.899746.619127@anthem.cnri.reston.va.us> >>>>> "Guido" == Guido van Rossum writes: Guido> This sounds like a useful idea. It should also check for Guido> the disclaimer text and send an appropriate apply if a Guido> patch is found without a disclaimer. Guido> Of course, the replybot would need to be smart enough to Guido> find things like patches hiding in BASE64-encoded Guido> attachments... Guido> On the other hand, perhaps it would be better to deal with Guido> patches the same way as with bug reports -- the Jitterbug Guido> database isn't perfect, but it makes it possible to check Guido> regularly whether something has been dealt with or not, Guido> much better than a simple mailing list. (There are already Guido> lieutenants scanning the bugs traffic, so that part doesn't Guido> change.) Maybe then just use Jitterbug to collate patches. That's what a lot of my JPython users do. -Barry From Moshe Zadka Wed Feb 2 19:28:33 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 2 Feb 2000 21:28:33 +0200 (IST) Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <14488.33324.334870.763850@anthem.cnri.reston.va.us> Message-ID: On Wed, 2 Feb 2000 bwarsaw@cnri.reston.va.us wrote: > Mine's just one vote, but I really do not want to see patches floated > on python-dev. How 'bout a seperate list with a Reply-To: python-dev? -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From bwarsaw@cnri.reston.va.us Wed Feb 2 21:56:41 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 2 Feb 2000 16:56:41 -0500 (EST) Subject: [Python-Dev] Python 1.6 timing References: <14488.33324.334870.763850@anthem.cnri.reston.va.us> Message-ID: <14488.43033.642829.483942@anthem.cnri.reston.va.us> >>>>> "MZ" == Moshe Zadka writes: MZ> On Wed, 2 Feb 2000 bwarsaw@cnri.reston.va.us wrote: >> Mine's just one vote, but I really do not want to see patches >> floated on python-dev. MZ> How 'bout a seperate list with a Reply-To: python-dev? That would work for me. I need to hack Mailman a little to add this feature, but it could be done. -Barry From fdrake@acm.org Wed Feb 2 22:14:58 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 2 Feb 2000 17:14:58 -0500 (EST) Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <200002021907.OAA23326@eric.cnri.reston.va.us> References: <200002021419.PAA07712@python.inrialpes.fr> <200002021423.JAA21511@eric.cnri.reston.va.us> <14488.26894.735522.942609@weyr.cnri.reston.va.us> <200002021907.OAA23326@eric.cnri.reston.va.us> Message-ID: <14488.44130.277594.651205@weyr.cnri.reston.va.us> Guido van Rossum writes: > I personally think there is very little merit in a validate() function > -- it's not going to be a very useful predictor of whether an open may > succeed or not. Agreed; I was not trying to push for the addition of the function but to point out that it is unlikely to be correct or meaningful. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From mhammond@skippinet.com.au Wed Feb 2 23:00:41 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 3 Feb 2000 10:00:41 +1100 Subject: [Python-Dev] Proposal: Registry access for Python on Windows In-Reply-To: <02a501bf6cc9$f1681620$4500a8c0@thomasnotebook> Message-ID: > I propose to include functions to access the windows registry > into the python 1.6 core. Agreed! > I have thrown together some code which I will post hopefully > tomorrow, but I would like to hear some comments before. > > ---------------------------------------------------------------------- > winreg - registry access module Im not convinced that we need either a) a new implementation, or b) a new API. I would propose that we use the existing registry access functions from win32api - as I didnt code them, Im not suggesting this due to my own ego. The reasons for my beliefs are: * The new API does not add any new value. The only changes I can see are that OpenKey() has had a reserved value dropped and QueryValue() has an extra redundant result. Indeed the new API does not appear a new API at all, so should be clearly stated if indeed it is (and in which case, exactly what the changes are) or be documented as a pythonic wrapping of the existing win32 registry API. Further, there is some useful functionality dropped. * Well tested. There are some obscure rules and code that experience has shown we need. It would be a shame to reinvent those wheels. It has taken a few years to get it "just right", and this was an implementation by people who know their stuff! Why not take the existing code as it stands (which _does_ include an auto-closing key) and add a new .py wrapper? At least Python will have a "complete, but low-level" registry API, and a higher level "easier to use, but maybe not complete" layer implemented in Python. Indeed, Guido has stated that the existing win32api functions would be suitable for the core. However, the issue is the "coding style" - and I admit that if I knew exectly what that meant I would make the change - eg, if it only means renaming the identifiers it would be trivial - however, it would also appear to be excessively anal, so Im sure there is more to it than that :-) And-I-think-I-will-stay-out-of-the-ternary-debate-ly, Mark. From guido@CNRI.Reston.VA.US Wed Feb 2 23:14:50 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 18:14:50 -0500 Subject: [Python-Dev] Proposal: Registry access for Python on Windows In-Reply-To: Your message of "Thu, 03 Feb 2000 10:00:41 +1100." References: Message-ID: <200002022314.SAA24664@eric.cnri.reston.va.us> > Im not convinced that we need either a) a new implementation, or b) a new > API. > > I would propose that we use the existing registry access functions from > win32api - as I didnt code them, Im not suggesting this due to my own ego. > The reasons for my beliefs are: > > * The new API does not add any new value. The only changes I can see are > that OpenKey() has had a reserved value dropped and QueryValue() has an > extra redundant result. Indeed the new API does not appear a new API at > all, so should be clearly stated if indeed it is (and in which case, exactly > what the changes are) or be documented as a pythonic wrapping of the > existing win32 registry API. Further, there is some useful functionality > dropped. > > * Well tested. There are some obscure rules and code that experience has > shown we need. It would be a shame to reinvent those wheels. It has taken > a few years to get it "just right", and this was an implementation by people > who know their stuff! > > Why not take the existing code as it stands (which _does_ include an > auto-closing key) and add a new .py wrapper? At least Python will have a > "complete, but low-level" registry API, and a higher level "easier to use, > but maybe not complete" layer implemented in Python. Sounds good to me. > Indeed, Guido has stated that the existing win32api functions would be > suitable for the core. However, the issue is the "coding style" - and I > admit that if I knew exectly what that meant I would make the change - eg, > if it only means renaming the identifiers it would be trivial - however, it > would also appear to be excessively anal, so Im sure there is more to it > than that :-) I only vaguely recollect what caused me to object against the coding style, but I think it was a lot of little things: // comments, lines longer than 78 chars, unusual indentation style. It was also somehow requiring C++ (everything in the core is plain C). I tried to do a style conversion myself, but found it very painful -- plus there were some dependencies on other files or modules that seemed to require me to pull in a lot of other things besides win32api.c. However, the registry functions are only a tiny piece of win32api -- they could probably be cut out of win32api and moved into something I would tentatively call win32reg (unless that's already an existing name), which could then be cleaned up much easier than all of win32api. I still think that it can be done, but evidently it takes someone besides me and Mark to do it. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond@skippinet.com.au Wed Feb 2 23:32:09 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 3 Feb 2000 10:32:09 +1100 Subject: [Python-Dev] Proposal: Registry access for Python on Windows In-Reply-To: <200002022314.SAA24664@eric.cnri.reston.va.us> Message-ID: > I only vaguely recollect what caused me to object against the coding > style, but I think it was a lot of little things: // comments, lines > longer than 78 chars, unusual indentation style. It was also somehow > requiring C++ (everything in the core is plain C). I tried to do a > style conversion myself, but found it very painful -- plus there were > some dependencies on other files or modules that seemed to require me > to pull in a lot of other things besides win32api.c. OK - that is a good enought list for me to get started. If no one else steps up within a week I will make an attempt at a module that meets these requirements.... Mark. From mal@lemburg.com Wed Feb 2 23:33:17 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 03 Feb 2000 00:33:17 +0100 Subject: [Python-Dev] __contains__ hook References: <200002021849.NAA23092@eric.cnri.reston.va.us> Message-ID: <3898BEBD.93DFBCA7@lemburg.com> Guido van Rossum wrote: > > > > But the real issue is what Moshe himself already brings up: contains > > > should have a slot in the type struct, so extension types can also > > > define this. > > > > > > Moshe, do you feel like doing this right? > > > > Yes, but not in the near future. Wouldn't adding a new slot break old > > extension types? I'm a bit ignorant on the subject > > There are some spare slots in PyTypeObject: > > /* More spares */ > long tp_xxx5; > long tp_xxx6; > long tp_xxx7; > long tp_xxx8; > > These can be used for binary compatibility; old extensions will simply > not have the new feature. > > There's also a more sophisticated feature, implemented through > tp_flags, which can indicate that an extension is aware of a > particular feature. These comments in object.h may explain this: > > /* > > Type flags (tp_flags) Shouldn't 'in' be a slot of the sequence methods ? I'd suggest creating a new tp_flag bit and then extending tp_as_sequence with: binaryfunc sq_contains; plus of course add an abstract function to abstract.c: PySequence_Contain(PyObject *container, PyObject *element) which uses the above slot after testing the tp_flag setting. Python instances, lists, tuples should then support this new slot. We could even sneak in support for dictionaries once we decide whether semantics whould be 1. key in dict 2. value in dict or 3. (key,value) in dict :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@CNRI.Reston.VA.US Wed Feb 2 23:49:34 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 18:49:34 -0500 Subject: [Python-Dev] __contains__ hook In-Reply-To: Your message of "Thu, 03 Feb 2000 00:33:17 +0100." <3898BEBD.93DFBCA7@lemburg.com> References: <200002021849.NAA23092@eric.cnri.reston.va.us> <3898BEBD.93DFBCA7@lemburg.com> Message-ID: <200002022349.SAA25030@eric.cnri.reston.va.us> > Shouldn't 'in' be a slot of the sequence methods ? I'd suggest > creating a new tp_flag bit and then extending tp_as_sequence > with: > > binaryfunc sq_contains; > > plus of course add an abstract function to abstract.c: > > PySequence_Contain(PyObject *container, PyObject *element) That function already exists, spelled "PySequence_Contains" (currently it does the C equivalent of for i in container: if element == i: return 1 return 0 I'm not entirely sure whether the 'contains' slot should be part of the as_sequence struct, but I suppose it makes sense historically. (The as_number, as_sequece, as_mapping structs don't make sense at all in the grand scheme of things, but we're stuck with them for the time being.) --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein@lyra.org Thu Feb 3 00:21:19 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 2 Feb 2000 16:21:19 -0800 (PST) Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <200002021423.JAA21511@eric.cnri.reston.va.us> Message-ID: On Wed, 2 Feb 2000, Guido van Rossum wrote: >... > > Sharing your collection of suggested patches definitely increases > > your chances to get some help and answer the authors in time! > > Thanks. Apart from Tim Peters who immediately tackled a typo in the > FAQ, no-one else has offered any help with these. I'm glad that > you've at least taken the time to look at them. I'm still being > inundated with patches... But as long as this experiment hasn't shown > more success I will keep them in my inbox. I looked through some of them, but (as I mentioned) would defer any real action until the April timeframe. At that point, I'd be more than happy to dig in and start handling them. Properly responding to them (in a group context) would probably need a bit of coordination infrustructure... > Or is there a better idea? Should I forward all patches I get to > python-dev? To a separate list? A new list. python-dev is very constructive in that it typically has one, maybe two or three, threads going at once. Throwing patches into the mix, and possibly unreasonable/unqualified patches, would seem to be quite a disruptive influence. The (smaller) list could be much more focused, and could hold just the truly active reviewers. People who are "just interested" could wait for the CVS checkin notices or become active :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Feb 3 00:31:41 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 2 Feb 2000 16:31:41 -0800 (PST) Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: <14488.33482.899746.619127@anthem.cnri.reston.va.us> Message-ID: On Wed, 2 Feb 2000 bwarsaw@CNRI.Reston.VA.US wrote: > >>>>> "Guido" == Guido van Rossum writes: >... > Guido> On the other hand, perhaps it would be better to deal with > Guido> patches the same way as with bug reports -- the Jitterbug > Guido> database isn't perfect, but it makes it possible to check > Guido> regularly whether something has been dealt with or not, > Guido> much better than a simple mailing list. (There are already > Guido> lieutenants scanning the bugs traffic, so that part doesn't > Guido> change.) > > Maybe then just use Jitterbug to collate patches. That's what a lot > of my JPython users do. Personally, I'm more comfortable knowing that I can email a patch (rather than dropping it into a bug db), and that will get handled by a human. The patch handlers could certainly use Jitterbug as arbitration, but I would think the list itself would make that reasonably clear. Note that "patches@python.org" could become THE place to submit patches. Sure, Guido would get some patches still, but some of the load will drop from his direct Inbox (yet he'd still get the patch as a subscriber). When the patch handlers had a "final" patch, it would get sent straight to Guido (with some "final" marker on it). etc etc. I'm sure there is a lot discussion that can take place on the exact mechanics. Until people will *volunteer*, I think the discussion of mechanics can be postponed. No need for a peanut gallery here :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Feb 3 00:35:20 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 2 Feb 2000 16:35:20 -0800 (PST) Subject: [Python-Dev] patches reply-to (was: Python 1.6 timing) In-Reply-To: <14488.43033.642829.483942@anthem.cnri.reston.va.us> Message-ID: On Wed, 2 Feb 2000 bwarsaw@cnri.reston.va.us wrote: > >>>>> "MZ" == Moshe Zadka writes: > MZ> On Wed, 2 Feb 2000 bwarsaw@cnri.reston.va.us wrote: > > >> Mine's just one vote, but I really do not want to see patches > >> floated on python-dev. > > MZ> How 'bout a seperate list with a Reply-To: python-dev? > > That would work for me. I need to hack Mailman a little to add this > feature, but it could be done. Note that I requested this feature for Mailman a while back. I'd like to use it for the "checkin" mailing lists that I run. Send to checkins, respond to the discussion list. Currently, my CVS automailer just inserts a Reply-To:, but it would be nice to have it directly on the mailing list itself. (view it more as a Followup-To: for mailers, rather than Reply-To munging) In this particular case, I think the "patches mailing list" would be a self-contained list discussing a *patch*. Sure, it could certainly migrate to python-dev when appropriate, but I think the majority of the discussion should stay on the patches list. Otherwise, we'd just be spamming the -dev list as if the patches list didn't exist. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Moshe Zadka Thu Feb 3 00:32:41 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 3 Feb 2000 02:32:41 +0200 (IST) Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: Message-ID: On Wed, 2 Feb 2000, Greg Stein wrote: > > Maybe then just use Jitterbug to collate patches. That's what a lot > > of my JPython users do. > Note that "patches@python.org" could become THE place to submit patches. OK, I want to know one thing: is everyone comfortable with my suggestion of a seperate list, with a reply-to: python-dev? Barry said he'd be willing to hack it in, and everyone who talked seemed like this idea is similar to what they have in mind. The sooner a consensus is reached, the less patches Guido will have to deal with. -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From gstein@lyra.org Thu Feb 3 00:42:57 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 2 Feb 2000 16:42:57 -0800 (PST) Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: Message-ID: On Thu, 3 Feb 2000, Moshe Zadka wrote: >... > OK, I want to know one thing: is everyone comfortable with my suggestion > of a seperate list, with a reply-to: python-dev? Barry said he'd be I don't advocate the reply-to (see my other email). > willing to hack it in, and everyone who talked seemed like this idea is > similar to what they have in mind. The sooner a consensus is reached, the > less patches Guido will have to deal with. It won't reduce his load unless we have actual volunteers that will truly do some handling of the patches. I'm assuming the current volunteer list is: - Guido (he volunteers whether he wants to or not :-) - Moshe (??) - Greg in April Others? Cheers, -g -- Greg Stein, http://www.lyra.org/ From Moshe Zadka Thu Feb 3 00:37:42 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 3 Feb 2000 02:37:42 +0200 (IST) Subject: [Python-Dev] patches reply-to (was: Python 1.6 timing) In-Reply-To: Message-ID: On Wed, 2 Feb 2000, Greg Stein wrote: > In this particular case, I think the "patches mailing list" would be a > self-contained list discussing a *patch*. Sure, it could certainly migrate > to python-dev when appropriate, but I think the majority of the discussion > should stay on the patches list. Otherwise, we'd just be spamming the -dev > list as if the patches list didn't exist. I retract my suggestion. Have python-patch, python-patch-discuss (python-patch would be replied-to: python-patch-discuss) and keep python-dev as a clean list. This way, people could just subscribe to python-patch, and when they get a patch they're interested in, they could subscribe to the discuss mailing list. That way, people could also subscribe to python-patch-discuss without subscribing to python-patch, to avoid the large attachments that would be sent by python-patch. Of course, mailman's new feature would automatically extract those attachments and post them up, so they can be downloaded by non-subscribers. enough-with-the-blabber-let's-just-get-something-going-ly y'rs, Z. -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From guido@CNRI.Reston.VA.US Thu Feb 3 00:45:56 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 19:45:56 -0500 Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: Your message of "Thu, 03 Feb 2000 02:32:41 +0200." References: Message-ID: <200002030045.TAA25323@eric.cnri.reston.va.us> > OK, I want to know one thing: is everyone comfortable with my suggestion > of a seperate list, with a reply-to: python-dev? Barry said he'd be > willing to hack it in, and everyone who talked seemed like this idea is > similar to what they have in mind. The sooner a consensus is reached, the > less patches Guido will have to deal with. Yes, let's do it. I actually think the reply-to is unnecessary to start (it's just a nicety). --Guido van Rossum (home page: http://www.python.org/~guido/) From Moshe Zadka Thu Feb 3 00:44:52 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 3 Feb 2000 02:44:52 +0200 (IST) Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: Message-ID: On Wed, 2 Feb 2000, Greg Stein wrote: > I'm assuming the current volunteer list is: > > - Guido (he volunteers whether he wants to or not :-) > - Moshe (??) Part time -- I'll take responsibility for the patches that interest me. There will likely be a few, and I *love* installing patches off the net, just to test my security measures <0.3 wink> > Others? I assume you'll get a similar response from many people: hopefully, for each patch it will either get booed automatically (hey! I just added braces instead of indentation to the parser) or will interest someone. -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From gstein@lyra.org Thu Feb 3 00:50:50 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 2 Feb 2000 16:50:50 -0800 (PST) Subject: [Python-Dev] patches reply-to In-Reply-To: Message-ID: On Thu, 3 Feb 2000, Moshe Zadka wrote: >... > I retract my suggestion. Have python-patch, python-patch-discuss > (python-patch would be replied-to: python-patch-discuss) and keep > python-dev as a clean list. This way, people could just subscribe to > python-patch, and when they get a patch they're interested in, they could > subscribe to the discuss mailing list. That way, people could also > subscribe to python-patch-discuss without subscribing to python-patch, to > avoid the large attachments that would be sent by python-patch. Of course, > mailman's new feature would automatically extract those attachments and > post them up, so they can be downloaded by non-subscribers. Guido/Barry can decide on the final structure, but I'd recommend something a bit different: 1) drop the python- prefix. These are @python.org 2) just have "patches@python.org" I'm assuming the mailing list would be Guido-approved and the people on it would be required to "deal with the patch size". I think an open list might generate some noise rather than just "work". But again: the structure is ultimately up to Guido. Oops. I see a post from Guido saying "let's do it." In that case, it is probably best to move this discussion to the new list. I believe we need a statement of subscription policy from Guido. Or at least something to the effect of "python-dev members are free to subscribe, but you are expected to directly/positively contribute." I am presuming in all cases, that it would be administratively closed to non-python-dev members. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@CNRI.Reston.VA.US Thu Feb 3 00:50:17 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 02 Feb 2000 19:50:17 -0500 Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: Your message of "Thu, 03 Feb 2000 02:44:52 +0200." References: Message-ID: <200002030050.TAA25376@eric.cnri.reston.va.us> > I assume you'll get a similar response from many people: hopefully, > for each patch it will either get booed automatically (hey! I just added > braces instead of indentation to the parser) or will interest someone. The thing here that makes me slightly uncomfortable is how to keep track of patches that nobody picks up. a Jitterbug database would nicely do this, but I agree that it's inconvenient and overkill for other reasons. Perhaps we could use the "Linus Torvalds' inbox algorithm"? (When it overflows he deletes everything; "if it was important they'll send it again.") --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Thu Feb 3 00:58:07 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 2 Feb 2000 19:58:07 -0500 Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: Message-ID: <000001bf6de1$bc2d0740$c1a0143f@tim> [Greg Stein asks ...] > ... > It won't reduce his load unless we have actual volunteers that will truly > do some handling of the patches. > > I'm assuming the current volunteer list is: > > - Guido (he volunteers whether he wants to or not :-) > - Moshe (??) > - Greg in April > > Others? Sure -- but can't make a concrete time commitment. The time I've been able to make so far amounted to changing three letters in a FAQ . I hope the Jitterbug idea is adopted: clunky as it is, it's public, searchable, has categories (so supports *some* rudimentary notion of workflow), and doesn't tie up my 28.8 modem . From gstein@lyra.org Thu Feb 3 01:00:19 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 2 Feb 2000 17:00:19 -0800 (PST) Subject: [Python-Dev] unhandled patches? (was: patch handling) In-Reply-To: <200002030050.TAA25376@eric.cnri.reston.va.us> Message-ID: On Wed, 2 Feb 2000, Guido van Rossum wrote: > > I assume you'll get a similar response from many people: hopefully, > > for each patch it will either get booed automatically (hey! I just added > > braces instead of indentation to the parser) or will interest someone. > > The thing here that makes me slightly uncomfortable is how to keep > track of patches that nobody picks up. a Jitterbug database would > nicely do this, but I agree that it's inconvenient and overkill for > other reasons. Perhaps we could use the "Linus Torvalds' inbox > algorithm"? (When it overflows he deletes everything; "if it was > important they'll send it again.") We have a mailing list to archive the patches, so the "delete all" approach becomes a bit harder :-). Note that the approach requires feedback to be successful. The patch author must watch CVS to know if the patch went it. Otherwise, the patch handlers would be required to notify the author one way or another. With the notify route, then we'd have to state something like "you should resend if you haven't heard back within X weeks." But the notify/resend approach also creates an expectation that a patch *will* be handled within a *specific* timeframe. Dunno what I'd think the policy should look like right now. More thought needed on my part, so I'll just defer until a list is set up and discuss there... Cheers, -g -- Greg Stein, http://www.lyra.org/ From Moshe Zadka Thu Feb 3 00:57:41 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 3 Feb 2000 02:57:41 +0200 (IST) Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: <200002030050.TAA25376@eric.cnri.reston.va.us> Message-ID: On Wed, 2 Feb 2000, Guido van Rossum wrote: > > I assume you'll get a similar response from many people: hopefully, > > for each patch it will either get booed automatically (hey! I just added > > braces instead of indentation to the parser) or will interest someone. > > The thing here that makes me slightly uncomfortable is how to keep > track of patches that nobody picks up. a Jitterbug database would > nicely do this, but I agree that it's inconvenient and overkill for > other reasons. Perhaps we could use the "Linus Torvalds' inbox > algorithm"? (When it overflows he deletes everything; "if it was > important they'll send it again.") 1. This discussion is in the (as you put it) niceties are. You are unlikely to get that many patches that it is an *immediate* problem. 2. mailman (what fun to me! I'm dumping work on Barry) could be hacked (or hooked) into doing that: it can keep a list of all patches which never got a reply in whatever list is being "replied to:" (that would neccessitate developers to CC the list, at least on the first post, but that's probably a good idea to do anyway) and send a mail message after a week to a patch-submitter who hasn't gotten a reply with a notice to the effect that nobody seems interested in it so he should make a bit more noise. 3. Like in the CP4E BOF we're getting all geeky again (which is fine, since we're all geeks). Just get something out of the door! Even a mailing list with no policy at all to who sends to it is infinitely better then Guido's mailbox, as much as we all respect that mailbox. We'll argue the fine points of exactly how to score automatically irrelevant patches (and I've got just the algorithm <0.9 wink>) later. -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From da@ski.org Thu Feb 3 01:04:46 2000 From: da@ski.org (David Ascher) Date: Wed, 2 Feb 2000 17:04:46 -0800 Subject: [Python-Dev] patch handling (was: Python 1.6 timing) References: <200002030050.TAA25376@eric.cnri.reston.va.us> Message-ID: <01c501bf6de2$a9b54950$c355cfc0@ski.org> From: "Guido van Rossum" To: Sent: Wednesday, February 02, 2000 4:50 PM Subject: Re: [Python-Dev] patch handling (was: Python 1.6 timing) > > I assume you'll get a similar response from many people: hopefully, > > for each patch it will either get booed automatically (hey! I just added > > braces instead of indentation to the parser) or will interest someone. > > The thing here that makes me slightly uncomfortable is how to keep > track of patches that nobody picks up. Sourceforge has a nice patch manager which allows a GUI'ish view of patches in context, discarding/deferring/etc. The code is available and open source. --david From Moshe Zadka Thu Feb 3 01:08:21 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 3 Feb 2000 03:08:21 +0200 (IST) Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: <01c501bf6de2$a9b54950$c355cfc0@ski.org> Message-ID: On Wed, 2 Feb 2000, David Ascher wrote: > Sourceforge has a nice patch manager which allows a GUI'ish view of patches > in context, discarding/deferring/etc. The code is available and open > source. However, I think I'd still like to be able to 1. send patches by e-mail (I don't always want to fire up a browser) 2. receive patches by e-mail (think of it as select() instead of a busy wait ;-) If the patch manager allows that/can do that with a simple addition, I'm for it. -- Moshe Zadka . INTERNET: Learn what you know. Share what you don't. From da@ski.org Thu Feb 3 01:12:37 2000 From: da@ski.org (David Ascher) Date: Wed, 2 Feb 2000 17:12:37 -0800 Subject: [Python-Dev] patch handling (was: Python 1.6 timing) References: <200002030050.TAA25376@eric.cnri.reston.va.us> Message-ID: <01f701bf6de3$c220da80$c355cfc0@ski.org> Another idea is to steal Ping's very cool idea of a 'nosy list'. If you missed his short talk at IPC8, he has a system which is a frontend to their bug database (but I think it would work well with patches). As far as I understood, folks submit bugs via an email message. Each email message has an _implicit_ mailing list, which is made up of all the people who either 'register' interest in the bug/patch, or who reply to the submission. That way there is an automatic broadcasting of the discussion to those parties interested in the topic at hand, and only those. Maybe Ping can explain in more detail how it works. It seemed like a brilliant idea to me. --david From guido@python.org Thu Feb 3 01:25:05 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 02 Feb 2000 20:25:05 -0500 Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: Your message of "Wed, 02 Feb 2000 17:12:37 PST." <01f701bf6de3$c220da80$c355cfc0@ski.org> References: <200002030050.TAA25376@eric.cnri.reston.va.us> <01f701bf6de3$c220da80$c355cfc0@ski.org> Message-ID: <200002030125.UAA25808@eric.cnri.reston.va.us> > Another idea is to steal Ping's very cool idea of a 'nosy list'. I missed it. Sounds an interesting long-term solution. I've heard about a similar concept elsewhere: you never unsubscribe to a list, each subject has its own list, and subjects just die. --Guido van Rossum (home page: http://www.python.org/~guido/) From ping@lfw.org Thu Feb 3 01:49:33 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 2 Feb 2000 17:49:33 -0800 (PST) Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: <200002030125.UAA25808@eric.cnri.reston.va.us> Message-ID: On Wed, 2 Feb 2000, Guido van Rossum wrote: > > Another idea is to steal Ping's very cool idea of a 'nosy list'. > > I missed it. Sounds an interesting long-term solution. I've heard > about a similar concept elsewhere: you never unsubscribe to a list, > each subject has its own list, and subjects just die. Yup, that's the general approach. The short paper is at http://www.lfw.org/ping/roundup.html; here is an excerpt describing the mechanism: a. New issues are always submitted by sending an e-mail message. This message is saved in a mail spool attached to the newly-created issue record, and copied to the relatively large user community of the application so everyone knows the issue has been raised. b. All e-mail messages sent by Roundup have their "Reply-To" field set to send mail back to Roundup, and have the issue's ID number in the Subject field. So, any replies to the initial announcement and subsequent threads are all received by Roundup and appended to the spool. c. Each issue has a "nosy list" of people interested in the issue. Any mail tagged with the issue's ID number is copied to this list of people, and any users found in the From:, To:, or Cc: fields of e-mail about the issue are automatically added to the nosy list. Whenever a user edits an item in the Web interface, they are also added to the list. The result is that no one ever has to worry about subscribing to anything. Indicating interest in an issue is sufficient, and if you want to bring someone new into the conversation, all you need to do is Cc: a message to them. It turns out that no one ever has to worry about unsubscribing, either: the nosy lists are so specific in scope that the conversation tends to die down by itself when the issue is resolved or people no longer find it sufficiently important. The transparent capture of the mail spool attached to each issue also yields a nice searchable knowledge repository over time. In practice, this has worked fairly well for developers at ILM, and no one has complained about missing mail they wanted or getting mail they didn't want -- which, given the apathetic nature of programmers, i suppose one could interpret as a positive empirical result. -- ?!ng "There's no point in being grown up if you can't be childish sometimes." -- Dr. Who From tim_one@email.msn.com Thu Feb 3 03:25:02 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 2 Feb 2000 22:25:02 -0500 Subject: [Python-Dev] Adding C ternary select (a?b:c) to Python? In-Reply-To: <00d901bf6d85$5577dd60$f29b12c2@secret.pythonware.com> Message-ID: <000101bf6df6$4220ee20$822d153f@tim> [Tim] > Man, you *are* Unfathomable <0.9 wink>! Even if true, you should > never have admitted to it <0.1 wink>. [Greg Wilson] > I think that's supposed to be , isn't it? [Fredrik Lundh] > not in this case. quoting a leading bot implementor: > > "We did requirements and task analysis, iterative > design, and user testing. You'd almost think emails > were an interface between people and bots." > > and I can assure you that proving that human beings don't > like weird but formally well designed syntaxes was the easy > part of that project... (but don't tell the schemers ;-) Right on, effbot! "Bots Helping Bots" is our motto. I'm quite sure the timbot's use of predates the Web's twisted formalization of what originally started life as a typographic device in a snail-mail newsletter, when the timbot discovered that "real people" had no idea what to make of ;-) style emoticons. User testing is exactly on target. Iterative design, too: the timbot's original use of [grin] didn't work nearly as well. The introduction of fractional winkery was actually a minor refinement, yet widely promoted by intuitionists as if it were the key idea. Feh. > > > "Larry Wall should be shot. Along with Bill Joy and Eric Allman." > -- Daniel Finster, on comp.lang.lisp > > "Why, just because you guys frittered away a 20-year headstart?" > -- Larry Wall Say what you will about Perl, but you gotta love Larry! I recently filed a Perl bug that was apparently introduced the day Perl5 hit the streets and somehow went unnoticed for years, and had a nice exchange with him. Looking over other recent bugs, I stumbled into this one first: @array = "0" .. -1; That, of course, computes an array of 100 elements, "0" thru "99": the string "0" gets magically autoincremented, as if it were an integer, until the *length* of the resulting string exceeds the length of the string "-1". That this wasn't justified as "a feature" gives me hope that Guido's presence on earth has done *some* little bit of good . time-for-an-oil-change-ly y'rs - tim From thomas.heller@ion-tof.com Thu Feb 3 13:27:00 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 3 Feb 2000 14:27:00 +0100 Subject: [Python-Dev] Revised proposal (and preliminary implementation): Registry access module for Python on Windows Message-ID: <019301bf6e4a$5a53f470$4500a8c0@thomasnotebook> Ok, at least the first proposal did start the discussion. Here is a revised one: A preliminary implementation is available at http://starship.python.net/crew/theller/ ---------------------------------------------------------------------- winreg - windows registry access module Exception: error - raised when a function fails. Will contain a windows error code and a textual description. Objects: regnode object - represents a open key in the registry. Functions: OpenKey (name) -> regnode object Opens an existing key with the specified access rights and returns a regnode object. name is specified like "HKLM\Software\Python" or "HKEY_LOCAL_MACHINE\Software\Python" CreateKey (name) -> regnode object Creates a new key or opens an existing one and returns a regnode object. For the name format see OpenKey regnode object methods: Values () -> dict Returns a dictionary mapping names to values. The or unnamed value has the key ''. The values are either strings or integers, depending on the REG_* type. GetValue ([name]) -> integer or string Returns a value specified by name or the default value. SetValue ([name,] value) Set a named or the value. Named values must be integers or string (which are stored as REG_DWORD or REG_SZ). Should an optional third parameter be used, allowing to store in other REG_* typecodes? I dont think so. DeleteValue ([name]) Deletes a named or the value. SubKeys () -> sequence Returns a sequence containing the names of all subkeys. DeleteKey (name [,recursive=0]) If recursive is 0, deletes the named key if no subkeys exist. If there are subkeys an error is raised. If recursive is not 0, the named key is deleted including subkeys. OpenKey (name) -> regnode object Openes an existing subkey and returns a regnode object pointing to it. CreateKey (name) -> regnode object Creates a new or openes an existing subkey and returns a regnode object pointing to it. regnode objects have the following properties: name - the name of the RegistryKey, something like "HKLM\Software\Python" hkey - the integer keyhandle ---------------------------------------------------------------------- Thomas Heller From thomas.heller@ion-tof.com Thu Feb 3 13:26:39 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 3 Feb 2000 14:26:39 +0100 Subject: [Python-Dev] Proposal: Registry access for Python on Windows References: Message-ID: <018b01bf6e4a$4db27700$4500a8c0@thomasnotebook> [Thomas] > > I propose to include functions to access the windows registry > > into the python 1.6 core. [Mark] > > Agreed! Fine. Thats the _main_ purpose of the proposal. > > winreg - registry access module > > Im not convinced that we need either a) a new implementation, or b) a new > API. > > I would propose that we use the existing registry access functions from > win32api - as I didnt code them, Im not suggesting this due to my own ego. > The reasons for my beliefs are: > > * The new API does not add any new value. The only changes I can see are > that OpenKey() has had a reserved value dropped and QueryValue() has an > extra redundant result. The redundant result value was a typo in the proposal. > Indeed the new API does not appear a new API at > all, so should be clearly stated if indeed it is (and in which case, exactly > what the changes are) or be documented as a pythonic wrapping of the > existing win32 registry API. Further, there is some useful functionality > dropped. I posted my proposal to start the discussion - so far it has been successfull - not as the final specification for the api. I admit: it has been too low level. I have posted (and implemented) a new proposal describing a more high level interface. In this I followed Gordon's suggestion: Provide the minimum needed. If one wants to do more special things, one probably needs your win32 extensions anyway. > > * Well tested. There are some obscure rules and code that experience has > shown we need. It would be a shame to reinvent those wheels. Already too late! (Programming is fun :-) (Is competition good ?) > It has taken > a few years to get it "just right", and this was an implementation by people > who know their stuff! The only obscure code I can see (having looked at win32api source AFTER writing my code) is the handling of REG_MULTI_SZ. These are returned as one normal string with embedded NULL bytes by my implementation. BTW: This is also how regedit.exe (but not regedt32) handles these. > > Why not take the existing code as it stands (which _does_ include an > auto-closing key) and add a new .py wrapper? At least Python will have a > "complete, but low-level" registry API, and a higher level "easier to use, > but maybe not complete" layer implemented in Python. > > Indeed, Guido has stated that the existing win32api functions would be > suitable for the core. Don't you think that the raw Win32 api functions are much too low level to belong into core python? How should they be documented? Pointers to msdn.microsoft.com? > However, the issue is the "coding style" - and I > admit that if I knew exectly what that meant I would make the change - eg, > if it only means renaming the identifiers it would be trivial - however, it > would also appear to be excessively anal, so Im sure there is more to it > than that :-) It seems (but I may be wrong) that my coding style is nearer to Guido's than that of win32api. Regards, Thomas From fdrake@acm.org Thu Feb 3 14:49:49 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 3 Feb 2000 09:49:49 -0500 (EST) Subject: [Python-Dev] __contains__ hook In-Reply-To: <3898BEBD.93DFBCA7@lemburg.com> References: <200002021849.NAA23092@eric.cnri.reston.va.us> <3898BEBD.93DFBCA7@lemburg.com> Message-ID: <14489.38285.840829.261016@weyr.cnri.reston.va.us> M.-A. Lemburg writes: > Shouldn't 'in' be a slot of the sequence methods ? I'd suggest > creating a new tp_flag bit and then extending tp_as_sequence Only if we want to restrict set-like behavior to sequences, and I don't think that's clear, though it does mirror the current situation. Regardless of the location of the slot, why should a flag be needed? Testing the slot for NULL is necessary to avoid core dumps anyway. > plus of course add an abstract function to abstract.c: > > PySequence_Contain(PyObject *container, PyObject *element) There's already PySequence_In(...); see: http://www.python.org/doc/current/api/sequence.html#l2h-135 I'm inclined to add PyObject_In(...) (or ..._Contains(); I like Contains better than In, but there's precedence for In and that's more important) and define the new slot on the Object using one of the reserved spaces. That allows a clean interface for "pure" sets that don't have to "look like" sequences or mappings. > which uses the above slot after testing the tp_flag setting. > Python instances, lists, tuples should then support this new > slot. We could even sneak in support for dictionaries once we > decide whether semantics whould be Bait! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From tismer@tismer.com Thu Feb 3 14:47:51 2000 From: tismer@tismer.com (Christian Tismer) Date: Thu, 03 Feb 2000 15:47:51 +0100 Subject: Python 2 namespace change? (was Re: [Python-Dev] Changing existing class instances) References: <000301bf652e$f348d1c0$132d153f@tim> Message-ID: <38999517.F32AFBF5@tismer.com> Tim Peters wrote: > > [Jim Fulton] [association objects] > Jim, I've been intrigued by this idea for all the years you've been > suggesting it , but I've never understood what it is you're proposing! > This is the Python-Dev list, so feel encouraged to present it in concrete > implementation terms instead of ambiguous English. Or maybe an interface? My guess is: An association object adds another level of indirection to namespaces and makes global variables be more like true variables, i.e. changing them in one place changes them everywhere. > Does this kind of dictionary have keys? If so, of what type? What type are > the values? Best I can make sense of the above, the values are "association > objects", each of which contains a name and a value, and a key is maybe a > duplicate of the name in the association object to which it maps. "A name" > may or may not be a string -- I can't tell. Or maybe by "dictionary" you > didn't intend Python's current meaning for that word at all. I assume "a > value" is a PyObject*. The whole thrust *appears* to be to get names to map > to a PyObject** instead of PyObject*, but if that's the ticket I don't know > what association objeects have to do with it. I don't believe that the actual implementation matters too much and is still open to be choosen. Here my approach: Let an association object be a pair of a key and a value. The restrictions for keys may be the same as for dict keys. We can now either use dicts as they are, inserting asso-objects as values and sharing the key field, or invent new dictionaries which have no key/value pairs at all, but just references to asso-objects. In either case, we have the advantage that further references by global use from a function or by imports will always add to the asso-object, not to its value. This keeps the value changeable, like a list with one element, kind of boxed object. Since the asso-objects stay alive as long as they are referenced, they are never moved, and it is ok to refer to their address. For a function, this means that it can resolve a global at compile time. If the asso-object exists already, it has a fixed memory address and can be placed into the code object. If it does not exist, it can be created in the global dictionary or special asso-dictionary, whatever we'll use. The value will be NULL in this case, and this is perfect. If we do right, a value will have been inserted before the function is called, or we will raise a name error. The idea is simply to generate fixed slots for global names which never move. By mentioning the name, we create such a slot. The slot is alive as long it is seen, i.e. refcount > 0. There must be a general way to look these things up, either by the per-module dictionary, or by a specialized one. Finally I'd tend to do the latter, since those unitialized key/value asso-objects would give ambiguity what dict.keys() should be then. For consistency, I would hide all asso-objects in a special asso-collection per module. They could be placed into the modules dict, when their value becomes assigned first time. Alternatively, they are not created at compile time but at runtime, when a value is assigned. I'm not sure yet. Now, moving on from globals to all name spaces: If they are all handled by the asso-approach, can we use it to speed up attribute access for classes and instances? I guess we can! But I need more thought. > > An import like: > > > > from foo import spam > > sentence == """ > > would copy the association between the name 'foo' and a > > value from module 'spam' into the current module. > > Where does the idea that 'spam' is a *module* here come from? It doesn't > make sense to me, and I'm so lost I'll spare everyone my further confusions > . """ def swap_words(str, one, two): pieces = string.split(str, one) for i in range(len(pieces)): pieces[i] = string.replace(pieces[i], two, one) return string.join(pieces, two) sentence = swap_words(sentence, "'foo'", "'spam'") ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Düppelstr. 31 : *Starship* http://starship.python.net 12163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From fdrake@acm.org Thu Feb 3 15:05:25 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 3 Feb 2000 10:05:25 -0500 (EST) Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: References: Message-ID: <14489.39221.91861.262217@weyr.cnri.reston.va.us> Moshe Zadka writes: > OK, I want to know one thing: is everyone comfortable with my suggestion > of a seperate list, with a reply-to: python-dev? Barry said he'd be > willing to hack it in, and everyone who talked seemed like this idea is I think this is the right approach. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Thu Feb 3 15:07:52 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 3 Feb 2000 10:07:52 -0500 (EST) Subject: [Python-Dev] patch handling (was: Python 1.6 timing) In-Reply-To: References: Message-ID: <14489.39368.355346.261453@weyr.cnri.reston.va.us> Greg Stein writes: > - Guido (he volunteers whether he wants to or not :-) > - Moshe (??) > - Greg in April I can certainly help out a bit, at least for small patches and anything related to the documentation (including additions of docstrings to module sources and the like). -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Thu Feb 3 15:09:54 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 3 Feb 2000 10:09:54 -0500 (EST) Subject: [Python-Dev] patches reply-to (was: Python 1.6 timing) In-Reply-To: References: Message-ID: <14489.39490.879151.5888@weyr.cnri.reston.va.us> Moshe Zadka writes: > I retract my suggestion. Have python-patch, python-patch-discuss > (python-patch would be replied-to: python-patch-discuss) and keep > python-dev as a clean list. This way, people could just subscribe to I'd be fine with this as well. If Ping can release his issue-tracker any time soon, that would also be a really nice tool. That was quite impressive. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From jim@digicool.com Thu Feb 3 15:34:54 2000 From: jim@digicool.com (Jim Fulton) Date: Thu, 03 Feb 2000 10:34:54 -0500 Subject: Python 2 namespace change? (was Re: [Python-Dev] Changing existing class instances) References: <200001200419.XAA01969@mira.erols.com> <38871665.C3B6FFEE@digicool.com> <38871CE5.53FB9D68@digicool.com> <200001201545.KAA21304@eric.cnri.reston.va.us> <38873C52.29FEAC6D@digicool.com> <200001201720.MAA21534@eric.cnri.reston.va.us> Message-ID: <3899A01E.DE29FC94@digicool.com> Eek, I didn't realized this thread had continued until I happened to notice Christian's post today. I get too much email Guido van Rossum wrote: > > [me] > > > I've never liked this very much, mostly because it breaks simplicity: > > > the idea that a namespace is a mapping from names to values > > > (e.g. {"limit": 100, "doit": , ...}) is beautifully > > > simple, while the idea of inserting an extra level of indirection, no > > > matter how powerful, is much murkier. > > [Jim F] > > How so? It doesn't change the mapping semantics. > > My assumption is that in your version, the dictionary would contain > special
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4