Re: [Python-Dev] feature request: inspect.isgenerator
Neal Norwitz 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 [email protected] 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 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 [email protected] 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 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 [email protected] 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 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 [email protected] 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 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 [email protected] 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 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 [email protected] 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 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. So, what should be the class of g ? Maybe we can keep FunctionType and don't bother. Michele Simionato ___ Python-Dev mailing list [email protected] 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 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 [email protected] 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
[email protected]
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 [email protected] 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 [email protected] 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 [email protected] 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 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 [email protected] 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 [email protected] 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 [email protected] 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 Friday 02 June 2006 02:21, Jack Diederich wrote: > 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. Obviously they need to hire people who are already crazy. not-naming-any-names-ly, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] 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 [email protected] 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. ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ > ronaldoussoren%40mac.com ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_unicode failure on MIPS
Neal Norwitz wrote: > Any ideas? this is a recent change, so it looks like the box simply didn't get around to rebuild the unicodeobject module. (I'm beginning to wonder if I didn't forget to add some header file dependencies somewhere during the stringlib refactoring, but none of the other buildbots seem to have a problem with this...) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] valgrind report
Looks pretty good, except for 1 cjk problem: test_codecencodings_jp Invalid read of size 1 at 0x110AEBC3: shift_jis_2004_decode (_codecs_jp.c:642) by 0xBFCBDB7: mbidecoder_decode (multibytecodec.c:839) Address 0xAEC376B is 0 bytes after a block of size 3 alloc'd at 0x4A19B7E: malloc (vg_replace_malloc.c:149) by 0xBFCBF54: mbidecoder_decode (multibytecodec.c:1023) n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_unicode failure on MIPS
On 6/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > > Any ideas? > > this is a recent change, so it looks like the box simply didn't get > around to rebuild the unicodeobject module. That shouldn't be. make distclean should be called (it was make clean until recently). However, http://www.python.org/dev/buildbot/all/MIPS%20Debian%20trunk/builds/176/step-compile/0 seems to indicate unicodeobject was in fact not built. I also don't see any previous record of any builds (or make cleans). That buildslave is new and it had some connectivity problems I think. So maybe something was whacky on it. The current build (still running) definitely did compile unicodeobject. So let's wait and see if that finishes successfully. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
