Re: [Python-Dev] nonlocals() function?
On Sun, Apr 4, 2010 at 1:44 PM, Steven D'Aprano wrote: > On Mon, 5 Apr 2010 09:03:17 am average wrote: >> presently). That includes dir() too and probably others. > > You are confused -- globals() and locals() don't return lists. Yeah, this thread is mostly a mess (what would nonlocals() return anyway?), but there is one serious suggestion in there. Maybe dir() should return a set. Points in its favor: * The results of dir() are non-repeating * The order of items returned by dir() is not especially important * It would make "method" in dir(obj) marginally faster Points against: * It would break code that tried dir(obj)[0] (but why would anyone do that?) * Even though the order isn’t important for code, it’s convenient at the interactive prompt to see the methods of an item in alphabetical order for quick scanning. Overall: -0 My two bits. -- Carl Johnson ___ 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] Odd lines in unicodedata_db.h
On Sun, Apr 4, 2010 at 12:59 AM, Stephen J. Turnbull wrote: > They are related to the Chinese numbering system. I recall U+4EAC > having that value from my textbooks (it's the "kyo" in Tokyo, and the > "jing" in "Beijing", so quite memorable), and U+5793 looks familiar > (it's not otherwise used in Japanese AFAIK, so I'm not sure, but it > seems quite plausible that there would be a character for 1^5). For reference, the Japanese dictionary built into OS X defines U+5793 as: Gai Numerical unit. 10,000 “kei”s (kei = U+4EAC). 10 to the 20th power. Formerly also used for 10 “kei”s. Reference-deskily-yours, -- Carl Johnson ___ 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] Fwd: i18n
On Wed, Aug 25, 2010 at 10:42 PM, Anders J. Munch wrote: > This could be done as a free-standing library, there's no reason to > involve core CPython. Just do message translation at a later stage, > e.g. in a custom sys.excepthook. It could be done as a free standing library, but if this idea gets traction, it might be nice to incorporate it into the standard library, so inexperienced Pythoneers wouldn't have to do anything more onerous than "import localizedexceptions" in their interactive console. Using easy_install or whatever to add a new module can be tough in, say, a school environment where you don't have control of the machines you are using. I suppose the sensible thing to do is to recruit people for an independent project first and see if it gains traction. If it does, then pull it into the standard library a few years down the road. Incidentally, on the topic of translating keywords and such, it looks like one project to do so, Chinese Python, hasn't been updated since 2004: http://www.chinesepython.org/cgi_bin/cgb.cgi/news/news.html I just don't think there's much demand for translating the keywords. -- Carl Johnson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] minmax() function returning (minimum, maximum) tuple of a sequence
On Sun, Oct 10, 2010 at 2:55 PM, Zac Burns wrote: > This could be generalized and placed into itertools if we create a function > (say, apply for lack of a better name at the moment) that takes in an > iterable and creates new iterables that yield each from the original > (avoiding the need for a list) holding only one in memory. Then you could > pass the whatever function you wanted to run the iterables over an get the > result back in a tuple. Time machine partially beat you to this one. Look at the docs on itertools.tee tee(it, n=2) --> (it1, it2 , ... itn) splits one iterator into n Can be used like so: >>> it = iter(range(100)) >>> it1, it2 = itertools.tee(it) >>> max(it1) 99 >>> min(it2) 0 This doesn't quite have the memory characteristics you describe, but it's about as good as you can expect in a single threaded environment. ___ 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
