Re: [Python-Dev] Should issubclass() be more like isinstance()?

Crutcher Dunnavant wrote: > While nocking together a framework today, I ran into the amazing > limitations of issubclass(). > > A) issubclass() throws a TypeError if the object being checked is not > a class, which seems very strange. It is a predicate, and lacking a > isclass() method, it should

Re: [Python-Dev] tally (and other accumulators)

Alex wrote: > On Apr 4, 2006, at 10:53 PM, Jess Austin wrote: > > Alex wrote: > >> import collections > >> def tally(seq): > >> d = collections.defaultdict(int) > >> for item in seq: > >> d[item] += 1 > >> return dict(d) > > > > I'll stop lurking and submit the following: >

Re: [Python-Dev] tally (and other accumulators)

On Apr 4, 2006, at 10:53 PM, Jess Austin wrote: > Alex wrote: >> import collections >> def tally(seq): >> d = collections.defaultdict(int) >> for item in seq: >> d[item] += 1 >> return dict(d) > > I'll stop lurking and submit the following: > > def tally(seq): > return

Re: [Python-Dev] tally (and other accumulators)

Alex wrote: > import collections > def tally(seq): > d = collections.defaultdict(int) > for item in seq: > d[item] += 1 > return dict(d) I'll stop lurking and submit the following: def tally(seq): return dict((group[0], len(tuple(group[1]))) for group

Re: [Python-Dev] Reminder: TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April.

On Tuesday 04 April 2006 22:34, Anthony Baxter wrote: > Just a reminder - the trunk is currently frozen for 2.5a1. Please > don't check anything into it until the release is done. I'll send an > update when this is good. Documentation packages have been uploaded to the download area. -Fred

Re: [Python-Dev] Should issubclass() be more like isinstance()?

On Apr 4, 2006, at 11:41 PM, Alex Martelli wrote: > IMHO, the solution to THAT very real problem is to supply a built-in > function that catches some exceptions and maps them into suitable > return values. Simplest would be something like: [...] > though I'm sure we can get better syntax if we turn

Re: [Python-Dev] Should issubclass() be more like isinstance()?

On Apr 4, 2006, at 8:18 PM, Crutcher Dunnavant wrote: ... >> There's no rule that predicate cannot raise an exception. > > No, but it makes many applications (such as using it as a test in list > comprehensions) difficult enough to not be worth it. IMHO, the solution to THAT very real problem

Re: [Python-Dev] Should issubclass() be more like isinstance()?

On 4/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/4/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > > On 4/4/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > > > Crutcher Dunnavant wrote: > > > > > > > A) issubclass() throws a TypeError if the object being checked is not > > > > a class,

Re: [Python-Dev] Should issubclass() be more like isinstance()?

On 4/4/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > On 4/4/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > > Crutcher Dunnavant wrote: > > > > > A) issubclass() throws a TypeError if the object being checked is not > > > a class, which seems very strange. > > > > If I ever pass a non-class to is

Re: [Python-Dev] reference leaks, __del__, and annotations

[various people debating how to steal a bit from an existing PyObject member] Let's stop this. It's a "bike shed" argument: even if we had 1000 spare bits, it wouldn't do any good. Having a bit to record whether an object has been finalized doesn't solve any problem that's been raised recently

[Python-Dev] The "Need for Speed" Sprint, Reykjavik, Iceland, May 21-28, 2006

EWT LLC and CCP h.f., having specific commercial interests in doing so, have decided to sponsor a sprint on the Python programming language with specific short- and medium-term acceleration goals. The sprint is also intended to stimulate broad consideration of the future of Python, and specificall

Re: [Python-Dev] reference leaks, __del__, and annotations

[Greg Ewing] > That's really what I'm asking -- what *does* a > generator finaliser need to reference? Or does > it depend on what the generator's code does? A generator finalizer can execute arbitrary Python code. Note that even if that was limited (which it isn't -- there are no limitations) to

[Python-Dev] Reminder: TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April.

Just a reminder - the trunk is currently frozen for 2.5a1. Please don't check anything into it until the release is done. I'll send an update when this is good. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. --- Begin Message --- Now that the bug day h

