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: Deprecati
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 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/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
> > >>
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
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 "n
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
[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
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
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
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-
Ü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
>
[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
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.
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 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
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 floats
[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
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
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 mayb
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
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
>
>
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
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
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
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
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 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
[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 tri
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
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
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
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
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
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
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
___
45 matches
Mail list logo
