This is still in Lib/test/string_tests.py:
#EQ("A", "", "replace", "", "A")
# That was the correct result; this is the result we actually get
# now (for str, but not for unicode):
#EQ("", "", "replace", "", "A")
Is this going to be fixed?
n
___
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 -- r
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 crea
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 writin
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
http://mail.pyt
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
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
[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 tri
[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
>
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; i
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 by-p
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 b
[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
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/
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 bi
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
Python-Dev
Fredrik Lundh wrote:
> 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
>
>
file.seek etc. should be changed to use PyNumber_AsIndex or whatever
it's called.
On 5/31/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Looking at #1153226, I found this:
>
> We introduced emitting a DeprecationWarning for PyArg_ParseTuple
> integer arguments if a float was given. This doesn't aff
[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 mayb
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
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
com
[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 p
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 floats
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
_
[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
(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
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 p
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
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.
[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 tellin
Ü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
>
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: c-
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
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 fi
[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
[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
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
-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 "n
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
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 TestSkipp
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
> > >>
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
> > t
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 somet
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: Deprecati
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
45 matches
Mail list logo