Re: [Python-Dev] reference leaks, __del__, and annotations

[Tim Peters] >> A problem is that the variant semantics also seem pretty arbitrary ;-), >> and there's a dearth of compelling use cases to guide a decision. [Greg Ewing] |> At the time I think I suggested that it would be > reasonable if weakref callbacks were guaranteed to > be called as long as

Re: [Python-Dev] Should issubclass() be more like isinstance()?

On 4/4/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Crutcher Dunnavant wrote: > > > A) issubclass() throws a TypeError if the object being checked is not > > a class, which seems very strange. > > If I ever pass a non-class to issubclass() it's almost > certainly a bug in my code, and I'd want to kn

Re: [Python-Dev] Should issubclass() be more like isinstance()?

Crutcher Dunnavant wrote: > A) issubclass() throws a TypeError if the object being checked is not > a class, which seems very strange. If I ever pass a non-class to issubclass() it's almost certainly a bug in my code, and I'd want to know about it. On the rare occasions when I don't want this, I

[Python-Dev] Should issubclass() be more like isinstance()?

While nocking together a framework today, I ran into the amazing limitations of issubclass(). A) issubclass() throws a TypeError if the object being checked is not a class, which seems very strange. It is a predicate, and lacking a isclass() method, it should just return False. B) issubclass() won

Re: [Python-Dev] reference leaks, __del__, and annotations

Martin v. Löwis wrote: > Of this kind, we have several spare bits: there are atleast two bits > in the ob_type field, And that would require changing all code that dereferenced the ob_type field! This would be much worse -- at least Py_INCREF and Py_DECREF are macros... -- Greg _

Re: [Python-Dev] reference leaks, __del__, and annotations

James Y Knight wrote: > All right, then, you could use the top bit of the ob_refcnt field. > There's no way to possibly have 2**32 objects on a 32bit system anyhow. That would slow down every Py_INCREF and Py_DECREF, which would need to be careful to exclude the top bit from their operations.

Re: [Python-Dev] reference leaks, __del__, and annotations

Neil Schemenauer wrote: > I think so but it depends on what the finalizer needs to reference. That's really what I'm asking -- what *does* a generator finaliser need to reference? Or does it depend on what the generator's code does? -- Greg ___ Python-

Re: [Python-Dev] reference leaks, __del__, and annotations

Tim Peters wrote: > A problem is that the variant semantics also seem pretty arbitrary ;-), > and there's a dearth of compelling use cases to guide a decision. At the time I think I suggested that it would be reasonable if weakref callbacks were guaranteed to be called as long as they weren't tras

Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py

Walter Dörwald wrote: > Greg Ewing wrote: > >> Wouldn't it be better for the setter to raise an exception >> if it's out of range? It probably indicates a bug in the >> caller's code. > > The day before Monday is -1, so it adds a little convenience. In that case, why doesn't the global function

Re: [Python-Dev] current 2.5 status

Trent Mick wrote: > I wonder if it would be possible to write a "reaper" script that used > some combination of EnumWindows, SendKeys, the Performance Monitoring > APIs (Pdh* function) and some elbow grease to click these crash > dialogs away. I've found for this type of thing AutoIt

Re: [Python-Dev] current 2.5 status

Trent Mick wrote: > I wonder if it would be possible to write a "reaper" script that used > some combination of EnumWindows, SendKeys, the Performance Monitoring > APIs (Pdh* function) and some elbow grease to click these crash dialogs > away. The buildbot invokes itself a "reaper" procedure if th

Re: [Python-Dev] current 2.5 status

[Tim Peters wrote] > Trent, FYI, on my box the invariable cause for > > LINK : fatal error LNK1104: cannot open file './python25_d.dll' > > in a failed buildbot Windows compile step is that some previous run > left behind a python_d.exe process that won't go away. I don't know > why it won't

Re: [Python-Dev] current 2.5 status

Trent, FYI, on my box the invariable cause for LINK : fatal error LNK1104: cannot open file './python25_d.dll' in a failed buildbot Windows compile step is that some previous run left behind a python_d.exe process that won't go away. I don't know why it won't go away on its own, or how it ge

