On 30-mei-2006, at 22:32, Tom Cato Amundsen wrote:
optparse
Using unicode strings with non-ascii chars.[1]
I'm working around this by subclassing OptionParser. Below is a
workaround I use in GNU Solfege. Should something like this be
included in python 2.5?
Could you please
A.M. Kuchling wrote:
On Tue, May 30, 2006 at 03:36:02PM -0600, Steven Bethard wrote:
That sounds about reasonable. One possible grouping:
Note that 2.5's library reference has a different chapter organization
from 2.4's. See http://docs.python.org/dev/lib/lib.html.
I like it. Its a
Bob,
There are a couple of things I don't understand about the new struct.
Below is a test that fails.
$ ./python ./Lib/test/regrtest.py test_tarfile test_struct
test_tarfile
/home/pybot/test-trunk/build/Lib/struct.py:63: DeprecationWarning: 'l'
format requires -2147483648 = number = 2147483647
On May 31, 2006, at 12:49 AM, Neal Norwitz wrote:
Bob,
There are a couple of things I don't understand about the new struct.
Below is a test that fails.
$ ./python ./Lib/test/regrtest.py test_tarfile test_struct
test_tarfile
/home/pybot/test-trunk/build/Lib/struct.py:63:
On 5/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Zitat von Neal Norwitz [EMAIL PROTECTED]:
I've been starting to get some of the buildbots working again. There
was some massive problem on May 25 where a ton of extra files were
left around. I can't remember if I saw something about
On 5/31/06, Bob Ippolito [EMAIL PROTECTED] wrote:
On May 31, 2006, at 12:49 AM, Neal Norwitz wrote:
Bob,
There are a couple of things I don't understand about the new struct.
Below is a test that fails.
$ ./python ./Lib/test/regrtest.py test_tarfile test_struct
test_tarfile
On 5/29/06, Guido van Rossum [EMAIL PROTECTED] wrote:
[python-checkins]
* Added socket.recv_buf() and socket.recvfrom_buf() methods, that
use the buffer
protocol (send and sendto already did).
* Added struct.pack_to(), that is the corresponding buffer
compatible method to
Some background for those not watching python-checkins:
I neglected to do svn add for the new functools Python module when
converting functional-functools. The buildbots stayed green because the
ImportError triggered by the line import functools in test_functools was
treated as a TestSkipped
Hi all
I'd like to know what the policy is on the source code indentation for
C code in the interpreter. At the Need-for-Speed sprints, there was
consensus that there is a new indentation for style for the Python C
source files, with
* indentation (emacs: c-basic-offset): 4 chars
* no tabs (so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 31 May 2006 07:02:02 -0400
Martin Blais [EMAIL PROTECTED] wrote:
I'd like to know what the policy is on the source code indentation for
C code in the interpreter. At the Need-for-Speed sprints, there was
consensus that there is a new
On Tue, May 30, 2006 at 11:46:06PM -0700, Talin wrote:
I like it. Its a much cleaner organization than the 2.4 libs. I would
like to see it used as a starting point for a reorg of the standard lib
namespace.
I'm not convinced that the chapter organization of a book is
necessarily the best
[Bob]
The warning is correct, and so is the size. Only native formats have
native sizes; l and i are exactly 4 bytes on all platforms when using
=, , , or !. That's what std size and alignment means.
[Neal]
Ah, you are correct. I see this is the behaviour in 2.4. Though I
wouldn't call 4
[Nick Coghlan]
What if we appended unexpected skips to the list of bad tests so that they get
rerun in verbose mode and the return value becomes non-zero?
print count(len(surprise), skip), \
unexpected on, plat + :
printlist(surprise)
# Add the next
On Wednesday, May 31, 2006, at 03:06PM, Tim Peters [EMAIL PROTECTED] wrote:
Would someone augment the warnings module to make testing
more reasonable?
What's required? I know of two things:
1. There's no advertised way to save+restore the internal
filter list, or to remove a filter
On 5/31/06, Martin Blais [EMAIL PROTECTED] wrote:
So I assume you're suggesting the following renames:
pack_to - packinto
recv_buf - recvinto
recvfrom_buf - recvfrominto
(I don't like that last one very much.
I'll go ahead and make those renames once I return.)
You could add an
Martin Blais wrote:
Hi all
I'd like to know what the policy is on the source code indentation for
C code in the interpreter. At the Need-for-Speed sprints, there was
consensus that there is a new indentation for style for the Python C
source files, with
* indentation (emacs:
Ühel kenal päeval, P, 2006-05-28 kell 14:18, kirjutas Thomas Wouters:
On 5/20/06, Hannu Krosing [EMAIL PROTECTED] wrote:
I try to move this to -dev as I hope there more people reading
it who
are competent in internal working :). So please replay to -dev
only.
[Ronald Oussoren, hijacking the test_struct failure on 64 bit platforms
thread]
The really annoying part of the new struct warnings is that the
warning line mentions a line in struct.py instead the caller of
struct.pack. That makes it hard to find the source of the
warning without telling the
I'm afraid a sabbatical year isn't long enough to understand what the
struct module did or intends to do by way of range checking 0.7
wink.
Is this intended? This is on a 32-bit Windows box with current trunk:
from struct import pack as p
p(I, 2**32 + 2343)
C:\Code\python\lib\struct.py:63:
Hello,
After reading through recent Python mail regarding dictionaries and
exceptions, I wondered, what is the current state of the art in
Python benchmarks? I've tried before to find a definite set of Python
benchmarks but failed. There doesn't seem to be an up to date
reference, though
On May 31, 2006, at 8:31 AM, Tim Peters wrote:
I'm afraid a sabbatical year isn't long enough to understand what the
struct module did or intends to do by way of range checking 0.7
wink.
Is this intended? This is on a 32-bit Windows box with current trunk:
from struct import pack as p
(This is more appropriate for comp.lang.python/[EMAIL PROTECTED])
Niko After reading through recent Python mail regarding dictionaries
Niko and exceptions, I wondered, what is the current state of the art
Niko in Python benchmarks?
Pybench was recently added to the repository and
[EMAIL PROTECTED] wrote:
(This is more appropriate for comp.lang.python/[EMAIL PROTECTED])
Niko After reading through recent Python mail regarding dictionaries
Niko and exceptions, I wondered, what is the current state of the art
Niko in Python benchmarks?
Pybench was recently
MAL Could you please forward such questions to me ?
I suppose, though what question were you referring to? I was referring to
Fredrik's thread about stringbench vs pybench for string/unicode tests,
which I thought was posted to python-dev. I assumed you were aware of the
issue.
Skip
Looking at #1153226, I found this:
We introduced emitting a DeprecationWarning for PyArg_ParseTuple
integer arguments if a float was given. This doesn't affect functions
like file.seek which use PyInt_AsLong to parse their argument.
PyInt_AsLong calls the nb_int slot which silently converts
[EMAIL PROTECTED] wrote:
MAL Could you please forward such questions to me ?
I suppose, though what question were you referring to?
Not sure - I thought you knew ;-)
I was referring to
Fredrik's thread about stringbench vs pybench for string/unicode tests,
which I thought was posted
MAL I'm aware of that thread, but Fredrik only posted some vague
MAL comment to the checkins list, saying that they couldn't use
MAL pybench. I asked for some more details, but he didn't get back to
MAL me.
I'm pretty sure I saw him (or maybe Andrew Dalke) post some timing
M.-A. Lemburg wrote:
AFAIK, there were no real issues with pybench, only with the
fact that time.clock() (the timer used by pybench) is wall-time
on Windows and thus an MP3-player running in the background
will cause some serious noise in the measurements
oh, please; as I mentioned back
[EMAIL PROTECTED] wrote:
MAL I'm aware of that thread, but Fredrik only posted some vague
MAL comment to the checkins list, saying that they couldn't use
MAL pybench. I asked for some more details, but he didn't get back to
MAL me.
I'm pretty sure I saw him (or maybe Andrew
Guido ... PyNumber_AsIndex or whatever it's called.
Maybe the API is getting a little fat if it doesn't fit comfortably in the
BDFL's brain... Does that suggest it might need some streamlining for Py3k?
Skip
___
Python-Dev mailing list
Zitat von Andreas Flöter [EMAIL PROTECTED]:
Help would be appreciated
This strictly doesn't belong to python-dev: this is the list where
you say I want to help, not so much I need your help.
If you want to resolve this yourself, we can guide you through
that. I would start running the binary
2006/5/31, [EMAIL PROTECTED] [EMAIL PROTECTED]:
This strictly doesn't belong to python-dev: this is the list where
you say I want to help, not so much I need your help.
QOTW!
I love it!
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
[MvL, to Andreas Flöter]
This strictly doesn't belong to python-dev: this is the list where
you say I want to help, not so much I need your help.
LOL! How true.
If you want to resolve this yourself, we can guide you through
that. I would start running the binary in a debugger to find
out
I'm curious about the difference between
float_subtype_new in floatobject.c
complex_subtype_from_c_complex in complexobject.c
The former uses type-tp_alloc(type, 0) to create memory for the object
while the latter uses PyType_GenericAlloc(type, 0) to create memory for
the sub-type (thereby
I'm curious about the difference between
float_subtype_new in floatobject.c
complex_subtype_from_c_complex in complexobject.c
The former uses type-tp_alloc(type, 0) to create memory for the object
while the latter uses PyType_GenericAlloc(type, 0) to create memory for
the sub-type (thereby
I wouldn't be surprised if this is a genuine bug; the complex type
doesn't get a lot of love from core developers.
Could you come up with a proposed fix, and a unit test showing that it
works (and that the old version doesn't)? (Maybe a good unit test
would require writing a custome C extension;
[Martin Blais]
I'm still looking for a benchmark that is not amazingly uninformative
and crappy. I've been looking around all day, I even looked under the
bed, I cannot find it. I've also been looking around all day as well,
even looked for it shooting out of the Iceland geysirs, of all
[Fredrik Lundh]
would abc.find(, 100) == 3 be okay? or should we switch to treating the
optional start and end positions as return value boundaries (used to filter
the
result) rather than slice directives (used to process the source string
before
the operation)? it's all trivial to
On 5/31/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 5/31/06, Martin Blais [EMAIL PROTECTED] wrote:
So I assume you're suggesting the following renames:
pack_to - packinto
recv_buf - recvinto
recvfrom_buf - recvfrominto
(I don't like that last one very much.
I'll go
On 5/31/06, Tim Peters [EMAIL PROTECTED] wrote:
[Fredrik Lundh]
would abc.find(, 100) == 3 be okay? or should we switch to treating the
optional start and end positions as return value boundaries (used to
filter the
result) rather than slice directives (used to process the source string
Guido (Maybe a good unit test would require writing a custome C
Guido extension; in that case just show some sample code.)
Isn't that what Module/_testcapimodule.c is for?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
I wouldn't be surprised if this is a genuine bug; the complex type
doesn't get a lot of love from core developers.
Could you come up with a proposed fix, and a unit test showing that it
works (and that the old version doesn't)? (Maybe a good unit test
would require
Travis E. Oliphant wrote:
I'm curious about the difference between
float_subtype_new in floatobject.c
complex_subtype_from_c_complex in complexobject.c
The former uses type-tp_alloc(type, 0) to create memory for the object
while the latter uses PyType_GenericAlloc(type, 0) to create
On 5/31/06, Tim Peters [EMAIL PROTECTED] wrote:
standard is a technical word with precise meaning here, and is
defined by the struct module docs, in contrast to native. It means
whatever they say it means :-) Portable may have been a more
intuitive word than standard here -- read standard
44 matches
Mail list logo
