Someone asked on python-list about getting notifications of changes to PEP's.
As a low-effort solution, would it be possible to add a Sourceforge mailing list
hook just for checkins to the nondist/peps directory?
Call it python-pep-updates or some such beast. If I remember how checkin
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The new solution is basically to go back to the Unix way of
building an extension: link it against nothing and sort things out
at runtime. Not my personal preference, but at least we know that
loading an extension into one Python won't bring in
[Nick Coghlan]
Someone asked on python-list about getting notifications of changes to
PEP's.
As a low-effort solution, would it be possible to add a Sourceforge
mailing list hook just for checkins to the nondist/peps directory?
-0
Probably possible, but not no-effort, so even if it gets a
Andrew McNamara wrote:
Marc-Andre Lemburg mentioned that he has encountered UTF-16 encoded csv
files, so a reasonable starting point would be the ability to read and
parse, as well as the ability to generate, one of these.
I see. That would be reasonable, indeed. Notice that this is not so much
a
Then why is the title Python's Super Considered Harmful ???
Here's my final offer. Change the title to something like Multiple
Inheritance Pitfalls in Python and nobody will get hurt.
Or better yet, considering the recent thread on Python marketing,
Multiple Inheritance Mastery in Python
Nick Coghlan wrote:
Someone asked on python-list about getting notifications of changes to
PEP's.
As a low-effort solution, would it be possible to add a Sourceforge
mailing list hook just for checkins to the nondist/peps directory?
Call it python-pep-updates or some such beast. If I remember
On Jan 6, 2005, at 8:17, Michael Hudson wrote:
Ilya Sandler [EMAIL PROTECTED] writes:
A problem:
The current struct.unpack api works well for unpacking C-structures
where
everything is usually unpacked at once, but it
becomes inconvenient when unpacking binary files where things
often have to be
[Guido]
Then why is the title Python's Super Considered Harmful ???
Here's my final offer. Change the title to something like Multiple
Inheritance Pitfalls in Python and nobody will get hurt.
[Bill Janssen]
Or better yet, considering the recent thread on Python marketing,
Multiple
On 6-jan-05, at 14:04, Jack Jansen wrote:
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The new solution is basically to go back to the Unix way of
building an extension: link it against nothing and sort things out
at runtime. Not my personal preference, but at least we know that
loading an
Ronald Oussoren wrote:
Wouldn't it be better to link with the actual dylib inside the framework
on 10.2? Otherwise you can no longer build 2.3 extensions after you've
installed 2.4.
That's what I thought, too.
Regards,
Martin
___
Python-Dev mailing
On Jan 6, 2005, at 14:59, Ronald Oussoren wrote:
On 6-jan-05, at 14:04, Jack Jansen wrote:
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The new solution is basically to go back to the Unix way of
building an extension: link it against nothing and sort things out
at runtime. Not my personal
When support for floating-point stat times was added in 2.3,
it was the plan that this should eventually become the default.
Does anybody object if I change the default now, for Python 2.5?
Applications which then break can globally change it back, with
os.stat_float_times(False)
Regards,
Martin
On 2005 Jan 06, at 20:16, Terry Reedy wrote:
James Y Knight [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Please notice that I'm talking about concrete, real issues, not just a
super is bad! rant.
Umm, James, come on. Let's be really real and concrete ;-).
Your title Python's Super
Guido van Rossum wrote:
and the cumbersome way in which you have to invoke super.
Given Python's dynamic nature I couldn't think of a way to make it
less cumbersome. I see you tried (see below) and couldn't either. At
this point I tend to say put up or shut up.
Well, there's my autosuper
Magnus Quite a while ago I posted some material to the csv-list about
Magnus problems using the csv module on Unix-style colon-separated
Magnus files -- it just doesn't deal properly with backslash escaping
Magnus and is quite useless for this kind of file. I seem to recall the
* is CSV going to be maintained outside the python tree?
If not, remove the 2.2 compatibility macros for: PyDoc_STR,
PyDoc_STRVAR, PyMODINIT_FUNC, etc.
Andrew Does anyone thing we should continue to maintain this 2.2
Andrew compatibility?
With the release of 2.4, 2.2 has
I'm considering a change to the csv module that could potentially break
some obscure uses of the module (but CSV files usually quote, rather
than escape, so the most common uses aren't effected).
Currently, with a non-default escapechar='\\', input like:
field one,field \
two,field three
17 matches
Mail list logo
