Andrew McNamara wrote:
There's a bunch of jobs we (CSV module maintainers) have been putting
off - attached is a list (in no particular order):
* unicode support (this will probably uglify the code considerably).
Can you please elaborate on that? What needs to be done, and how is
that going to
Martin v. Löwis wrote:
Andrew McNamara wrote:
There's a bunch of jobs we (CSV module maintainers) have been putting
off - attached is a list (in no particular order):
* unicode support (this will probably uglify the code considerably).
Can you please elaborate on that? What needs to be done, and
On 5-jan-05, at 9:33, Martin v. Löwis wrote:
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again. Search
the pythonmac-sig archives for longer explanations. The gist is
that you specifically do not want to link directly to the framework
at all when building
Andrew McNamara wrote:
There's a bunch of jobs we (CSV module maintainers) have been putting
off - attached is a list (in no particular order):
* unicode support (this will probably uglify the code considerably).
Martin v. Löwis wrote:
Can you please elaborate on that? What needs to be
Andrew McNamara wrote:
Andrew McNamara wrote:
There's a bunch of jobs we (CSV module maintainers) have been putting
off - attached is a list (in no particular order):
* unicode support (this will probably uglify the code considerably).
Martin v. Löwis wrote:
Can you please elaborate on that? What
Yes, although it would be nice to also retain the 8-bit versions as well.
You can do so by using latin-1 as default encoding. Works great !
Yep, although that means we wear the cost of decoding and encoding for
all 8 bit input.
What does the _sre.c code do?
Depends on your needs: CSV files
Andrew McNamara wrote:
Yes, although it would be nice to also retain the 8-bit versions as well.
You can do so by using latin-1 as default encoding. Works great !
Yep, although that means we wear the cost of decoding and encoding for
all 8 bit input.
Right, but it makes the code very clean and
Yep, although that means we wear the cost of decoding and encoding for
all 8 bit input.
Right, but it makes the code very clean and straight forward.
I agree it makes for a very clean solution, and 99% of the time I'd
chose that option.
Again, it depends on what you need. If performance is
Martin v. Löwis [EMAIL PROTECTED] writes:
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again.
Search the pythonmac-sig archives for longer explanations. The
gist is that you specifically do not want to link directly to the
framework at all when building
On Jan 5, 2005, at 3:33 AM, Martin v. Löwis wrote:
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again. Search
the pythonmac-sig archives for longer explanations. The gist is
that you specifically do not want to link directly to the framework
at all when
I think it would be easier to create a new branch from the current
head, integrate the small number of changed files from ast-branch, and
work with that branch instead. The idea is that it's an end-run
around doing an automatic CVS merge and relying on someone to manually
merge the changes.
On Jan 5, 2005, at 18:46, Martin v. Löwis wrote:
Bob Ippolito wrote:
I just dug up some information I had written on this particular topic
but never published, if you're interested:
http://bob.pythonmac.org/archives/2005/01/05/versioned-frameworks-
considered-harmful/
Interesting. I don't get
[Ilya Sandler]
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 has to keep track
of offsets,
13 matches
Mail list logo