Re: [Python-Dev] current 2.5 status

[Neal Norwitz] > ... > The following systems are green: > ... > x86 Windows 2k & XP (though there were some problems due to previous runs) There are no problems on one of the XP slaves. test_sqlite never ran on Win2K, although it's unlikely it will fail there (given that test_sqlite has run succe

[Python-Dev] current 2.5 status

Debian (ia64, ppc) is broken for several reasons, including the following test failures: test_ctypes test_curses test_sqlite. Some of the reasons vary depending on architecture. Ubuntu on hppa seems to have problems with at least: test_wait[34] seems to crash. cygwin has major problems (ie, it

Re: [Python-Dev] reference leaks, __del__, and annotations

James Y Knight wrote: > All right, then, you could use the top bit of the ob_refcnt field. > There's no way to possibly have 2**32 objects on a 32bit system anyhow. Of this kind, we have several spare bits: there are atleast two bits in the ob_type field, since the type pointer is atleast 4-alig

Re: [Python-Dev] Twisted and Python 2.5a0r43587

Thomas Wouters wrote: > It's just too bad that it's an easily overlooked hint, and that you > can't get that hint when compiling for 32-bit platforms. That all depends on the compiler, of course. Both MSVC and the Intel compiler support a /Wp64 flag, which tells you about "questionable" conversion

Re: [Python-Dev] outstanding items for 2.5

On Mon, Apr 03, 2006, Guido van Rossum wrote: > > Done. What exactly do you plan to do apart from editing the docs to > steer people away from file()? For the initial checkin, the dirt-simple: def open(filename, *args, **kwargs): return file(filename, *args, **kwargs) At this point, the sole

Re: [Python-Dev] Twisted and Python 2.5a0r43587

Thomas Wouters wrote: > The webpage should be made, though, if just to refer to in the > release notes. the web page does exist: http://www.python.org/dev/peps/pep-0353/#conversion-guidelines ___ Python-Dev mailing list Python-Dev@python.org h

Re: [Python-Dev] tally (and other accumulators)

On 4/4/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Alex] > > This is quite general and simple at the same time: for example, it > > was proposed originally to answer some complaint about any and all > > giving no indication of the count of true/false items: > > > > tally(bool(x) for x in se

Re: [Python-Dev] Twisted and Python 2.5a0r43587

On 4/4/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Thomas Wouters wrote:> And so I could.  test_banana.CananaTestCase.testCrashNegativeLong> crashes, because it calls PyString_AsStringAndSize() with an int-ptr as> second argument (an adjacent ptr variable becomes garbage.) That's > certainly a

Re: [Python-Dev] reference leaks, __del__, and annotations

On Apr 3, 2006, at 4:02 PM, Tim Peters wrote: > Using which compiler? This varies across boxes. Most obviously, on a > 64-bit box all these members are 8 bytes (note that ob_refcnt is > Py_ssize_t in 2.5, not int anymore), but even on some 32-bit boxes the > "long double" trick only forces 4-byte

[Python-Dev] chilling svn for 2.5a1

The freeze is still a few hours away, but please refrain from modifications unless they are really, really important for the release. The tests are just starting to turn green again. I'm not as worried about doc changes. Andrew feel free to keep updating whatsnew. Cheers, n

Re: [Python-Dev] line numbers, pass statements, implicit returns

On 4/2/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/1/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > > There are several test cases in test_trace that are commented out. We > > did this when we merged the ast-branch and promised to come back to > > them. I'm coming back to them now, but

Re: [Python-Dev] Twisted and Python 2.5a0r43587

On 4/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > On 4/4/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > > > > Of course anyone who is interested can run the Twisted test suite very > easily and take a look at the failures themselves (if you have Twisted > installed, "trial twisted" w

Re: [Python-Dev] Twisted and Python 2.5a0r43587

Neal Norwitz wrote: > I don't think so. I think that macro controls Py_BuildValue etc (the > APIs in modsupport.h) I don't think it controls anything else. So > what that means is that Py_BuildValue("l") means something different > depending on ssize_t or not. Actually, it *only* affects s#, z#

Re: [Python-Dev] Twisted and Python 2.5a0r43587

Thomas Wouters wrote: > And so I could. test_banana.CananaTestCase.testCrashNegativeLong > crashes, because it calls PyString_AsStringAndSize() with an int-ptr as > second argument (an adjacent ptr variable becomes garbage.) That's > certainly a problem with the Py_ssize_t change. Martin, aren't a

Re: [Python-Dev] tally (and other accumulators)

[Alex] > This is quite general and simple at the same time: for example, it > was proposed originally to answer some complaint about any and all > giving no indication of the count of true/false items: > > tally(bool(x) for x in seq) > > would give a dict with two entries, counts of true and

Re: [Python-Dev] Renaming sqlite3

Thomas Heller wrote: > Since on Windows binary extensions have to be compiled for the exact > major version of Python, it seems logical (to me, at least), to include > that version number into the filename. Say, _socket25.pyd. This would be a major change; it might break the build process of many

Re: [Python-Dev] Twisted and Python 2.5a0r43587

On 4/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > On 4/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > > > > Oh, goodie, a segmentation fault. Let's see if I can reproduce it ;P > > > And so I could. > test_banana.CananaTestCase.testCrashNegativeLong crashes, > because it calls PyStr

Re: [Python-Dev] reference leaks, __del__, and annotations

Greg Ewing <[EMAIL PROTECTED]> wrote: > Okay, so would it be possible for a generator that > needs finalisation to set up a weakref callback, suitably > rooted somewhere so that the callback is reachable, > that references enough stuff to clean up after the > generator, without referencing the gene

Re: [Python-Dev] Twisted and Python 2.5a0r43587

On 4/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: Oh, goodie, a segmentation fault. Let's see if I can reproduce it ;PAnd so I could.  test_banana.CananaTestCase.testCrashNegativeLong crashes, because it calls PyString_AsStringAndSize() with an int-ptr as second argument (an adjacent ptr variabl

Re: [Python-Dev] Twisted and Python 2.5a0r43587

On 4/4/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: Of course anyone who is interested can run the Twisted test suite very easily and take a look at the failures themselves (if you have Twisted installed, "trial twisted" will do it) and can guess which errors/failures are specific to Pyth

Re: [Python-Dev] tally (and other accumulators)

Alex Martelli wrote: > On Apr 4, 2006, at 8:01 AM, Jeremy Hylton wrote: > >> On 4/4/06, Alex Martelli <[EMAIL PROTECTED]> wrote: >>> import collections >>> def tally(seq): >>> d = collections.defaultdict(int) >>> for item in seq: >>> d[item] += 1 >>> return dict(d) > ..

Re: [Python-Dev] r43613 - python/trunk/Doc/lib/libcsv.tex

David Goodger wrote: > [regarding the examples in the last section of libcsv.tex] > > [Walter Dörwald] >> These classes will have problems with various non-charmap encodings. >> (E.g. the writer will write multiple BOMS for UTF-16). IMHO it would be >> better to use the new incremental codecs in

Re: [Python-Dev] Use dlopen() on Darwin/OS X to load extensions?

On Apr 3, 2006, at 9:01 PM, Neal Norwitz wrote: > On 4/3/06, Zachary Pincus <[EMAIL PROTECTED]> wrote: >> >> Sorry if it's bad form to ask about patches one has submitted -- let >> me know if that sort of discussion should be kept strictly on the >> patch tracker. > > No, it's fine. Thanks for r

Re: [Python-Dev] tally (and other accumulators)

Alex Martelli wrote: > It's a bit late for 2.5, of course, but, I thought I'd propose it > anyway -- I noticed it on c.l.py. > > In 2.3/2.4 we have many ways to generate and process iterators but > few "accumulators" -- functions that accept an iterable and produce > some kind of "summary re

Re: [Python-Dev] Twisted and Python 2.5a0r43587

On 4/4/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: This apparently was due to a change in the behavior of __import__: in Python 2.4, __import__('') raises a ValueError; in Python 2.5, it returns None.Oops, that wasn't intended. I seem to recall seeing that before, and I thought I'd fixed it,

Re: [Python-Dev] r43613 - python/trunk/Doc/lib/libcsv.tex

David Goodger wrote: > [regarding the examples in the last section of libcsv.tex] > > [Walter Dörwald] >> These classes will have problems with various non-charmap encodings. >> (E.g. the writer will write multiple BOMS for UTF-16). IMHO it would be >> better to use the new incremental codecs i

Re: [Python-Dev] r43613 - python/trunk/Doc/lib/libcsv.tex

[regarding the examples in the last section of libcsv.tex] [Walter Dörwald] > These classes will have problems with various non-charmap encodings. > (E.g. the writer will write multiple BOMS for UTF-16). IMHO it would be > better to use the new incremental codecs in these examples. Could you fi

Re: [Python-Dev] reference leaks, __del__, and annotations

[Michael Hudson] >>> And if we want to have a version of __del__ that can't reference >>> 'self', we have it already: weakrefs with callbacks. [Greg Ewing] >> Does that actually work at the moment? Last I heard, >> there was some issue with gc and weakref callbacks >> as well. Has that been resolv

Re: [Python-Dev] tally (and other accumulators)

On Apr 4, 2006, at 8:01 AM, Jeremy Hylton wrote: > On 4/4/06, Alex Martelli <[EMAIL PROTECTED]> wrote: >> import collections >> def tally(seq): >> d = collections.defaultdict(int) >> for item in seq: >> d[item] += 1 >> return dict(d) ... > Putting it somewhere in colle

Re: [Python-Dev] tally (and other accumulators)

On 4/4/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > import collections > def tally(seq): > d = collections.defaultdict(int) > for item in seq: > d[item] += 1 > return dict(d) > > Nevertheless, simplicity and generality make it advisable to supply > it as part of the standa

[Python-Dev] tally (and other accumulators)

It's a bit late for 2.5, of course, but, I thought I'd propose it anyway -- I noticed it on c.l.py. In 2.3/2.4 we have many ways to generate and process iterators but few "accumulators" -- functions that accept an iterable and produce some kind of "summary result" from it. sum, min, max, fo

Re: [Python-Dev] Use dlopen() on Darwin/OS X to load extensions?

On Apr 4, 2006, at 1:29 AM, Martin v. Löwis wrote: > Zachary Pincus wrote: >> Specifically, this patch would change a core python code path. > > Why do you think so? I believe Python always passes absolute paths > to dlopen, so any path resolution dlopen might do should be > irrelevant. > *If*

Re: [Python-Dev] reference leaks, __del__, and annotations

"Neal Norwitz" <[EMAIL PROTECTED]> writes: > On 4/3/06, Michael Hudson <[EMAIL PROTECTED]> wrote: >> Greg Ewing <[EMAIL PROTECTED]> writes: >> >> > Michael Hudson wrote: >> > >> >> And if we want to have a version of __del__ that can't reference >> >> 'self', we have it already: weakrefs with call

Re: [Python-Dev] Renaming sqlite3

Martin v. Löwis wrote: > Thomas Heller wrote: >> But if you make the change to implement option 3, IMO it would be a >> good idea to add the Python version number to the .pyd basename as >> well. > > Can you please elaborate? In the name of what .pyd file do you want > the Python version number?

Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py

Greg Ewing wrote: > Walter Dörwald wrote: > >> OK, the property setter does a "% 7" now. (But the global >> setfirstweekday() still does a range check). > > Wouldn't it be better for the setter to raise an exception > if it's out of range? It probably indicates a bug in the > caller's code. The

Re: [Python-Dev] reference leaks, __del__, and annotations

On 4/3/06, Michael Hudson <[EMAIL PROTECTED]> wrote: > Greg Ewing <[EMAIL PROTECTED]> writes: > > > Michael Hudson wrote: > > > >> And if we want to have a version of __del__ that can't reference > >> 'self', we have it already: weakrefs with callbacks. > > > > Does that actually work at the moment