[Python-Dev] string inconsistency
This is still in Lib/test/string_tests.py: #EQ(A, , replace, , A) # That was the correct result; this is the result we actually get # now (for str, but not for unicode): #EQ(, , replace, , A) Is this going to be fixed? n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] feature request: inspect.isgenerator
Neal Norwitz nnorwitz at gmail.com writes: I wonder whether a check shouldn't just return (co_flags 0x20), which is CO_GENERATOR. Makes more sense. Okay, but my point is that the final user should not be expected to know about those implementation details. The one obvious way to me is to have an inspect.isgenerator, analogous to inspect.isfunction, inspect.ismethod, etc. The typical use case is in writing a documentation/debugging tool. Now I was writing a decorator that needed to discriminate in the case it was decorating a regular function versus a generator. Michele Simionato ___ 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] feature request: inspect.isgenerator
Michele Simionato wrote: Neal Norwitz nnorwitz at gmail.com writes: I wonder whether a check shouldn't just return (co_flags 0x20), which is CO_GENERATOR. Makes more sense. Okay, but my point is that the final user should not be expected to know about those implementation details. The one obvious way to me is to have an inspect.isgenerator, analogous to inspect.isfunction, inspect.ismethod, etc. The typical use case is in writing a documentation/debugging tool. Now I was writing a decorator that needed to discriminate in the case it was decorating a regular function versus a generator. I'd say, go ahead and write a patch including docs, and I think there's no problem with accepting it (as long as it comes before beta1). 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] feature request: inspect.isgenerator
Michele Simionato [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Neal Norwitz nnorwitz at gmail.com writes: I wonder whether a check shouldn't just return (co_flags 0x20), which is CO_GENERATOR. Makes more sense. Okay, but my point is that the final user should not be expected to know about those implementation details. The one obvious way to me is to have an inspect.isgenerator, analogous to inspect.isfunction, inspect.ismethod, etc. The typical use case is in writing a documentation/debugging tool. Now I was writing a decorator that needed to discriminate in the case it was decorating a regular function versus a generator. To me, another obvious way is isinstance(object, gentype) where gentype = type(i for i in []) # for instance which should also be in types module. tjr ___ 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] feature request: inspect.isgenerator
Terry Reedy tjreedy at udel.edu writes: To me, another obvious way is isinstance(object, gentype) where gentype = type(i for i in []) # for instance which should also be in types module. No, that check would match generator objects, not generators tout court. On a related notes, inspect.isfunction gives True on a generator, such as def g(): yield None This could confuse people, however I am inclined to leave things as they are. Any thoughts? Michele Simionato ___ 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] feature request: inspect.isgenerator
Georg Brandl g.brandl at gmx.net writes: I'd say, go ahead and write a patch including docs, and I think there's no problem with accepting it (as long as it comes before beta1). I was having a look at http://docs.python.org/dev/lib/inspect-types.html and it would seem that adding isgenerator would imply changing inspect.getmembers() and its documentation. Also, should one add a GeneratorType, perhaps as a subclass of FunctionType? ___ 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] feature request: inspect.isgenerator
Michele Simionato wrote: Georg Brandl g.brandl at gmx.net writes: I'd say, go ahead and write a patch including docs, and I think there's no problem with accepting it (as long as it comes before beta1). I was having a look at http://docs.python.org/dev/lib/inspect-types.html and it would seem that adding isgenerator would imply changing inspect.getmembers() and its documentation. Yep. Also, should one add a GeneratorType, perhaps as a subclass of FunctionType? Add GeneratorType where? There is already one in the types module. 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] feature request: inspect.isgenerator
Michele Simionato wrote: Georg Brandl g.brandl at gmx.net writes: Also, should one add a GeneratorType, perhaps as a subclass of FunctionType? Add GeneratorType where? There is already one in the types module. Yep, this is the crux. types.GeneratorType refers to generator objects, which in an improper sense are instances of a generator function. I.e. def g(): yield 1 # this is a generator go = g() # this is a generator object I want isgenerator(g) == True, but isgenerator(go) == False. Ah, ok. But then I would name the function differently, perhaps isgeneratorfunc(). So, what should be the class of g ? Maybe we can keep FunctionType and don't bother. I would say, keep FunctionType. There's no real need to know the exact type except for inspecting, and for that, the new function in inspect can be used. 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] string inconsistency
[Neal] This is still in Lib/test/string_tests.py: #EQ(A, , replace, , A) # That was the correct result; this is the result we actually get # now (for str, but not for unicode): #EQ(, , replace, , A) Is this going to be fixed? Done. I had to comment out that new test during the NFS sprint because the str and unicode implementations gave different results (a pre-existing bug discovered during the sprint). str.replace() was repaired later during the sprint, but the new test remained commented out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] S/390 buildbot URLs problematic
The S/390 buildbot should be renamed. While the URLs buildbot generates in its email messages work, the ones that are on the overview page don't. 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] feature request: inspect.isgenerator
Michele Simionato [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] No, that check would match generator objects, not generators tout court. tout court?? is not English or commonly used at least in America On a related notes, inspect.isfunction gives True on a generator, such as def g(): yield None Ok, you mean generator function, which produces generators, not generators themselves. So what you want is a new isgenfunc function. That makes more sense, in a sense, since I can see that you would want to wrap genfuncs differently from regular funcs. But then I wonder why you don't use a different decorator since you know when you are writing a generator function. tjr ___ 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] feature request: inspect.isgenerator
Michele Simionato [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Yep, this is the crux. types.GeneratorType refers to generator objects, which in an improper sense are instances of a generator function. I.e. def g(): yield 1 # this is a generator go = g() # this is a generator object That terminology does not work. For every other type, an x is an x object and vice versa. I think most of us call functions which return generators a generator function when the distinction needs to be made. A generator is a type in the conceptual class 'iterator'. 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] feature request: inspect.isgenerator
At 09:26 AM 6/1/2006 +, Michele Simionato wrote: Terry Reedy tjreedy at udel.edu writes: To me, another obvious way is isinstance(object, gentype) where gentype = type(i for i in []) # for instance which should also be in types module. No, that check would match generator objects, not generators tout court. On a related notes, inspect.isfunction gives True on a generator, such as def g(): yield None This could confuse people, however I am inclined to leave things as they are. Any thoughts? Yes, I think the whole concept of inspecting for this is broken. *Any* function can return a generator-iterator. A generator function is just a function that happens to always return one. In other words, the confusion is in the idea of introspecting for this in the first place, not that generator functions are of FunctionType. The best way to avoid the confusion is to avoid thinking that you can distinguish one type of function from another without explicit guidance from the function's author. I'm -0 on having an isgenfunc(), but -1 on changing isfunction. +1 on making the code flags available. -1 on changing any other inspect stuff to handle generators specially. They are not special and should not be treated specially - they are just functions that happen to always return generator-iterators -- and that is an *implementation detail* of the function. Pushing that information out to introspection or doc is a bad idea in the general case. ___ 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 stop eating exceptions in dict lookup
On Wed, May 31, 2006 at 09:10:47PM -0400, Tim Peters wrote: [Martin Blais] I'm still looking for a benchmark that is not amazingly uninformative and crappy. I've been looking around all day, I even looked under the bed, I cannot find it. I've also been looking around all day as well, even looked for it shooting out of the Iceland geysirs, of all places--it's always all day out here it seems, day and day-- and I still can't find it. (In the process however, I found Thule beer and strangely dressed vikings, which makes it all worthwhile.) For those who don't know, Martin stayed on in Iceland after the NFS sprint. He shows clear signs above of developing photon madness. http://www.timeanddate.com/worldclock/astronomy.html?n=211 Where that says sunset, don't read dark -- it just means the top of the sun dips a bit below the horizon for a few hours. It never gets dark this time of year. If you haven't experienced this, no explanation can convey the other-worldly sense of it. The CCP Games CEO said they have trouble retaining talent from more moderate latitudes for this reason. 18 hours of daylight makes them a bit goofy and when the Winter Solstice rolls around they are apt to go quite mad. -Jack ___ 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] feature request: inspect.isgenerator
Phillip J. Eby writes: Yes, I think the whole concept of inspecting for this is broken. *Any* function can return a generator-iterator. A generator function is just a function that happens to always return one. Just following up on Phillip's comments, consider the following functions: def foo(x): while still_going(x): yield some_func(x) def bar(x): while still_going(x): yield other_func(x) def foo_or_bar(x): if some_condition(x): return foo(x) else: return bar(x) I presume that Michele's proposal is that inspect.isgenerator() (or perhaps inspect.isgenfunc()) would return True for foo and bar but false for foo_or_bar. Can you give a single use case for which that distinction is desirable? -- 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] SF patch #1473257: Add a gi_code attr to generators
At 09:53 PM 5/31/2006 +0200, Collin Winter wrote: Hi Phillip, Do you have any opinion on this patch (http://python.org/sf/1473257), which is assigned to you? I didn't know it was assigned to me. I guess SF doesn't send any notifications, and neither did Georg, so your email is the very first time that I've heard of it. I don't have any opinion, but perhaps Python-Dev does? ___ 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 Benchmarks
M.-A. Lemburg wrote: Seriously, I've been using and running pybench for years and even though tweaks to the interpreter do sometimes result in speedups or slow-downs where you wouldn't expect them (due to the interpreter using the Python objects), they are reproducable and often enough have uncovered that optimizations in one area may well result in slow-downs in other areas. Often enough the results are related to low-level features of the architecture you're using to run the code such as cache size, cache lines, number of registers in the CPU or on the FPU stack, etc. etc. and that observation has never made you stop and think about whether there might be some problem with the benchmarking approach you're using? after all, if a change to e.g. the try/except code slows things down or speed things up, is it really reasonable to expect that the time it takes to convert Unicode strings to uppercase should suddenly change due to cache effects or a changing number of registers in the CPU? real hardware doesn't work that way... is PyBench perhaps using the following approach: T = set of tests for N in range(number of test runs): for t in T: t0 = get_process_time() t() t1 = get_process_time() assign t1 - t0 to test t print assigned time where t1 - t0 is very short? that's not a very good idea, given how get_process_time tends to be implemented on current-era systems (google for jiffies)... but it definitely explains the bogus subtest results I'm seeing, and the magic hardware behaviour you're seeing. /F ___ 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] Removing Mac OS 9 cruft
I was about to remove Mac/IDE scripts, but it looks like there might be more stuff that is OS 9 related and should be removed. Other possibilities look like (everything under Mac/): Demo/* this is a bit more speculative IDE scripts/* MPW/* Tools/IDE/* this references IDE scripts, so presumably it should be toast? Tools/macfreeze/* Unsupported/mactcp/dnrglue.c Wastemods/* I'm going mostly based on what has been modified somewhat recently. Can someone confirm/reject these? I'll remove them. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF patch #1473257: Add a gi_code attr to generators
On 6/1/06, Phillip J. Eby [EMAIL PROTECTED] wrote: I didn't know it was assigned to me. I guess SF doesn't send any notifications, and neither did Georg, so your email is the very first time that I've heard of it. This is a longstanding SF bug. (One of the reasons why we should move away from it ASAP IMO.) While we're still using SF, developers should probably get in the habit of sending an email to the assignee when assigning a bug... -- --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] Removing Mac OS 9 cruft
On 2-jun-2006, at 5:31, Neal Norwitz wrote: I was about to remove Mac/IDE scripts, but it looks like there might be more stuff that is OS 9 related and should be removed. Other possibilities look like (everything under Mac/): Demo/* this is a bit more speculative IDE scripts/* MPW/* Tools/IDE/* this references IDE scripts, so presumably it should be toast? Tools/macfreeze/* Unsupported/mactcp/dnrglue.c Wastemods/* I'm going mostly based on what has been modified somewhat recently. Can someone confirm/reject these? I'll remove them. Demo is still needed, it contains example code. Some of it is stale, but not all. IMHO Modules/wastemodule.c and the demo's for it are also toast. I don't include support for waste in the universal binaries and so far nobody has complained. There's also not a universal binary of the version of waste we need. I'll be working on the structure of the Mac tree this weekend, other than removing cruft like the stuff you mention I want to move the files in Mac/OSX one level up in the hierarchy. Well actually I wasn't planning on actually removing stuff, just moving them to Mac/ Unsupported, but that's because I'm a wuss ;-). Feel free to remove these files (except Demo) and feel the satisfaction of removing unnecessary code. BTW. Bgen is a lot more challenging than the removal of old cruft. A lot of the modules in Mac/Modules are generated using bgen. Sadly enough they are/were generated from the OS9 SDK header files instead of the current system header files. This makes updating these modules harder than necessary. I'd like to fix this before 2.5b1 is out, but don't know if I'll be able to understand bgen good enough to actually make that deadline. Ronald n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.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
[Python-Dev] test_unicode failure on MIPS
Any ideas? http://www.python.org/dev/buildbot/all/MIPS%20Debian%20trunk/builds/176/step-test/0 == FAIL: test_count (test.test_unicode.UnicodeTest) -- Traceback (most recent call last): File /home/pybot/buildarea/trunk.klose-debian-mips/build/Lib/test/test_unicode.py, line 97, in test_count string_tests.CommonTest.test_count(self) File /home/pybot/buildarea/trunk.klose-debian-mips/build/Lib/test/string_tests.py, line 119, in test_count self.checkequal(0, 'aaa', 'count', '', 10) File /home/pybot/buildarea/trunk.klose-debian-mips/build/Lib/test/string_tests.py, line 56, in checkequal realresult AssertionError: 0 != 1 == FAIL: test_rfind (test.test_unicode.UnicodeTest) -- Traceback (most recent call last): File /home/pybot/buildarea/trunk.klose-debian-mips/build/Lib/test/test_unicode.py, line 118, in test_rfind string_tests.CommonTest.test_rfind(self) File /home/pybot/buildarea/trunk.klose-debian-mips/build/Lib/test/string_tests.py, line 198, in test_rfind self.checkequal(-1, 'abc', 'rfind', '', 4) File /home/pybot/buildarea/trunk.klose-debian-mips/build/Lib/test/string_tests.py, line 56, in checkequal realresult AssertionError: -1 != 3 ___ 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] SF patch #1473257: Add a gi_code attr to generators
Phillip J. Eby wrote: At 09:53 PM 5/31/2006 +0200, Collin Winter wrote: Hi Phillip, Do you have any opinion on this patch (http://python.org/sf/1473257), which is assigned to you? I didn't know it was assigned to me. I guess SF doesn't send any notifications, and neither did Georg, so your email is the very first time that I've heard of it. BTW, there's another one: #1483133. 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
