Re: [Python-Dev] os.access and Unicode
Skip Montanaro wrote: I say backport. If people were trying to call os.access with unicode filenames it would have been failing and they were either avoiding unicode filenames as a result or working around it some other way. I can't see how making os.access work with unicode filenames is going to break existing code. The question is whether it would encourage conditional work-arounds. If people will put into their code if sys.version_info (2,4,2): import os, sys def new_access(name, mode, old_access = os.access): try: return old_access(name, mode) except UnicodeError: return old_access(name.encode( sys.getfilesystemencoding()), mode) os.access = new_access then backporting does not improve anything. OTOH, if people are likely to say yes, this was a bug in 2.4.0 and 2.4.1, you need atleast 2.4.2, backporting will help. 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] os.access and Unicode
Martin v. Löwis wrote: Skip Montanaro wrote: I say backport. If people were trying to call os.access with unicode filenames it would have been failing and they were either avoiding unicode filenames as a result or working around it some other way. I can't see how making os.access work with unicode filenames is going to break existing code. The question is whether it would encourage conditional work-arounds. -1. That only makes the code more complicated. If people will put into their code if sys.version_info (2,4,2): import os, sys def new_access(name, mode, old_access = os.access): try: return old_access(name, mode) except UnicodeError: return old_access(name.encode( sys.getfilesystemencoding()), mode) os.access = new_access then backporting does not improve anything. OTOH, if people are likely to say yes, this was a bug in 2.4.0 and 2.4.1, you need atleast 2.4.2, backporting will help. +1. Application writers can add tests for the correct version of Python to their application and give a warning to the user in case the version doesn't match. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Adding any() and all()
Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of (all) things. In my mind it doesn't make sense (yet) that all(seq) returns true if all elements of seq is true and false otherwise, I would have expected all to return a list. any is better because it is very obvious it can only return one thing. -- mvh Björn ___ 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] Adding any() and all()
On Fri, 11 Mar 2005 11:30:38 +0100, BJörn Lindqvist [EMAIL PROTECTED] wrote: Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of (all) things. In my mind it doesn't make sense (yet) that all(seq) returns true if all elements of seq is true and false otherwise, I would have expected all to return a list. any is better because it is very obvious it can only return one thing. Using any and all as variables hides the builtins, but doesn't disallow their use elsewhere. Personally, though, I wouldn't use any or all as variable names, so that's a style issue. As far as the names making sense is concerned, they are perfect in context: if all(i 0 for i in int_list): if any(invalid(s) for s in input_values): While you may think that use in any other context looks a little less natural (something I'm not convinced of), in the intended context, the names seem ideal to me. 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] os.access and Unicode
Martin v. Löwis wrote: M.-A. Lemburg wrote: The question is whether it would encourage conditional work-arounds. -1. That only makes the code more complicated. You misunderstand. I'm not proposing that the work-around is added to Python. I'm saying that Python *users* might introduce such work-arounds to their code. Ah, ok. Either way, the code get's more complicated :-) +1. Application writers can add tests for the correct version of Python to their application and give a warning to the user in case the version doesn't match. Application writers typically don't do that if they can find a work-around, because that means less hassle for their users. They accept that the code will get more complicated because of the work-around, and blame Python for having this bug in the first place. Hmm, eGenix always suggests to people to use the latest patch level release, esp. for production systems, not only for Python itself, but also for the products. Zope Corp. does the same, as do many other application writers. The only time where we do add work-arounds is for changes between minor Python versions in order to make the same code base work for multiple Python versions, but that's rare. In any case, I can't backport the os.access change without explicit permission from Anthony. Agreed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Adding any() and all()
On Fri, 11 Mar 2005, Paul Moore wrote: Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of Using any and all as variables hides the builtins, but doesn't disallow their use elsewhere. Personally, though, I wouldn't use any or all as variable names, so that's a style issue. Even though you can use them as variables (and shadow the builtins), you will still get warnings from pychecker. The code will also be harder to read: When you see all in the middle of some code, you don't know if it's referring to the builtin or a variable. Personally, I think Python has too many builtins already. /Peter Åstrand [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] Adding any() and all()
Peter Astrand wrote: On Fri, 11 Mar 2005, Paul Moore wrote: Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of Using any and all as variables hides the builtins, but doesn't disallow their use elsewhere. Personally, though, I wouldn't use any or all as variable names, so that's a style issue. Even though you can use them as variables (and shadow the builtins), you will still get warnings from pychecker. The code will also be harder to read: When you see all in the middle of some code, you don't know if it's referring to the builtin or a variable. Personally, I think Python has too many builtins already. to extend the naming pool, FWIW CL calls similar things EVERY and SOME. ___ 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] Adding any() and all()
And why not use the names already in use in numarray/Numeric ? They are called sometrue and alltrue ... IMHO, it explicits more what it means : alltrue(i5 for i in l) sometrue(i5 for i in l) Another point is: as I agree there is already a huge lot of builtins, shouldn't it be in some module ? Perhaps in itertools ? Pierre PS: It's my first post on the list, even if I'm reading it for a few months now ^_^ Peter Astrand a écrit : On Fri, 11 Mar 2005, Paul Moore wrote: Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of Using any and all as variables hides the builtins, but doesn't disallow their use elsewhere. Personally, though, I wouldn't use any or all as variable names, so that's a style issue. Even though you can use them as variables (and shadow the builtins), you will still get warnings from pychecker. The code will also be harder to read: When you see all in the middle of some code, you don't know if it's referring to the builtin or a variable. Personally, I think Python has too many builtins already. /Peter Åstrand [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/pierre.barbier%40cirad.fr -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77fax : (33) 4 67 61 56 68 ___ 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] RELEASED Python 2.4.1, release candidate 1
[Martin v. Löwis] I'd like to encourage feedback on whether the Windows installer works for people. It replaces the VBScript part in the MSI package with native code, which ought to drop the dependency on VBScript, but might introduce new incompatibilities. [Tim Peters] Worked fine here. Did an all-default all users install, WinXP Pro SP2, from local disk, and under an account with Admin rights. I uninstalled 2.4 first. I suppose that's the least stressful set of choices I could possibly have made, but at least it confirms a happy baseline. I tried several stranger things, like installing over 2.4.0 but in a different directory. Everything worked like clockwork. I did NOT try anything that would have involved a system with various things missing (like lack of VBScript), but I did play around with alternate install locations, repairs, uninstalls, single-user and all-user installs, and I found no problems anywhere. Nice work! -- Michael Chermside ___ 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] Adding any() and all()
Peter Astrand wrote: Personally, I think Python has too many builtins already. A suggestion was made on c.l.p a while back to have a specific module dedicated to reductive operations. That is, just as itertools is oriented towards manipulating iterables and creating iterators, this module would be oriented towards consuming iterators in a reductive fashion. product(), anytrue() and alltrue() were obvious candidates for inclusion ([1]). The combination of explicit for loops and a standard toolkit of reductive operations was designed to eliminate the need for reduce() ([2]). Cheers, Nick. [1] While any()/all() read well in the context of an if statement, I think anytrue()/alltrue() better convey the reductive nature of the operations, read nearly as well in the if context, and read significantly better when isolated from the if context (e.g. assigned to a variable). I also think the names are less likely to collide with existing variable names. [2] I'm firmly in Guido's camp on this one - whenever I encounter code that uses reduce(), I have to rewrite it (either mentally or literally) to use a for loop before I can understand it. Getting rid of the function would benefit me because I would no longer have to waste time figuring out what such code was doing - it would already be an explicit loop, or it would be using one of the standard reductive operations. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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] LinkedHashSet/LinkedHashMap equivalents
Anthony Baxter wrote: On Thursday 10 March 2005 17:29, Raymond Hettinger wrote: Or the implementation can have a switch to choose between keep-first logic or replace logic. The latter seems a bit odd to me. The key position would be determined by the first encountered while the value would be determined by the last encountered. Starting with [(10, v1), (20, v2), (10.0, v3)], the ordered dictionary's items would look like [(10, v3), (20, v2)]. Or, alternately, we keep the last occurence, and move it to the new position. There's a wide number of different use cases, each with a slightly different final result, and for this reason alone I'm -0 on it for the library. Anthony But surely such use cases could be more easily handled by subclassing from collections.OrderedDict and tweaking the semantics than by having to implement an ordered mapping from scratch. Would the default semantics below really be that suprising? An ordered dictionary remembers the order in which keys are first seen and, when iterated over, returns entries based on that order. This applies to direct iteration, iteration over values and (key, value) pairs, to the list-producing methods (i.e. keys(), values() and items()) and to any other operations that involve implicit iteration (e.g. converting to a string representation). Overwriting an entry replaces its value, but does not affect its position in the key order. Removing an entry (using 'del') _does_ remove it from the key order. Accordingly, if the entry is later recreated, it will then occur last in the key order. This behaviour is analagous to that of a list constructed using only list.append() to add items (indeed, the key order can be thought of as a list constructed in this fashion, with keys appended to the list when they are first encountered). An ordered dictionary provides a sort() method. The sort operation is applied to the key ordering and affects future iteration over the dictionary. Again, this is analagous to sorting a list. For instance, to convert a standard dictionary to an ordered dictionary using a specific key function: x = collections.OrderedDict(sorted(d.itervalues(), key=keyfunc)) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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] Adding any() and all()
[ Pierre Barbier de Reuille ]: They are called sometrue and alltrue ... IMHO, it explicits more what it means : alltrue(i5 for i in l) sometrue(i5 for i in l) +1 [ from a comment in GvR's blog ] Why not, if True in (x 42 for x in S): instead of any and why not if not False in (x 42 for x in S): instead of all? Because any and all have shortcut semantics (they return as soon as they can determine the final result). [ Guido ]: -- See my blog: http://www.artima.com/forums/flat.jsp?forum=106thread=98196 Do we even need a PEP ? In the absence of a PEP, soon will see in c.l.p discussions like: For completeness sake shouldn't there be a optimiztion version for nonetrue() ? def nonetrue(S): for x in S: if x: return False return True why not allfalse() ? Due to the previous use of sometrue(), guess it becomes easier to remeber nonetrue() than allfalse(). One may argue for aliasing(nonetrue, allfalse), and we are back to _builtin pollution_. So, people might fallback to any() and all(),realising that: '''not all()''' meaning somefalse() '''not any()''' meaning nonetrue()==allfalse() All I'm saying: +1 for the PEP. OFF-TOPIC: It is curious though that we choose to read an *implicit* True in [all(), any()] instead of an implicit False. I guess that is a moral or ethical choice coming from the Human realm, favouring Truth instead of Falsity. But that difference does not hold in the Boolean realm wink. best regards, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ 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] rationale for the no-new-features approach
On Thu, 2005-03-10 at 23:46, Glyph Lefkowitz wrote: That way instead of multi-line except NameError tests all over the place you can simply have one-liner boilerplate for every module in your project: 'from py24compat import *' Easy to grep/sed for when you're ready to stop supporting old versions, too, for those of you without a copy of the refactoring editor from the 2009 release of PyDev/Eclipse. I do something very similar, both for Mailman and for the commercial products I'm working on. There are lots of ways to handle this kind of thing, and there might be some value in a community effort to work together and standardize this. IWBNI there were some common idioms and packages that people could use. Having said that... The only problem with this idea is that the 2.3 - 2.4 transition has been extremely smooth for me - there are no new features I desperately want to use, and there are no old features that were deprecated or altered (that I've found yet - knock on wood). Still, future incompatibilties are inevitable. ...I agree. We just upgraded to 2.4 internally and it went embarrassingly smoothly. Had to find something else to do with the four days (cough - warsaw's first law - cough) we'd scheduled for that. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Re: @deprecated (was: Useful thread project for 2.5?)
Nick Coghlan wrote: Raymond Hettinger wrote: Decorators like this should preserve information about the underlying function: def deprecated(func): This is a decorator which can be used to mark functions as deprecated. It will result in a warning being emmitted when the function is used. def newFunc(*args, **kwargs): warnings.warn(Call to deprecated function.) return func(*args, **kwargs) newFunc.__name__ = func.__name__ newFunc.__doc__ = func.__doc__ newFunc.__dict__.update(func.__dict__) return newFunc A utility method on function objects could simplify this: newFunc.update_info(func) +1. This is really good for 90% of all decorator uses. But maybe a better name should be found, perhaps update_meta. Reinhold -- Mail address is perfectly valid! ___ 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] Adding any() and all()
BTW I definitely expect having to defend removing map/filter/reduce/lambda with a PEP; that's much more controversial because it's *removing* something and hence by definition breaking code. I suspect that lambda will be the only bone of contention. The reduce() function can be moved to the functional module. The map() and filter() functions are already covered by the itertools module. Lambda will be more difficult. Eric Raymond adapted an anti-gun control slogan and said you can pry lambda out of my cold dead hands. A bunch of folks will sorely miss the ability to create anonymous functions on the fly. When lambda is used for deferred argument evaluation (a la PEP 312), the def syntax is a crummy substitute. PS in the blog responses, a problem with sum() was pointed out -- unless you use the second argument, it will only work for numbers. Now that string concatenation is apparently O(N) rather than O(N**2) (is that right, Raymond?) maybe this could be revised. str.join() is still the best practice for string concatenation. Armin's optimization doesn't appear in other implementations of Python. In CPython, it has a set of pre-conditions that are usually but not always True. IIRC, it also doesn't apply to Unicode and ASCII mixed with Unicode. Also, the optimization is part of ceval.c and would not be triggered by sum()'s call to PyNumber_Add(). That limitation is not easily removed because the optimization depends on an interaction between the stack, variable refcounts, and the sequence of opcodes. IOW, your original pronouncement on the subject should remain in effect. 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] Adding any() and all()
Raymond Hettinger wrote: BTW I definitely expect having to defend removing map/filter/reduce/lambda with a PEP; that's much more controversial because it's *removing* something and hence by definition breaking code. +1 on the PEP -1 on removing those tools - breaks too much code. I suspect that lambda will be the only bone of contention. The reduce() function can be moved to the functional module. The map() and filter() functions are already covered by the itertools module. Nope. Think of the side-effects that can occur as a result of calling the function argument n times with different arguments. itertools only help if the functions don't have side-effects. Iteration is nice, but not the solution to everything :-) Lambda will be more difficult. Eric Raymond adapted an anti-gun control slogan and said you can pry lambda out of my cold dead hands. A bunch of folks will sorely miss the ability to create anonymous functions on the fly. When lambda is used for deferred argument evaluation (a la PEP 312), the def syntax is a crummy substitute. While I'm no fan of lambdas either, the removal would break too much code (e.g. I have 407 hits in the code base I use regularly alone). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Adding any() and all()
On Mar 11, 2005, at 17:28, Guido van Rossum wrote: PS in the blog responses, a problem with sum() was pointed out -- unless you use the second argument, it will only work for numbers. Now Why is that a *problem*? It solves the end case (if the sequence is empty which you mention for any() and all() [[indeed, I think a similar approach to any and all might be best: have them return an item from the sequence, an empty sequence uses the optional second item defaulting to something reasonable -- 0 for sum, False for any, True for all, for example]] in a neatly explicit way. As I recall, I had tried to handle non-empty sequences by picking the first item and doing following + on it (with internal implementation specialcasing for strings, to avoid an attractive nuisance situation), and you cut the gordian knot by pronouncing about the second argument with a default of 0 (I immediately thought your pronouncement was excellent and I still can't see why it wouldn't be). Forcing the user to provide a 2nd arg when summing a sequence of non-numbers (say, datetime.timedelta instances, that's one example that ended up in the 2nd ed Cookbook) is good because it ensures a good return value when the sequence is empty (say, timedelta(0) rather than 0 as a number). If you're considering revisions to sum's design, my suggestion would be to find a way to let the user tell sum to use a more accurate approach when summing floats. Summing a million floats with a loop of total+=item loses a LOT of accuracy (several digits' worth!) -- but doing the summation the right way takes O(N) auxiliary temporary space, so both approaches (the naive, performance-optimized accuracy disaster, and the expensive but accurate one) should ideally be available. An optional use_partials keyword argument defaulting to False, for example, might allow that... (again, I've hopefully clarified the issues in another 2nd ed Cookbook recipe, I guess I can post that if it helps). Alex ___ 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] sum()
[Alex] If you're considering revisions to sum's design, my suggestion would be to find a way to let the user tell sum to use a more accurate approach when summing floats. FWIW, when accuracy is an issue, I use: sum(sorted(data, key=abs)) 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] Adding any() and all()
On Mar 11, 2005, at 18:18, Raymond Hettinger wrote:
str.join() is still the best practice for string concatenation.
...except you actually need unicode.join if the strings are of that
kind. Fortunately, ''.join intrinsically compensates:
x=[u'\u0fe0']*2
''.join(x)
u'\u0fe0\u0fe0'
*without* (as one would expect) the GD nuisance of converting x's items
to str (hellishly hard to document accurately and clearly, but
extremely convenient!-).
Which reminds me -- could we have a methodcaller relative to attrgetter
and itemgetter? Sort a list of strings in a case-insensitive way
would become *SO* easy with sort(dalist, key=methodcaller('lower'))...
can't REALLY recommend sort(dalist, key=str.lower) then the items of
dalist MIGHT be either str or unicode items... (the relevance of
''.join is that it proves SOMEbody considered it important to deal with
a list of either str or unicode in the joining context... why not in
the sorting context then?).
Alex
___
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] sum()
On Mar 11, 2005, at 19:39, Raymond Hettinger wrote: [Alex] If you're considering revisions to sum's design, my suggestion would be to find a way to let the user tell sum to use a more accurate approach when summing floats. FWIW, when accuracy is an issue, I use: sum(sorted(data, key=abs)) ...and you may still lose a LOT of accuracy that way:-(. Raymond, you technically reviewed the 2nd ed Cookbook -- don't you recall the sidebar about why partials are the RIGHT way to do summations? I was SO proud of that one, thought I'd made the issue clearest than anywhere previously in print... To summarize: as we all know, a+b loses significant digits from (say) b when abs(a) is much larger than abs(b). Now, say we're summing a million numbers, all positive and roughly the same magnitude. If we do it by total += item (which is basically what sum does), by the time we've summed the first 100,000 or so total IS *much larger than item* in absolute value -- we're systematically tossing away about 5 digits from each new item by that time!!! To avoid such a massacre of digits, one uses partials -- summing items two at a time to get half as many partials, then iterating that idea about log2(N) times when summing N items. Problem is, one needs O(N) auxiliary space (assuming one can't just overwrite the incoming list/array/whatever). There's all other kinds of accuracy issues with a+b, but the one partials-based summation deals with is numero uno in many real-life situations, e.g. when one needs to get (say) the total area from N regions, each of roughly the same magnitude, whose areas were separately measured -- total length from N segments ditto -- total mass of N items ditto -- and so forth. Alex ___ 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] Adding any() and all()
On Fri, 2005-03-11 at 14:29, Jim Jewett wrote: Is that so bad? If you plan to use them often, then from itertools import any, every +1 -Barry signature.asc Description: This is a digitally signed message part ___ 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] Adding any() and all()
[Guido van Rossum] But I realized (1) any() and all() read much better in their natural context (an if statement), and there's no confusion there; I do not think builtins should read good in some statement contexts and bad in the others, or designed to be legible in only a few contexts. This would be a waste. In other contexts dans `if' or `while', `any(...)' might be read as pick one of, in which case a True/False result might be surprising. `allTrue' (or such) is clearer in all contexts, even if not as nice in some of them. For `any(...)' to be clear in all contexts, it should return one of its arguments. That would surely do the proper thing in `if' or `while' context. We've read various arguments about this idea. Some (pro or con) arguments are only valid outside `if' and `while' context, other (pro and con) arguments are only valid within `if' and `while' context. If we are going to dismiss contexts outside `if' and `while', we should not retain arguments which only apply outside those contexts. This is my only complain. The overall idea and principle are good, especially if they succeed in cleaning out `reduce' and the others. However, if for compatibility reasons, `reduce' stays, than we are merely adding other ways, without sparing any, and this means yet another tiny bloat in Python, that might be better avoided. What worries me a bit about doing a PEP for this simple proposal is that it might accidentally have the wrong outcome: Isn't that true of any PEP? I thought going through a PEP for changes, and additions just as well, was not far from being a principle. Depending on opinions, the outcome is right or wrong. The principle of PEPs is not necessarily a good one in practice, as some PEPs are forever incomplete or unupdated, miss their role, and then sum up to having nearly been an annoyance. Good if PEPs may be avoided! :-) -- François Pinard http://pinard.progiciels-bpi.ca ___ 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] Adding any() and all()
Jim Jewett wrote: Guido van Rossum: [Why any() and all() shouldn't need to be imported.] Is that so bad? If you plan to use them often, then from itertools import any, every is reasonable. If you only use them once and weren't expecting it (and want your imports at the top) ... well how awful is it to have an extra line or two in your code? The problem with this approach is that any() and all() are so fundamental* that you should just use them without thinking about it, just as when you use + to conctenate strings, you don't have to stop and think to yourself, Ah, this program needs to be able to manipulate strings. I'd better make sure string operations as available in this module. Thinking such thoughts takes you away from thinking about the problem you're trying to solve by manipulating strings. Likewise, programmers solve a lot of problems with boolean expressions, and it seems silly to require a special declaration just to make the full complement of boolean operations available. I can think of three ways of coping with any() and all() being in a module: First, I could just not use them. In that case all the effort here is wasted, and my code becomes less readable than it would have been otherwise. This is the approach I usually take with modules like operator, where I can just as easily write a lambda expression (for now at least). Second, I could break my concentration to think about import statements every time I have a use for these particular functions. Third, I could import them at the top of every module. Since one of the distinguishing features of Python in a lack of gratuitous boilerplate code everywhere, I would find it very sad to add even a little bit. So while putting any() and all() into a module isn't that bad in itself, it seems like the start of a slippery slope that has Python at the top and C++ at the bottom. -- jw *I appreciate the irony of calling something fundamental when we've all gotten by just fine without it for many years--I'm trying to think from the perspective of someone used to dealing with a later (and hopefully better) version of Python. ___ 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] code blocks using 'for' loops and generators
I would like to get some feedback on a proposal to introduce
smalltalk/ruby-like code blocks to python. Code blocks are, among other
things, a clean way to solve the acquire/release problem [1][2]. This
proposal also touches on some of the problems PEP 288 [3] deals with.
The best discussion I have been able to find on this topic is in the
thread of ref. [4].
Since generators, when used with 'for' loops, are so similar to code
blocks [5], one can imagine two ways to implement code blocks in python:
(1, parallel) keep them as similar as possible to 'for' loops so that a
normal user doesn't distinguish the two, or (2, orthogonal) make them so
much different than 'for' loops that the normal user doesn't notice the
similarities. Anything between these extremes will probably be confusing.
Here I will describe an attempt at (1).
(I) Give generators a __call__ method as an alternative to 'next'.
Method __call__ should take a single parameter: a function. Using
__call__ will cause the generator to start executing normally, but when a
'yield' is reached, the generator will invoke the function passed to
__call__ instead of activating the currently implemented 'yield'
mechanism.
Since __call__ will be an alternative to 'next', it will raise an
exception if 'next' has already been called and vice-versa. Also, any
calls to 'next' will raise an exception if there is a 'yield' in the try
of a try/finally. Such yields will no longer trigger a SyntaxError
because they will not a problem when using __call__.
(II) Have a method of generators, __blockcall__, which will be equal to
__call__, but will only exist if (1) the generator contains a try/finally
try yield, or (2) the user explicitly defines it, for example, with a
function decorator (@completion_required would be a descriptive name).
Have 'for' loops use __blockcall__ if it is available, and __iter__
otherwise. Pass to __blockcall__ the block of code in the 'for' loop.
Scope rules for the passed block of code should mimic current 'for' loop
behavior. Behavior of 'break' and 'return' should be mimicked, perhaps
with special exceptions catchable only by the 'for' loop. Mimicking
'yield' will be a problem unless/until multi-level yields are allowed.
(performance and implementation difficulties for all of this? I don't
know).
The thunk shouldn't be savable for later use because the 'for' loop will
no longer be around to deal with 'break' and 'return'. This means that
__blockcall__ will not be implementable as a function that takes a
function as an argument.
(III) Allow 'continue' to pass values to 'yield' (something similar
previously rejected here [6]). As far as I know, all other control
statements that transfer execution to a different frame (yield, return,
raise) pass values, and I don't see why this case should be any different.
I do not see such a mechanism as gimmicky; being able to cleanly pass
values when changing scope is an inherent part of nearly every programming
language.
As an example of the syntax I am suggesting, here is something I was
desiring recently, a generator to open, unpickle, repickle and close a
file:
def pickled_file(name):
f = open(name, 'r')
l yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(l, f)
f.close()
The unpickled object is sent to the caller at the yield statement, and the
modified object is received back at the same statement. Note the
suggested 'yield' syntax and the conspicuous absence of '='. This syntax
is backwardly compatible with current yield syntax. Also, this syntax
does not require yield to appear as a function; it is still clear that
this is a unique control-flow statement.
This function would be used like this:
for l in pickled_file('greetings.pickle'):
l.append('hello')
l.append('howdy')
continue l
The above code would have the same effect as:
def named(l):
l.append('hello')
l.append('howdy')
return l
pickled_file('greetings.pickle')(named)
(IV) Allow 'yield' to return no value; in this case a new keyword,
'with', will be required instead of an awkward 'for':
with f(): instead of for in f():
(V) For the same reasons as in (III), allow generators to return values.
These values can be sent with the StopIteration exception if 'next' is
being used for iteration. An obvious syntax for receiving these values is
shown by this example:
with dt = stopwatch():
f()
g()
print 'it took', dt, 'seconds'
Although with stopwatch() result dt: might not be so bad.
[1] PEP 310 Reliable Acquisition/Release Pairs
http://www.python.org/peps/pep-0310.html
[2] PEP 325 Resource-Release Support for Generators
http://www.python.org/peps/pep-0325.html
[3] PEP 288 Generators Attributes and Exceptions
http://www.python.org/peps/pep-0288.html
[4] http://mail.python.org/pipermail/python-dev/2003-February/032800.html
[5]
Re: [Python-Dev] operator.methodcaller
On Mar 11, 2005, at 2:02 PM, Steven Bethard wrote:
On Fri, 11 Mar 2005 19:48:45 +0100, Alex Martelli [EMAIL PROTECTED]
wrote:
Which reminds me -- could we have a methodcaller relative to
attrgetter
and itemgetter? Sort a list of strings in a case-insensitive way
would become *SO* easy with sort(dalist, key=methodcaller('lower'))...
can't REALLY recommend sort(dalist, key=str.lower) then the items of
dalist MIGHT be either str or unicode
I'd like to second this suggestion -- I've run into this problem a few
times. When you're using a listcomp or genexp, you can inline it of
course, but especially with a lot of functions growing the incredibly
convenient key= arguments in 2.5 (e.g. min, max and the deque
functions if I recall correctly), methodcaller would be a much more
duck-typing friendly way to create such callables.
Yeah, if *only* we had some way to create callables in a nice, short,
generic, and easy to understand way.
How about this proposal:
sort(dalist, key=lambda x: x.lower())
Who wants to make a PEP for it? Maybe we can add it in Python 3000.
James
___
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] sum()
[Alex] FWIW, when accuracy is an issue, I use: sum(sorted(data, key=abs)) ...and you may still lose a LOT of accuracy that way:-(. Raymond, you technically reviewed the 2nd ed Cookbook -- don't you recall the sidebar about why partials are the RIGHT way to do summations? I was SO proud of that one, thought I'd made the issue clearest than anywhere previously in print... No doubt about it. Partials are superior. My little snippet meets my needs with no fuss -- my usual situation is many small values whose accuracy gets clobbered upon encountering a handful of large values. In the draft statistics module, nondist/sandbox/statistics/statistics.py , I used yet another approach and tracked a separate error term. The advantage is adding precision while still keeping O(n) summation speed. Of course, we can always use the decimal module to add as much precision as needed. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] distutils fix for building Zope against Python 2.4.1c1
http://mail.python.org/pipermail/python-checkins/2005-March/045185.html Note that I also could not build PyWin32 against 2.4.1c1 and I suspect this was the same problem. (Still checking to see if this change fixes the PyWin32 build for me.) In any case, this change should also make it to the trunk, right? Trent -- Trent Mick [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] rationale for the no-new-features approach
Bob try: Bob set Bob except NameError: Bob from sets import Set as set Bob You don't need the rest. Sure, but then pychecker bitches about a statement that appears to have no effect. ;-) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rationale for the no-new-features approach
On Mar 11, 2005, at 2:26 PM, Skip Montanaro wrote: Bob try: Bob set Bob except NameError: Bob from sets import Set as set Bob You don't need the rest. Sure, but then pychecker bitches about a statement that appears to have no effect. ;-) Well then fix PyChecker to look for this pattern :) -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] distutils fix for building Zope against Python 2.4.1c1
[Trent Mick wrote] http://mail.python.org/pipermail/python-checkins/2005-March/045185.html Note that I also could not build PyWin32 against 2.4.1c1 and I suspect this was the same problem. (Still checking to see if this change fixes the PyWin32 build for me. ... It doesn't. Investigating... Trent -- Trent Mick [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] Adding any() and all()
Guido van Rossum wrote: Here's my take on the key issues brought up: Alternative names anytrue(), alltrue(): before I posted to my blog I played with these names (actually anyTrue(), allTrue(), anyFalse(), allFalse()). But I realized (1) any() and all() read much better in their natural context (an if statement), and there's no confusion there; (2) anyFalse() and allFalse() are redundant, so there's no need to distinguish between anyTrue() and anyFalse(). (To the person who wondered why we default to True: because 'if' tests for True, duh. :-) I've been using exists() and forall() in mxTools for years. The names originate from math usage, where you often use these qualifiers. A note on builtins: Most tools in mxTools automatically get registered as builtins when you load the module. The motivation for this was that wanted to have easy access to these often used APIs. However, a few years down the line I realized that this kind of usage just causes confusion when you read code: * it is not clear where the APIs originate * the code dependencies are not longer easily visible Ever since, I've switched to making all use of these functions explicit with reference to the mx.Tools module. http://www.egenix.com/files/python/mxTools.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 12 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] comprehension abbreviation (was: Adding any() and all())
Jim Jewett wrote: Note that the last x shouldn't have to be x. [x in seq if f(x)] is by far my most common syntax error, and [x for x in seq if f(x)] is always what I want instead. That 'x in seq' bit still shouts containment to me rather than iteration, though. Perhaps repurposing 'from': (x from seq if f(x)) That rather breaks TOOWTDI though (since it is essentially new syntax for a for loop). And I have other hopes for the meaning of (x from ()). . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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] Python2.4.1c1 and win32com
Hi, Win32com generates Python-files for use with com interfaces, using the make-py.py utility. The generated files are OK with Python2.3.5 The generated files crash the Python interpreter with Python 2.4 Under Python 2.4.1c1, They give a syntax error!? The files unfortunately are very big, nearly 2Mb each, although they compress very well (270Kb). The errors given are for one file: D:\Python24\lib\site-packages\win32com\gen_py\00020905---C000-0046x0x8x1.py, line 3025 StyleName: (3, 2, (8, 0), (), StyleName, None), Value: (0, 2, (8, 0), (), Value, None), ^ SyntaxError: invalid syntax (The marker is in the middle of 'None') And for the other file: File D:\Python24\lib\site-packages\win32com\gen_py\00020813---C000-0046x0x1x3.py, line 2591 return ret ^ SyntaxError: invalid syntax At least the interpreter no longer crashes, but I'm very surprised that this gives syntax errors when the exact same files do compile with Python 2.3.5 (To be sure, I generated the files using Python2.3.5, then copied them to the 2.4.1c1 installation, and then tried to have them compiled.) Eyeballing the files, I can definately not see any syntax errors. Anyone who can help or offer any suggestions? Please CC me on any replies b/c I'm not subscribed to the list. regards, --Tim ___ 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] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2
Anthony Baxter [EMAIL PROTECTED] writes: On Thursday 10 March 2005 03:48, Fred L. Drake, Jr. wrote: RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/idlever.py,v -IDLE_VERSION = 1.1.1 +IDLE_VERSION = 1.1.1c1 Shouldn't this progress from 1.1.1 to 1.1.2c1? Otherwise it's moving backward. No - Py2.4 shipped with idle 1.1. I must've updated it to 1.1.1 sometime after the 2.4 release (I vaguely recall doing this). To eliminate this confusion I'd propose either 1. Eliminating the separate IDLE versioning now that it's installed with Python when Tcl/Tk is available. or 2. Bringing its version in sync with Python 2.5. I'm in favor of the latter, to handle the situation where a customized IDLE is decoupled from Python. -- KBK ___ 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] distutils fix for building Zope against Python 2.4.1c1
[Trent Mick wrote] [Trent Mick wrote] http://mail.python.org/pipermail/python-checkins/2005-March/045185.html Note that I also could not build PyWin32 against 2.4.1c1 and I suspect this was the same problem. (Still checking to see if this change fixes the PyWin32 build for me. ... It doesn't. Investigating... Investigation has turned up that I cannot keep my Python trees straight. That patch *does* fix building PyWin32 against 2.4.1c1. Cheers, Trent -- Trent Mick [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] distutils fix for building Zope against Python 2.4.1c1
[Trent Mick] Investigation has turned up that I cannot keep my Python trees straight. That patch *does* fix building PyWin32 against 2.4.1c1. Good! Please send a check for US$1000.00 to the PSF by Monday wink. ___ 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] Memory Allocator Part 2: Did I get it right?
On Mar 4, 2005, at 23:55, Brett C. wrote: Evan uploaded the newest version (@ http://www.python.org/sf/1123430) and he says it is complete. I should point out (very late! It's been a busy couple of weeks) that I fully expect that there may be some issues with the patch that will arise when it is reviewed. I am still lurking on Python-Dev, and I will strive to correct any defects ASAP. A few users have contacted me privately and have tested the patch, so it works for a few people at least. Evan Jones ___ 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] sum()
FYI, there are a lot of ways to do accurate fp summation, but in
general people worry about it too much (except for those who don't
worry about it at all -- they're _really_ in trouble 0.5 wink).
One clever way is to build on that whenever |x| and |y| are within a
factor of 2 of each other, x+y is exact in 754 arithmetic. So you
never lose information (not even one bit) when adding two floats with
the same binary exponent. That leads directly to this kind of code:
from math import frexp
class Summer:
def __init__(self):
self.exp2sum = {}
def add(self, x):
while 1:
exp = frexp(x)[1]
if exp in self.exp2sum:
x += self.exp2sum.pop(exp) # exact!
else:
break
self.exp2sum[exp] = x # trivially exact
def total(self):
items = self.exp2sum.items()
items.sort()
return sum((x for dummy, x in items), 0.0)
exp2sum maps a binary exponent to a float having that exponent. If
you pass a sequence of fp numbers to .add(), then ignoring
underflow/overflow endcases, the key invariant is that the exact
(mathematical) sum of all the numbers passed to add() so far is equal
to the exact (mathematical) sum of exp2sum.values(). While it's not
obvious at first, the total number of additions performed inside add()
is typically a bit _less_ than the total number of times add() is
called.
More importantly, len(exp2sum) can never be more than about 2K. The
worst case for that is having one input with each possible binary
exponent, like 2.**-1000 + 2.**-999 + ... + 2.**999 + 2.**1000. No
inputs are like that in real life, and exp2sum typically has no more
than a few dozen entries.
total() then adds those, in order of increasing exponent == in order
of increasing absolute value. This can lose information, but there is
no bad case for it, in part because there are typically so few
addends, and in part because that no two addends have the same binary
exponent implies massive cancellation can never occur.
Playing with this can show why most fp apps shouldn't worry most
often. Example:
Get a million floats of about the same magnitude:
xs = [random.random() for dummy in xrange(100)]
Sum them accurately:
s = Summer()
for x in xs:
... s.add(x)
No information has been lost yet (if you could look at your FPU's
inexact result flag, you'd see that it hasn't been set yet), and the
million inputs have been squashed into just a few dozen buckets:
len(s.exp2sum)
22
from pprint import pprint
pprint(s.exp2sum)
{-20: 8.8332388070710977e-007,
-19: 1.4206079529399673e-006,
-16: 1.0065260162672729e-005,
-15: 2.4398649189794064e-005,
-14: 5.3980784313178987e-005,
-10: 0.00074737138777436485,
-9: 0.0014605198999595448,
-8: 0.003361820812962546,
-7: 0.0063811680318408559,
-5: 0.016214300821313588,
-4: 0.044836286041944229,
-2: 0.17325355843673518,
-1: 0.46194788522906305,
3: 6.4590200674982423,
4: 11.684394209886134,
5: 24.715676913177944,
6: 49.056084672323166,
10: 767.69329043309051,
11: 1531.1560084859361,
13: 6155.484212371357,
17: 98286.760386143636,
19: 393290.34884990752}
Add those 22, smallest to largest:
s.total()
500124.06621686369
Add the originals, left to right:
sum(xs)
500124.06621685845
So they're the same to about 14 significant decimal digits. No good
if exact pennies are important, but far more precise than real-world
measurements.
How much does sorting first help?
xs.sort()
sum(xs)
500124.06621685764
Not much! It actually moved a bit in the wrong direction (which is
unusual, but them's the breaks).
Using decimal as a (much more expensive) sanity check:
import decimal
t = decimal.Decimal(0)
for x in xs:
... t += decimal.Decimal(repr(x))
print t
500124.0662168636972127329455
Of course wink Summer's result is very close to that.
___
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] func.update_meta (was: @deprecated)
Reinhold Birkenfeld wrote: Nick Coghlan wrote: A utility method on function objects could simplify this: newFunc.update_info(func) +1. This is really good for 90% of all decorator uses. But maybe a better name should be found, perhaps update_meta. I like update_meta Patch against current CVS added to SF with the behaviour: def update_meta(self, other): self.__name__ = other.__name__ self.__doc__ = other.__doc__ self.__dict__.update(other.__dict__) http://www.python.org/sf/1161819 Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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] Python2.4.1c1 and win32com
On Sat, 12 Mar 2005 15:31:03 +1300, Tony Meyer [EMAIL PROTECTED] wrote: Win32com generates Python-files for use with com interfaces, using the make-py.py utility. The generated files are OK with Python2.3.5 The generated files crash the Python interpreter with Python 2.4 I believe this is a pywin32 bug, which has been fixed in (pywin32) CVS and will be fixed for the next build. It's certainly a probably with 2.4.0 as well as 2.4.1. The pywin32 mailing list archives have more details, as do the tracker for the project: http://sf.net/projects/pywin32. Here is a link to the specific (closed) bug: http://sourceforge.net/tracker/?func=detailaid=1085454group_id=78018atid=551954 And, in case you can't update to the CVS pywin32 for some reason, there is a work-around listed in the bug. Take care, -Brian ___ 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] code blocks using 'for' loops and generators
Brian Sabbey [EMAIL PROTECTED] wrote:
I would like to get some feedback on a proposal to introduce
smalltalk/ruby-like code blocks to python. Code blocks are, among other
things, a clean way to solve the acquire/release problem [1][2]. This
proposal also touches on some of the problems PEP 288 [3] deals with.
[...]
My first reaction to the proposal was ick. Why? Because every time
I've seen a mechanism for modifying the internals of generators
constructed using yield, the syntax has been awful; in my opinion
(whether my opinion means anything is another matter), the syntax you
propose is quite awful, and the functionality you desire does not
require syntax modification to be possible.
Strawman 1: the syntax
def pickled_file(name):
f = open(name, 'r')
l yield pickle.load(f)
^
--
|f.close()
|f = open(name, 'w')
|pickle.dump(l, f)
|f.close()
|
While this is currently a syntax error, it is not clear that an
assignment is happening /at all/, and I don't believe it would be /even
if/ if were documented, and every time someone opened up Python it said
This is an assignment! with an example. It looks too magical to me
(and from a guy who had previously proposed 'Some' as the opposite of
'None', that's saying something).
Strawman 2: putting data back into a generator
def pickled_file(name):
f = open(name, 'r')
yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(l, f)
f.close()
Keep your code, except toss that leading 'l'.
for l in pickled_file('greetings.pickle'):
l.append('hello')
l.append('howdy')
Toss that 'continue l', and your code will work (as long as both the
function and the for are sitting in the same namespace).
Hrm, not good enough? Use a Queue, or use another variable in a
namespace accessable to both your function and your loop.
Strawman 3: there is no strawman 3, but all lists need to have at least
3 items
I'm sorry if this email comes off harsh,
- 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] Adding any() and all()
Jim Jewett wrote: Guido van Rossum: Whether to segregate these into a separate module: they are really a very small amount of syntactic sugat, and I expect that in most cases, instead of importing that module (which totally makes me lose my context while editing) I would probably just write the extra line that it takes to get the same effect with an explicit for loop and if statement. Is that so bad? If you plan to use them often, then from itertools import any, every is reasonable. If you only use them once and weren't expecting it (and want your imports at the top) ... well how awful is it to have an extra line or two in your code? Basically the question (at least in my mind) when it comes to built-ins is whether the usage is so basic and fundamental that sticking them in a module is done more for rigid organization than for convenience. Personally, I think any() and all() meet this requirement. With their ties to basic boolean testing they should be built into the language and not just a part of the stdlib. If I am banging something out at a interpreter prompt I will want these functions easily accessible and I won't think of them as something to import. This probably comes off as wishy-washy, but it is just what my mind is spitting out at the moment. They also have the feeling as something that could be useful as a syntax (although I am just suggesting syntactic support!). Which could be an even better way to measure whether something should be a built-in. Would the function be useful as a syntactic addition to the language, but just can't quite reach the need of a new keyword? Once again any() and all() feel like that to me. These aren't *really* replacing map/filter/reduce because you're adding the new functions now, but the old-function removal is waiting until (forever?) Even if Python 3000 comes out a while from now, why wait? Two more is not that much. Besides, it isn't like we are adding functions as some crazy rate. And Guido has stated that the 2.x branch stops once 2.9 (if it goes that long) comes out. So at worst you only have to worry about 5 more releases to worry. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
