Eric V. Smith wrote:
> If you want:
>
> x = 3
> "{0:f}".format(x)
>
> then be explicit and write:
>
> "{0:f}".format(float(x))
That would be quite inconvenient, I think. It's very common
to use ints and floats interchangeably in contexts which
are conceptually float. The rest of the language fa
On 8/9/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
[SNIP]
> See http://docs.python.org/dev/3.0/results/make-install.out for this failure:
>
> Compiling /tmp/python-test-3.0/local/lib/python3.0/test/test_pep263.py ...
> Traceback (most recent call last):
> File "/tmp/python-test-3.0/local/lib/pyth
Bah, who needs sleep anyways. This list of problems should be fairly
complete when running with -R. (it skips the fatal error from
test_datetime though)
Code to trigger a leak: b'\xff'.decode("utf8", "ignore")
Leaks:
test_array leaked [11, 11, 11] references, sum=33
test_bytes leaked [4, 4, 4
On 8/9/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Georg Brandl schrieb:
> > Well, subject says it all. While 2.5 sets sys.std*.encoding correctly to
> > UTF-8, 3k sets it to 'latin-1', breaking output of Unicode strings.
>
> And not surprisingly so: io.py says
>
> if encoding is Non
On 8/10/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Anyway, if we're keeping conversions, I see two approaches:
>
> 1: "".format() (or Talin's format_field, actually) understands which
> types can be converted to other types, and does the conversions. This
> is how Patrick and I wrote the original
On 8/10/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 8/9/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> [SNIP]
> > See http://docs.python.org/dev/3.0/results/make-install.out for this
> > failure:
> >
> > Compiling /tmp/python-test-3.0/local/lib/python3.0/test/test_pep263.py ...
> > Traceback (
Jim Jewett wrote:
> On 8/9/07, Eric V. Smith <[EMAIL PROTECTED]> wrote:
>
>> If you want:
>>
>> x = 3
>> "{0:f}".format(x)
>>
>> then be explicit and write:
>>
>> "{0:f}".format(float(x))
>
> Because then you can't really create formatting strings. Instead of
>
> >>> print("The high tempera
If you really need to step through the Python code, you can just
sabotage the loading of the non-Python version, e.g. remove or rename
the .so or .dll file temporarily.
I wonder about the usefulness of this debugging though -- if you're
debugging something that requires you to step through the C c
On 8/9/07, Eric V. Smith <[EMAIL PROTECTED]> wrote:
> If you want:
>
> x = 3
> "{0:f}".format(x)
>
> then be explicit and write:
>
> "{0:f}".format(float(x))
Because then you can't really create formatting strings. Instead of
>>> print("The high temperature at {place:s}, on {date:-MM-DD
On 8/9/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > There are currently about 7 failing unit tests left:
> >
> > test_bsddb
Looks like this (trivial) test now passes, at least on the one box I
have where it isn't skipped (an ancient red hat 7.3 box that just
won't die :-).
> > test_bsddb3
FWI
Um, Neal reported some more failures with -R earlier. I can reproduce
the failures for test_collections and test_runpy, but test_gzip passes
fine for me (standalone). I'll look into these. I'm still running the
full set as well, it'll take all day. I can't reproduce Neal's problem
with test_poplib
On 8/10/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > If you really need to step through the Python code, you can just
> > sabotage the loading of the non-Python version, e.g. remove or rename
> > the .so or .dll file temporarily.
> >
> > I wonder about the usefulness of
I've updated the wiki page with the status for these. I've confirmed
the test_datetime segfault, but I can only provoke it when run in
sequence with all the others.
I'm also experiencing a hang of test_asynchat when run in sequence.
http://wiki.python.org/moin/Py3kStrUniTests
--Guido
On 8/10/07
On Aug 10, 2007, at 11:23 AM, Guido van Rossum wrote:
> Python 3.0 currently has limited universal newlines support: by
> default, \r\n is translated into \n for text files, but this can be
> controlled by the newline= keyword parameter. For details on how, see
> PEP 3116. The PEP prescribes that
Python 3.0 currently has limited universal newlines support: by
default, \r\n is translated into \n for text files, but this can be
controlled by the newline= keyword parameter. For details on how, see
PEP 3116. The PEP prescribes that a lone \r must also be translated,
though this hasn't been impl
Status update:
The following still leak (regrtest.py -R4:3:)
test_array leaked [11, 11, 11] references, sum=33
test_multibytecodec leaked [72, 72, 72] references, sum=216
test_parser leaked [5, 5, 5] references, sum=15
test_zipimport leaked [29, 29, 29] references, sum=87
I can't reproduce the t
On Thursday 09 August 2007 19:21:27 Thomas Heller wrote:
> Victor Stinner schrieb:
> > I prefer str8 which looks to be a good candidate for "frozenbytes" type.
>
> I love this idea! Leave str8 as it is, maybe extend Python so that it
> understands the s"..." literals and we are done.
Hum, today s
Guido van Rossum wrote:
> This could just as well be done using a method on that specific
> object. I don't think having to write x.as_bytes() is worse than
> bytes(x), *unless* there are contexts where it's important to convert
> something to bytes without knowing what kind of thing it is. For
> s
Ron Adam wrote:
> - alter the value and return (new_value, format_spec)
> - alter the format_spec and return (value, new_format_spec)
> - do logging of some values, and return the (value, format_spec)
> unchanged.
I would ditch all of these. They're not necessary, as
the same effect c
Good morning py3k-dev!
If I understand correctly the new C optimization for io,py by Alexandre
Vassalotti and possible other optimization for modules likes pickle.py
are going to be dropped in automatically. The Python implementation is a
reference implementation and will be used as fall back only
Neal Norwitz wrote:
> [...]
> Code to trigger a leak: b'\xff'.decode("utf8", "ignore")
This should be fixed in r56894.
> [...]
Servus,
Walter
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
On 8/10/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > However we select between Python and native module versions, the build
> > bots need be set up to run the modules both ways (with and without C
> > optimisation).
>
> If there is a way to explictly
On 8/10/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I like to propose a --disable-optimization (-N for no optimization) flag
> for Python that disables the usage of optimized implementation. The
> status of the flag can be set by either a command line argument or a C
> function call before P
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> However we select between Python and native module versions, the build
> bots need be set up to run the modules both ways (with and without C
> optimisation).
If there is a way to explictly import each module separately then I
think that meets both needs
I tried test_shelve on three boxes, with the following results:
Ubuntu, using gdbm: pass
OSX, using dbm: pass
Red Hat 7.3, using bsddb: fail
So this seems to be a lingering bsddb failure. (I think that's the
"simple" bsddb module, not the full bsddb3 package.)
--Guido
On 8/10/07, Jeremy Hylton
On 8/10/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> However we select between Python and native module versions, the build
> bots need be set up to run the modules both ways (with and without C
> optimisation).
That is trivial to do without any runtime flags. For example for
testing both the C a
Guido van Rossum writes:
> However, the old universal newlines feature also set an attibute named
> 'newlines' on the file object to a tuple of up to three elements
> giving the actual line endings that were observed on the file so far
> (\r, \n, or \r\n). This feature is not in PEP 3116, and
I also see test_shelve failing because something is passing bytes as a
dictionary key. I've just started seeing it, but can't figure out
what caused the change.
Jeremy
On 8/10/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I've updated the wiki page with the status for these. I've confirmed
>
Greg Ewing wrote:
> Ron Adam wrote:
>> - alter the value and return (new_value, format_spec)
>> - alter the format_spec and return (value, new_format_spec)
>> - do logging of some values, and return the (value, format_spec)
>> unchanged.
>
> I would ditch all of these. They're not n
Guido van Rossum wrote:
> If you really need to step through the Python code, you can just
> sabotage the loading of the non-Python version, e.g. remove or rename
> the .so or .dll file temporarily.
>
> I wonder about the usefulness of this debugging though -- if you're
> debugging something that
Hi,
On Thursday 09 August 2007 02:41:08 Victor Stinner wrote:
> I started to work on email module to port it for Python 3000, but I have
> trouble to understand if a function should returns bytes or str (because I
> don't know email module).
It's really hard to convert email module to Python 3000
Hi,
I don't like the behaviour of Python 3000 when we compare a bytes strings
with length=1:
>>> b'xyz'[0] == b'x'
False
The code can be see as:
>>> ord(b'x') == b'x'
False
or also:
>>> 120 == b'x'
False
Two solutions:
1. b'xyz'[0] returns a new bytes object (b'x' instead of
Hi,
I just see that function what() of imghdr module requires str type for
argument h which is totally wrong! An image file is composed of bytes and not
characters.
Attached patch should fix it. Notes:
- I used .startswith() instead of h[:len(s)] == s
- I used h[0] == ord(b'P') instead of h[0
On 8/10/07, Victor Stinner <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I just see that function what() of imghdr module requires str type for
> argument h which is totally wrong! An image file is composed of bytes and not
> characters.
>
> Attached patch should fix it. Notes:
> - I used .startswith() ins
On 8/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> >>> OTOH, IDLE ran w/o this error in p3yk...
> >> Yes. Somebody would have to study what precisely the problem is: is it
> >> that there is a None key in that dictionary, and that you must not use
> >> None as a tag name? In that case: wh
Hi,
As imghdr, sndhdr tests were strill based on Unicode strings instead of bytes.
Attached patch should fix the module. I'm very, I was unable to test it.
Note: I replaced aifc.openfp with aifc.open since it's the new public
function.
sndhdr requires some cleanup: it doesn't check division by
Christian Heimes wrote:
> But on the
> other hand it is going to make debugging with pdb much harder because
> pdb can't step into C code.
But wouldn't the only reason you want to step into,
e.g. pickle be if there were a bug in pickle itself?
And if this happens when you're using the C version
of
Eric Smith wrote:
> 1: "".format() ... understands which
> types can be converted to other types, and does the conversions.
>
> 2: each type's __format__ function understands how to convert to some
> subset of all types (int can convert to float and decimal, for example).
>
> The problem with a
Ron Adam wrote:
>
> I'm not sure what you mean by "ditch all of these".
I was guessing that what's meant by returning a
(value, format_spec) tuple is to re-try the
formatting using the new value and spec. That's
what I thought was unnecessary, since the method
can do that itself if it wants.
> T
Guido van Rossum wrote:
> However, the old universal newlines feature also set an attibute named
> 'newlines' on the file object to a tuple of up to three elements
> giving the actual line endings that were observed on the file so far
> (\r, \n, or \r\n).
I've never used it, but I can see how it c
Greg Ewing wrote:
> Eric Smith wrote:
>> 1: "".format() ... understands which
>> types can be converted to other types, and does the conversions.
>>
>> 2: each type's __format__ function understands how to convert to some
>> subset of all types (int can convert to float and decimal, for example).
Greg Ewing wrote:
> Ron Adam wrote:
>> I'm not sure what you mean by "ditch all of these".
>
> I was guessing that what's meant by returning a
> (value, format_spec) tuple is to re-try the
> formatting using the new value and spec. That's
> what I thought was unnecessary, since the method
> can
Ron Adam wrote:
>
> Greg Ewing wrote:
>
> > Then why not just return an empty string?
>
> Because an empty string is a valid string. It can be expanded to a
> minimum width which me may not want to do.
I'm not seeing a use case for this. If the user says
he wants his field a certain minimum wi
I'm going to address several issues of the discussion, in hopes of
short-cutting through some of the debate. I may not be responding to the
correct person in all cases.
Ron Adam wrote:
> If you want the 'r' specifier to always have precedence over even custom
> __format__ methods, then you can
Greg Ewing writes:
> Guido van Rossum wrote:
> > However, the old universal newlines feature also set an attibute named
> > 'newlines' on the file object to a tuple of up to three elements
> > giving the actual line endings that were observed on the file so far
> > (\r, \n, or \r\n).
>
> I
45 matches
Mail list logo
