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
>There's a bunch of jobs we (CSV module maintainers) have been putting
>off - attached is a list (in no particular order):
[...]
>Also, review comments from Jeremy Hylton, 10 Apr 2003:
>
>I've been reviewing extension modules looking for C types that should
>participate in garbage collecti
"Alex Martelli" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> On 2005 Jan 06, at 20:16, Terry Reedy wrote:
>
>> [Knight's] title "Python's Super Considered Harmful" is an obvious
>> reference to
>> and takeoff on Dijkstra's influential polemic "Go To Statement
>> Considered Ha
>> * 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
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
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 auto
On Wed, 5 Jan 2005 21:27:16 -0800 (PST), Ilya Sandler
<[EMAIL PROTECTED]> wrote:
>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 unpacked fie
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 Su
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 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
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 list
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 a
OK, latest update with all suggest revisions (mention this is for CPython,
section for known previous bytecode work).
If no one has any revisions I will submit to David for official PEP acceptance
this weekend.
--
PEP: XXX
Title: How to change CPython's bytecode
[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,
> "Mul
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 b
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 h
> 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 P
"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 Considered Harmful" is an obviou
On Thu, 2005-01-06 at 11:33, Chermside, Michael wrote:
> > Why not just subscribe to
> > python-checkins and filter out everything *but* nondist/peps?
>
> But there are lots of people who might be interested in
> following PEP updates but not other checkins. Pretty
> much anyone who considers them
At 02:46 AM 1/6/05 -0500, James Y Knight wrote:
To fix #1, it would be really nice if you could write code something like
the following snippet. Notice especially here that the 'bar' argument gets
passed through C.__init__ and A.__init__, into D.__init__, without the
previous two having to do an
On Jan 6, 2005, at 7:22 AM, Thomas Heller wrote:
(*) Which brings me to the questions I have in my mind for quite some
time: Why is readinto undocumented, and what about the status of the
buffer object: do the recent fixes to the buffer object change it's
status?
I, for one, would be very unhappy i
> Please notice that I'm talking about concrete, real issues, not just a
> "super is bad!" rant.
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.
> They are
> Why not just subscribe to
> python-checkins and filter out everything *but* nondist/peps?
But there are lots of people who might be interested in
following PEP updates but not other checkins. Pretty
much anyone who considers themselves a "user" of Python
not a developer. Perhaps they don't even
Andrew McNamara wrote:
>
> I'm not altogether sure there. The parsing state machine is all
> written in C, and deals with signed chars - I expect we'll need two
> versions of that (or one version that's compiled twice using
> pre-processor macros). Quite a large job. Suggestions gratefully
> recei
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 "
On Thu, 2005-01-06 at 13: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
[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 favorable
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 unpacked field by field. Then one
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 i
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
notificati
Paul Moore <[EMAIL PROTECTED]> writes:
> On Thu, 6 Jan 2005 21:28:26 +1100, Anthony Baxter
> <[EMAIL PROTECTED]> wrote:
>> My take on this:
>>
>> struct.pack/struct.unpack is already one of my least-favourite parts
>> of the stdlib. Of the modules I use regularly, I pretty much only ever
On Thu, 6 Jan 2005 21:28:26 +1100, Anthony Baxter
<[EMAIL PROTECTED]> wrote:
> My take on this:
>
> struct.pack/struct.unpack is already one of my least-favourite parts
> of the stdlib. Of the modules I use regularly, I pretty much only ever
> have to go back and re-read the struct (an
My take on this:
struct.pack/struct.unpack is already one of my least-favourite parts
of the stdlib. Of the modules I use regularly, I pretty much only ever
have to go back and re-read the struct (and re) documentation because
they just won't fit in my brain. Adding additional com
On 2005 Jan 06, at 06:27, Ilya Sandler wrote:
...
We could have an optional offset argument for
unpack(format, buffer, offset=None)
I do agree on one concept here: when a function wants a string argument
S, and the value for that string argument S is likely to come from some
other bigger strin
On Jan 5, 2005, at 18:49, Martin v. Löwis wrote:
Jack Jansen 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
35 matches
Mail list logo
