Re: [Python-Dev] Octal literals
On Sun, 05 Feb 2006 18:47:13 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote: > >[EMAIL PROTECTED] (Bengt Richter) wrote: >> Are you just lecturing me personally (in which case off list would be more >> appropriate), >> or do you include the authors of the 17 files I count under > prefix>/Lib that have >> isinstance(, int) in them? >> Or would you like to rephrase that with suitable qualifications? ;-) > >I did not mean to sound like I was lecturing you personally. > >Without taking a peek at the source, I would guess that the various uses >of isinstance(, int) are bugs, possibly replacing previous >uses of type() is int, shortly after int subclassing was >allowed. But that's just a guess. > Thank you. I didn't look either, but I did notice that most (but not all) of them were under /Lib/test/. Maybe it's excusable for test code ;-) Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
On Sun, 5 Feb 2006 18:08:58 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: >On 2/5/06, Bengt Richter <[EMAIL PROTECTED]> wrote: >> On Sun, 05 Feb 2006 09:38:35 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote: >> >1. If your Python code distinguishes between ints and longs, it has a >> >bug. >> Are you just lecturing me personally (in which case off list would be more >> appropriate), >> or do you include the authors of the 17 files I count under > prefix>/Lib that have >> isinstance(, int) in them? > >Josiah is correct, and those modules all have bugs. > It seems I stand incontestably corrected. Sorry, both ways ;-/ Perhaps I missed a py3k assumption in this thread (where I see in the PEP that "Remove distinction between int and long types" is core item number one)? I googled, but could not find that isinstance(,int) was slated for deprecation, so I assumed that Josiah's absolute statement "1. ..." (above) could not be absolutely true, at least in the "has" (present) tense that he used. Is PEP 237 phase C to be implemented sooner than py3k, making isinstance(, int) a transparently distinction-hiding alias for isinstance(, integer), or outright illegal? IOW, will isinstance(, int) be _guaranteed_ to be a bug, thus requiring code change? If so, when? Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Guido van Rossum wrote: > After so many attempts to come up with an alternative for lambda, > perhaps we should admit defeat. I've not had the time to follow the > most recent rounds, but I propose that we keep lambda, so as to stop > wasting everybody's talent and time on an impossible quest. Personally, I'd rather see a callable-from-expression syntax (the ``lambda`` expression) that looks more like our callable-from-statements syntax (the ``def`` statement), e.g. Nick Coghlan's def-from syntax:: (def f(a) + o(b) - o(c) from (a, b, c)) Something like this is more consistent with how list creation is turned into list comprehensions, how generator functions are turned into generator expressions and how if/else statements are turned into conditional expressions. That said, I firmly believe that syntax decisions *must* be left to the BDFL. The decorator syntax and with-statement syntax debates clearly showed this. So if after looking at all the syntax alternatives_, you feel that the current lambda syntax is the best we can do, I'm willing to accept that decision. .. _alternatives: http://wiki.python.org/moin/AlternateLambdaSyntax STeVe -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] any support for a methodcaller HOF?
| making the implied return statment visible might also be a good idea, | e.g. | |lambda x, y: return x + y | | or even | |def (x, y): return x + y | Although I don't understand the implications of making such a change, the 2nd alternative above looks very nice. Whenever I write a lambda I feel like I am doing something non-pythonic. I think the 2nd proposal increases the readability of the lambda, something that is often touted as being part of what makes python beautiful. /c ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
[EMAIL PROTECTED] (Bengt Richter) wrote: > Are you just lecturing me personally (in which case off list would be more > appropriate), > or do you include the authors of the 17 files I count under /Lib > that have > isinstance(, int) in them? > Or would you like to rephrase that with suitable qualifications? ;-) I did not mean to sound like I was lecturing you personally. Without taking a peek at the source, I would guess that the various uses of isinstance(, int) are bugs, possibly replacing previous uses of type() is int, shortly after int subclassing was allowed. But that's just a guess. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
On 2/5/06, Bengt Richter <[EMAIL PROTECTED]> wrote: > On Sun, 05 Feb 2006 09:38:35 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote: > >1. If your Python code distinguishes between ints and longs, it has a > >bug. > Are you just lecturing me personally (in which case off list would be more > appropriate), > or do you include the authors of the 17 files I count under /Lib > that have > isinstance(, int) in them? Josiah is correct, and those modules all have bugs. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 5 feb 2006, at 18:43, Guido van Rossum wrote: > After so many attempts to come up with an alternative for lambda, > perhaps we should admit defeat. I've not had the time to follow the > most recent rounds, but I propose that we keep lambda, so as to stop > wasting everybody's talent and time on an impossible quest. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) +1 And let's add "Wise" t the BDFL's title: WBDFL. ;-) --eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] any support for a methodcaller HOF?
On Sun, 05 Feb 2006 18:45:52 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote: [...] >Psst, Nick, how about >(x*y for x,y in ()) ? # "()" as mnemonic for call args D'oh, sorry, that should have been illegal syntax, e.g., (x*y for x,y in *) ? # "*" as mnemonic for call *args so (x*y for x,y in *)(3,5) # => 15 or (x*y for x,y in *)(*[3,5]) # => 15 etc. Hm, along that line why not (x*y for x,y in **) ? # "**" as mnemonic for call **kwargs so (x*y for x,y in **)(x=3, y=5) # => 15 or maybe even (x*y+z for (x,y),z in *,**)(3, 5, z=200) # => 215 Though I see this is moot, since Guido decided to "keep lambda," (+1 on that, although this is kind of growing on me, no doubt from partial ih-factor ;-) Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries
You don't have to keep writing notes to python-dev on this patch. It is assigned to me and when I get a chance to go through it in detail, it has a good likelihood of going in (if no issues arise). Raymond - Original Message - From: "Crutcher Dunnavant" <[EMAIL PROTECTED]> To: "Martin v. Löwis" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Aahz" <[EMAIL PROTECTED]>; Sent: Sunday, February 05, 2006 5:53 PM Subject: Re: [Python-Dev] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries I've significantly re-worked the patch to permit globals to be arbitrary mappings. The regression tests continue to all pass. http://sourceforge.net/tracker/index.php?func=detail&aid=1402289&group_id=5470&atid=305470 On 1/24/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Crutcher Dunnavant wrote: > > Okay, but is there any reason not to include this in 2.5? There > > doesn't seem to be any noticeable performance impact, and it does add > > consistancy (and opens some really, really cool options up). > > I see no reason, except perhaps the lack of volunteers to actually > patch the repository (along with the accompanying work). > > Regards, > Martin > > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries
I've significantly re-worked the patch to permit globals to be arbitrary mappings. The regression tests continue to all pass. http://sourceforge.net/tracker/index.php?func=detail&aid=1402289&group_id=5470&atid=305470 On 1/24/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Crutcher Dunnavant wrote: > > Okay, but is there any reason not to include this in 2.5? There > > doesn't seem to be any noticeable performance impact, and it does add > > consistancy (and opens some really, really cool options up). > > I see no reason, except perhaps the lack of volunteers to actually > patch the repository (along with the accompanying work). > > Regards, > Martin > > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
[Crutcher Dunnavant[ > Which reminds me, we need to support roman numeral constants. One of my more-normal relatives reminded me that this is Super Bowl XL Sunday, so your demand is more topical than it would ordinarily be. Alas, there's already a PEP on this, and it was already rejected. See PEP CCCXIII: http://www.python.org/peps/pep-0313.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Which reminds me, we need to support roman numeral constants. A silly implementation follows. class RomanNumeralDict(dict): def __getitem__(self, key): if not self.has_key(key) and self.isRN(key): return self.decodeRN(key) return dict.__getitem__(self, key) def isRN(self, key): for c in key: if c not in 'MmCcXxIiDdVv': return False return True def decodeRN(self, key): val = 0 # ... do stuff ... return val On 2/5/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Guido] > > After so many attempts to come up with an alternative for lambda, > > perhaps we should admit defeat. I've not had the time to follow the > > most recent rounds, but I propose that we keep lambda, so as to stop > > wasting everybody's talent and time on an impossible quest. > > Huh! Was someone bad-mouthing lambda again? We should keep it, but > rename it to honor a different Greek letter. xi is a good one, easier > to type, and would lay solid groundwork for future flamewars between > xi enthusiasts and Roman numeral fans :-) > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/crutcher%40gmail.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> monket.samedi-studios.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
[Guido] > After so many attempts to come up with an alternative for lambda, > perhaps we should admit defeat. I've not had the time to follow the > most recent rounds, but I propose that we keep lambda, so as to stop > wasting everybody's talent and time on an impossible quest. Huh! Was someone bad-mouthing lambda again? We should keep it, but rename it to honor a different Greek letter. xi is a good one, easier to type, and would lay solid groundwork for future flamewars between xi enthusiasts and Roman numeral fans :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
+1 On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > After so many attempts to come up with an alternative for lambda, > perhaps we should admit defeat. I've not had the time to follow the > most recent rounds, but I propose that we keep lambda, so as to stop > wasting everybody's talent and time on an impossible quest. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/crutcher%40gmail.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> monket.samedi-studios.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
+1 on retaining lambda -1 on any name change On Sun, 5 Feb 2006, Paul Moore wrote: > On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > After so many attempts to come up with an alternative for lambda, > > perhaps we should admit defeat. I've not had the time to follow the > > most recent rounds, but I propose that we keep lambda, so as to stop > > wasting everybody's talent and time on an impossible quest. > > +1 > > The recently suggested keyword change, from lambda to expr (as in > '''expr x, y: x+y''') looks like an improvement to me, but I suspect > opening up the possibility of a keyword change would simply restart > all the discussions... (Nevertheless, I'd be +1 on lambda being > renamed to expr, if it was an option). > > Paul. > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/allison%40shasta.stanford.edu > -- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
> After so many attempts to come up with an alternative for lambda, > perhaps we should admit defeat. I've not had the time to follow the > most recent rounds, but I propose that we keep lambda, so as to stop > wasting everybody's talent and time on an impossible quest. +1 -- trying to cover all the use cases is a fools errand Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > After so many attempts to come up with an alternative for lambda, > perhaps we should admit defeat. I've not had the time to follow the > most recent rounds, but I propose that we keep lambda, so as to stop > wasting everybody's talent and time on an impossible quest. +1 The recently suggested keyword change, from lambda to expr (as in '''expr x, y: x+y''') looks like an improvement to me, but I suspect opening up the possibility of a keyword change would simply restart all the discussions... (Nevertheless, I'd be +1 on lambda being renamed to expr, if it was an option). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
On Sun, 5 Feb 2006 13:48:51 -0500, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote: [...] > [...] >A language suitable for beginners should be easy to learn, but it should not >leave them permanently crippled. All of the above are sets of training >wheels >that don't come off. To misquote Einstein: The language should be as >simple >as possible, but no simpler. > ++1 QOTW Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On Sunday 05 February 2006 12:43, Guido van Rossum wrote: > After so many attempts to come up with an alternative for lambda, > perhaps we should admit defeat. I've not had the time to follow the > most recent rounds, but I propose that we keep lambda, so as to stop > wasting everybody's talent and time on an impossible quest. +1 -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
On Sun, 05 Feb 2006 09:38:35 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote: > >[EMAIL PROTECTED] (Bengt Richter) wrote: >> Martin v. Lowis <[EMAIL PROTECTED]> wrote: >> >Bengt Richter wrote: >> >>>The typical way of processing incoming ints in C is through >> >>>PyArg_ParseTuple, which already has the code to coerce long->int >> >>>(which in turn may raise an exception for a range violation). >> >>> >> >>>So for typical C code, 0x8004 is a perfect bit mask in Python 2.4. >> >> >> >> Ok, I'll take your word that 'k' coercion takes no significant time for >> >> longs vs ints. >> > >> >I didn't say that 'k' takes no significant time for longs vs ints. In >> >fact, I did not make any performance claims. I don't know what the >> >relative performance is. >> >> Sorry, I apologize for putting words in your mouth. > >In regards to the aesthetics and/or inconsistancies of: > >>> -0x8000 > -2147483648L > >>> -2147483648 > -2147483648 > >>> -(2147483648) > -2147483648L > >1. If your Python code distinguishes between ints and longs, it has a >bug. Are you just lecturing me personally (in which case off list would be more appropriate), or do you include the authors of the 17 files I count under /Lib that have isinstance(, int) in them? Or would you like to rephrase that with suitable qualifications? ;-) > >2. If your C extension to Python isn't using the 'k' format specifier as >Martin is telling you to, then your C extension has a bug. I respect Martin's expert knowledge and manner of communication. He said, "Just have a look at the 'k' specifier in PyArg_ParseTuple." Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
On Feb 5, 2006, at 11:31 AM, Raymond Hettinger wrote: > [Bob Ipppolito] >> For those of us that already know what we're doing with floating >> point, areclose would be very convenient to have. > > Do you agree that the original proposed use (helping newbs ignore > floating > point realities) is misguided and error-prone? Maybe it's a bit misguided, but it's less error-prone than more naive comparisons. It could delay the necessity for a newer programmer to lean all about floating point, but maybe most of those users don't really need to learn it. Whether the function is there or not, this is really a documentation issue. If the function is there then maybe it could highly suggest reading some "floating point in Python" guide that would describe the scenario, then lists common pitfalls with patterns that avoid those problems. > Just curious, for your needs, do you want both absolute and > relative checks combined into the same function? Having both makes it less likely that you'll need to tweak the constants, except of course if you're working with very small numbers such that the absolute tolerance is too big. Of course, if you only want one or the other in a given case, you can always pass in 0 manually. For my needs, the proposed function and default tolerances would be better than the sloppy stuff that usually ends up in my tests. >> Especially for unit testing. I could definitely throw away a >> bunch of ugly code that uses less correct arbitrary tolerance >> guesses if it were around. > > The unittest module already has assertAlmostEqual(). Does that > method meet your needs or does it need to be improved in some way? I generally write tests that don't run directly under the unittest framework, such as doctests or assert-based functions for nose or py.test. The unittest module does not expose assertAlmostEqual as a function so it's of little use for me. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
[Bob Ipppolito] > For those of us that already know what we're doing with floating > point, areclose would be very convenient to have. Do you agree that the original proposed use (helping newbs ignore floating point realities) is misguided and error-prone? Just curious, for your needs, do you want both absolute and relative checks combined into the same function? > Especially for > unit testing. I could definitely throw away a bunch of ugly code > that uses less correct arbitrary tolerance guesses if it were around. The unittest module already has assertAlmostEqual(). Does that method meet your needs or does it need to be improved in some way? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
On Feb 5, 2006, at 10:48 AM, Raymond Hettinger wrote: >>> So I was wondering if module math (and >>> perhaps by symmetry module cmath, too) shouldn't grow a function >>> 'areclose' (calling it just 'close' seems likely to engender >>> confusion, since 'close' is more often used as a verb than as an >>> adjective; maybe some other name would work better, e.g. >>> 'almost_equal') taking two float arguments and optional tolerances >>> and using roughly the same specs as Numeric, e.g.: >>> >>> def areclose(x,y,rtol=1.e-5,atol=1.e-8): >>> return abs(x-y) > IMO, the cure is worse than the disease. It is easier to learn about > the hazards of floating point equality testing than to think > through the > implications of tolerance testing (such as loss of transitivity) and > learning > how to set the right tolerance values for a given application (ones > that > give the right results across the entire domain of expected inputs). > > The areclose() function can be a dangerous crutch that temporarily > glosses over the issue. Without some numerical sophistication, it > would not > be hard create programs that look correct and pass a few test but, > in fact, > contain nasty bugs (non-termination, incorrect acceptance/ > rejection, etc). For those of us that already know what we're doing with floating point, areclose would be very convenient to have. Especially for unit testing. I could definitely throw away a bunch of ugly code that uses less correct arbitrary tolerance guesses if it were around. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] any support for a methodcaller HOF?
Terry Reedy wrote: > If 3.0 comes with a conversion program, then I would like to see 'lambda' > replaced with either 'def' or another abbreviation like 'edef' (expression > def) or 'func'. making the implied return statment visible might also be a good idea, e.g. lambda x, y: return x + y or even def (x, y): return x + y ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > After so many attempts to come up with an alternative for lambda, > perhaps we should admit defeat. I've not had the time to follow the > most recent rounds, but I propose that we keep lambda, so as to stop > wasting everybody's talent and time on an impossible quest. To me, there are two separate issues: the keyword and the syntax. I also have not been impressed by any of the numerous alternative syntaxes proposed over several years and just this morning was thinking something similar to the above. But will you consider changing the keyword from the charged and overladen 'lambda' to something else? (See other post today.) I think this would cut at least half the fuss. I base this on the following observation: generator expressions are to generator statement definitions much like function expressions are to function statement definitions. Both work when the payload yielded or returned is computed in a single expression. But I personally have not seen any complaints about the 'limitations of generator expressions' nor proposals to duplicate the generality of statement definitions by stuffing compound statement bodies within expressions. But if we had called them generator lambdas, I suspect we would have. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Guido van Rossum wrote: >After so many attempts to come up with an alternative for lambda, >perhaps we should admit defeat. I've not had the time to follow the >most recent rounds, but I propose that we keep lambda, so as to stop >wasting everybody's talent and time on an impossible quest. > >-- >--Guido van Rossum (home page: http://www.python.org/~guido/) >___ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/gherron%40islandtraining.com > > Hear hear! +1 Gary Herron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
Georg Brandl wrote: > Alex Martelli wrote: >>So I was wondering if module math (and perhaps by symmetry module cmath, >> too) shouldn't grow a function 'areclose' ...maybe ... 'almost_equal') >> def areclose(x, y, rtol=1.e-5, atol=1.e-8): >> return abs(x-y) > atol sounds suspicious to me, but otherwise fine. "almost_equal", "closeto", or some variant of "near" (no nasty verb to worry about) would do for me. atol / rtol would be better as either abs_tol / rel_tol or even absolute_tolerance / relative_tolerance. As to the equation itself, wouldn't a symmetric version be somewhat better? def nearby(x, y, rel_tol=1.e-5, abs_tol=1.e-8): return abs(x - y) < abs_tol + rel_tol * (abs(x) + abs(y)) This avoids areclose(0, 1e-8) != areclose(1e-8, 0), for example. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
>>So I was wondering if module math (and >> perhaps by symmetry module cmath, too) shouldn't grow a function >> 'areclose' (calling it just 'close' seems likely to engender >> confusion, since 'close' is more often used as a verb than as an >> adjective; maybe some other name would work better, e.g. >> 'almost_equal') taking two float arguments and optional tolerances >> and using roughly the same specs as Numeric, e.g.: >> >> def areclose(x,y,rtol=1.e-5,atol=1.e-8): >> return abs(x-y) This proposal is one of several that have recently surfaced that aim to help newbies skip learning basic lessons. I think the efforts are noble but misguided. * If someone doesn't get why set(1,2,3) raises an exception, it is a good opportunity to teach a broadly applicable skill: def Set(*args): return set(args) * If someone doesn't get why sum([0.1]*10)!=1.0, then we have a good opportunity to teach the basics of floating point. Otherwise, we're going to get people writing accounting apps using floats instead of ints or Decimals. * If someone doesn't get how to empty a list using a[:]=[], it is a good time to go through the basics of slicing which are a foundation for understanding many parts of the language. A language suitable for beginners should be easy to learn, but it should not leave them permanently crippled. All of the above are sets of training wheels that don't come off. To misquote Einstein: The language should be as simple as possible, but no simpler. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] any support for a methodcaller HOF?
On Sat, 4 Feb 2006 20:17:15 +0100, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>Nick Coghlan wrote:
>>> I believe that usage of a keyword with the name of a Greek letter also
>>> contributes to people considering something broken.
>>
>> Aye, I agree there are serious problems with the current syntax. All
>> I'm
>> trying to say above is that I don't believe the functionality itself
>> is broken.
>
>Lambda is not broken, it's restricted to single calculation and
>therefore of limited use.
It's not even that restricted, if you want to be perverse, e.g.,
>>> (lambda w:eval(compile("""if 1: # indented looks nicer ;-)
... if len(w)<=3: adj ='short'
... elif len(w)<=5: adj ='medium length'
... else: adj = 'long'
... print 'Hi, %s! I would say you have a %s name ;-)'%(w,adj)
... """,'','exec')))('Monty')
Hi, Monty! I would say you have a medium length name ;-)
lazy copy/pasting and changing the arg:
>>> (lambda w:eval(compile("""if 1: # indented looks nicer ;-)
... if len(w)<=3: adj ='short'
... elif len(w)<=5: adj ='medium length'
... else: adj = 'long'
... print 'Hi, %s! I would say you have a %s name ;-)'%(w,adj)
... """,'','exec')))('Ada')
Hi, Ada! I would say you have a short name ;-)
My point is that ISTM preventing easy inclusion of suites in
lambda/anonymous_def
is more of a morality/taste/catechistic issue than a technical one. It seems
like
an attempt to control coding style by disincentivizing the disapproved.
That may be ok in the big picture, I'm not sure, but IMO transparency of
motivations is best.
>Although I wasn't too serious (should had added more signs of that), an
>anonymous 'def' would allow to use the full power of method definition.
>
It's already allowed, just not in a way that generates efficient code (although
the above can be improved upon, let's not go there ;-)
>> At last count, Guido's stated preference was to ditch the functionality
>> entirely for Py3k, so unless he says something to indicate he's
>> changed his
>> mind, we'll simply need to continue with proposing functions like
>> methodcaller() as workarounds for its absence...
>
>Yep, we'll just have to learn to live without it. :-( / ;-)
If it's needed, I believe a way will be found to have it ;-)
I do think the current lambda serves a valuable purpose, so I
hope some way is found to preserve the functionality, whatever
problems anyone may have with its current simple syntax.
Psst, Nick, how about
(x*y for x,y in ()) ? # "()" as mnemonic for call args
;-)
Regards,
Bengt Richter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] any support for a methodcaller HOF?
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I guess I misstated myself slightly - I've previously advocated re-using > the > 'def' keyword, so there are obviously parallels I want to emphasize. If 3.0 comes with a conversion program, then I would like to see 'lambda' replaced with either 'def' or another abbreviation like 'edef' (expression def) or 'func'. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
Alex Martelli wrote: > When teaching some programming to total newbies, a common frustration > is how to explain why a==b is False when a and b are floats computed > by different routes which ``should'' give the same results (if > arithmetic had infinite precision). Decimals can help, but another > approach I've found useful is embodied in Numeric.allclose(a,b) -- > which returns True if all items of the arrays are ``close'' (equal to > within certain absolute and relative tolerances): > > >>> (1.0/3.0)==(0.1/0.3) > False > >>> Numeric.allclose(1.0/3.0, 0.1/0.3) > 1 > > But pulling in the whole of Numeric just to have that one handy > function is often overkill. So I was wondering if module math (and > perhaps by symmetry module cmath, too) shouldn't grow a function > 'areclose' (calling it just 'close' seems likely to engender > confusion, since 'close' is more often used as a verb than as an > adjective; maybe some other name would work better, e.g. > 'almost_equal') taking two float arguments and optional tolerances > and using roughly the same specs as Numeric, e.g.: > > def areclose(x,y,rtol=1.e-5,atol=1.e-8): > return abs(x-y) > What do y'all think...? atol sounds suspicious to me, but otherwise fine. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
On Sun, Feb 05, 2006, Alex Martelli wrote: > > But pulling in the whole of Numeric just to have that one handy > function is often overkill. So I was wondering if module math (and > perhaps by symmetry module cmath, too) shouldn't grow a function > 'areclose' (calling it just 'close' seems likely to engender > confusion, since 'close' is more often used as a verb than as an > adjective; maybe some other name would work better, e.g. > 'almost_equal') taking two float arguments and optional tolerances > and using roughly the same specs as Numeric, e.g.: > > def areclose(x,y,rtol=1.e-5,atol=1.e-8): > return abs(x-y) http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Let's just *keep* lambda
After so many attempts to come up with an alternative for lambda, perhaps we should admit defeat. I've not had the time to follow the most recent rounds, but I propose that we keep lambda, so as to stop wasting everybody's talent and time on an impossible quest. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
[EMAIL PROTECTED] (Bengt Richter) wrote: > Martin v. Lowis <[EMAIL PROTECTED]> wrote: > >Bengt Richter wrote: > >>>The typical way of processing incoming ints in C is through > >>>PyArg_ParseTuple, which already has the code to coerce long->int > >>>(which in turn may raise an exception for a range violation). > >>> > >>>So for typical C code, 0x8004 is a perfect bit mask in Python 2.4. > >> > >> Ok, I'll take your word that 'k' coercion takes no significant time for > >> longs vs ints. > > > >I didn't say that 'k' takes no significant time for longs vs ints. In > >fact, I did not make any performance claims. I don't know what the > >relative performance is. > > Sorry, I apologize for putting words in your mouth. In regards to the aesthetics and/or inconsistancies of: >>> -0x8000 -2147483648L >>> -2147483648 -2147483648 >>> -(2147483648) -2147483648L 1. If your Python code distinguishes between ints and longs, it has a bug. 2. If your C extension to Python isn't using the 'k' format specifier as Martin is telling you to, then your C extension has a bug. 3. If you are concerned about *potential* performance degredation due to a use of 'k' rather than 'i' or 'I', then you've forgotten the fact that Python function calling is orders of magnitude slower than the minimal bit twiddling that PyInt_AsUnsignedLongMask() or PyLong_AsUnsignedLongMask() has to do. Please, just use 'k' and let the list get past this. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] math.areclose ...?
When teaching some programming to total newbies, a common frustration is how to explain why a==b is False when a and b are floats computed by different routes which ``should'' give the same results (if arithmetic had infinite precision). Decimals can help, but another approach I've found useful is embodied in Numeric.allclose(a,b) -- which returns True if all items of the arrays are ``close'' (equal to within certain absolute and relative tolerances): >>> (1.0/3.0)==(0.1/0.3) False >>> Numeric.allclose(1.0/3.0, 0.1/0.3) 1 But pulling in the whole of Numeric just to have that one handy function is often overkill. So I was wondering if module math (and perhaps by symmetry module cmath, too) shouldn't grow a function 'areclose' (calling it just 'close' seems likely to engender confusion, since 'close' is more often used as a verb than as an adjective; maybe some other name would work better, e.g. 'almost_equal') taking two float arguments and optional tolerances and using roughly the same specs as Numeric, e.g.: def areclose(x,y,rtol=1.e-5,atol=1.e-8): return abs(x-y)http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path PEP: some comments
Giovanni Bajo wrote: >>ctime should be provided to report whatever ctime used to report in >>the past (i.e. creation_time on Windows, status_change_time on Unix). > > > In other words, if there are mistakes in the old API, this is the time to > fix them. Why should we carry them over to a new API? I'm not talking about all API in general, I'm talking about ctime specifically. People will ask "where is ctime?", and it better be where they think it should be. I don't see a point in confusing users. (Plus, there might be systems that associate yet a different meaning with ctime - it is just our guess that it means "status change time"). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
On Sat, 04 Feb 2006 11:11:08 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote: >Bengt Richter wrote: >>>The typical way of processing incoming ints in C is through >>>PyArg_ParseTuple, which already has the code to coerce long->int >>>(which in turn may raise an exception for a range violation). >>> >>>So for typical C code, 0x8004 is a perfect bit mask in Python 2.4. >> >> Ok, I'll take your word that 'k' coercion takes no significant time for >> longs vs ints. > >I didn't say that 'k' takes no significant time for longs vs ints. In >fact, I did not make any performance claims. I don't know what the >relative performance is. Sorry, I apologize for putting words in your mouth. > >> Well, I was visualizing having a homogeneous bunch of bit mask >> definitions all as int type if they could fit. I can't express >> them all in hex as literals without some processing. That got me started ;-) > >I still can't see *why* you want to do that. Just write them as >hex literals the way you expect it to work, and it typically will >work just fine. Some of these literals are longs, some are ints, >but there is no need to worry about this. It will all work just >fine. Perhaps it's mostly aesthetics. Imagine that I was a tile-setter and my supplier had an order form where I could order square glazed tiles in various colors with dimensions in multiples of 4cm, and I said that I was very happy with the product, except why does the supplier have to send stretchable plastic tiles whenever I order the 32cm size, when I know they can be made like the others? (Granted that the plastic works just fine for most uses ;-). I have to admit the price for supplies is unbeatable, and that the necessary kit for converting 32cm plastic to ceramic was also supplied, but still, if one can order ceramic at all, why not the full range? Especially since if one orders the 32cm size in another dialect one can get it without having to use the conversion kit, e.g., >>> -2147483648 -2147483648 but >>> -0x8000 -2147483648L >>> int(-0x8000) -2147483648 ;-) That minus seems to bind differently in different literal dialects, e.g. to make the point clearer, compare with above: >>> -2147483648 -2147483648 >>> -(2147483648) -2147483648L > >> BTW, is long mandatory for all implementations? Is there a doc that >> defines minimum features for a conforming Python implementation? > >The Python language reference is typically considered as a specification >of what Python is. There is no "minimal Python" specification: you have >to do all of it. Good to know, thanks. Sorry to go OT. If someone wants to add something about supersetting and pypy's facilitation of same, I guess that belongs in another thread ;-) Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path PEP: some comments
On Sun, February 5, 2006 13:57, "Martin v. Löwis" wrote: > I think the path module should provide these under a different name: > creation_time and status_change_time. Either of these might be absent. +1. This is exactly what I proposed, in fact. > ctime should be provided to report whatever ctime used to report in > the past (i.e. creation_time on Windows, status_change_time on Unix). As I stated in my mail, I don't agree that there needs to be such a strict compatibility between methods in the new Path class and functions in the old os.path (or other) modules. Some consistency will ease the transition of course, but there is absolutely no need to provide a 1:1 mapping. Old code will continue to work, and new code might adapt to a new (possibly) better API. Given the confusion with 'ctime', I don't think that providing it in the new Path class would be a good move. It's better to force people to explicitally name what they're asking for (either creation_time or status_change_time). In other words, if there are mistakes in the old API, this is the time to fix them. Why should we carry them over to a new API? Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes patch (was: (libffi) Re: Copyright issue)
Hye-Shik Chang wrote: > Thomas and I collaborated on integration into the ctypes repository > and testing on various platforms yesterday. My patches for Python > are derived from ctypes CVS with a change of only one line. Not sure whether you think you need further approval: if you are ready to check this into the Python trunk, just go ahead. As I said, I would prefer if what is checked in is a literal copy of the ctypes CVS (as far as reasonable). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] any support for a methodcaller HOF?
Nick Coghlan wrote: > I guess my point is that expressions are appropriate sometimes, functions are > appropriate other times, and it *is* possible to give reasonably simple > guidelines as to which one is most appropriate when (one consumer->deferred > expression, multiple consumers->named function). I don't think this guideline is really valuable. If you transfer this to variables, you would get "one reader -> inline expression, multiple readers -> named variable". This is clearly wrong: it is established practice to use local variables even if there is only one access to the variable, if creating the variable improves readability of the code (e.g. if the expression is very complex). For functions, the same should hold: if it improves readability, make it a local function. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path PEP: some comments
Terry Reedy wrote: >>Note that this is the opposite of normal Python policy: Python does not >>attempt to create cross-platform abstractions, but instead chooses to >>expose platform differences. > > > I had the opposite impression about Python -- that it generally masks such > differences. I think it is both ways. For counter-examples, consider GUIs: Python does *not* attempt to provide a cross-platform GUI library (Tk tries that, but that is a different story). It also exposes os.lstat on systems that provide it, but doesn't try to emulate it on systems which don't. Likewise, there is a module linuxaudiodev which is only useful on some systems, and winsound, which is only useful on others. So first of all, Python exposes the platform API as-is, and doesn't try to "correct" things that it thinks the system got "wrong", or forgot to implement. On top of that, you have layers which try to mask differences, e.g. the os module or the subprocess module. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path PEP: some comments
Phillip J. Eby wrote: >>- ctime() is documented to be unportable: it has different semantics on UNIX >>and Windows. I believe the class should abstract from these details. > > > Note that this is the opposite of normal Python policy: Python does not > attempt to create cross-platform abstractions, but instead chooses to > expose platform differences. The Path class shouldn't abstract this any > more than the original *path modules do. I think this is partially due to a misunderstanding, both by Microsoft, and in Python. There is a long-time myth that ctime denotes "creation time", as this is really in-line with mtime and atime. I think the path module should provide these under a different name: creation_time and status_change_time. Either of these might be absent. ctime should be provided to report whatever ctime used to report in the past (i.e. creation_time on Windows, status_change_time on Unix). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path PEP and the division operator
Nick Coghlan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Duncan Booth wrote: >> I'm not convinced by the rationale given why atime,ctime,mtime and >> size are methods rather than properties but I do find this PEP much >> more agreeable than the last time I looked at it. > > A better rationale for doing it is that all of them may raise > IOException. It's rude for properties to do that, so it's better to > make them methods instead. Yes, that rationale sounds good to me. > > That was a general guideline that came up the first time adding Path > was proposed - if the functionality involved querying or manipulating > the actual filesystem (and therefore potentially raising IOError), > then it should be a method. If the operation related solely to the > string representation, then it could be a property. Perhaps Bjorn could add that to the PEP? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
