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* you can get dlopen to look at directories outside sys.path,
that
A.B., Khalid wrote:
Shouldn't that part read as follows? Or am I missing something?
rc = ShellExecuteW((HWND)0,
PyUnicode_AS_UNICODE(woperation),
PyUnicode_AS_UNICODE(unipath),
NULL, NULL, SW_SHOWNORMAL);
That's certainly better, though not correct, yet: woperation
might be NULL.
Jean-Paul Calderone wrote:
Once I do have time to track down specifics, I'll file tickets as
appropriate. For now I just wanted to point out the one detail I
have tracked down, and give a heads up that there are likely some
more to come.
Of course anyone who is interested can run the
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? Last I heard,
there was some issue with gc and weakref callbacks
as well.
Tim Peters [EMAIL PROTECTED] writes:
[Michael Hudson]
...
What happened to the 'get rid of __del__ in py3k' idea?
Apart from its initial mention, every now again someone asks what
happened to it :-).
Good enough for me :)
Cheers,
mwh
(not subscribed to python-3000)
--
You're going to
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? Last I heard,
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 day before
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? And why?
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 callbacks.
Does that
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* you can
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, for
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 standard library
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 collections seems
[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 resolved?
[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 fix
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 these
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,
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 result
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 reminding us
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 these
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)
...
Putting it somewhere
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 Python
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 variable
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 generator
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
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
[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 false
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 all
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#, t#.
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 will do it).
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 the test
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
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
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 problem
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 seq)
would
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
/F
___
Python-Dev mailing list
Python-Dev@python.org
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
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
conversions
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
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,
[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
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
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
allow the
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 trash
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
___
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
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()
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,
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 know about
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.
---BeginMessage---
Now that the bug day has
[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
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
[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
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 issubclass() it's
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, which seems very
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
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
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 in
58 matches
Mail list logo