Guido van Rossum wrote:
> Currently (in 3.0), "".join() automatically applies str() to the
> items of , *except* if the item is a bytes instance -- then it
> raises a TypeError. Is that proper behavior? The alternative is to
> uniformly apply str(), which for bytes returns a string of the form
> "b
On 10/31/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> We've made a lot of progress with the tests. Several buildbots are
> green. http://python.org/dev/buildbot/3.0/
>
> There are some tests that are unstable, at least:
>test_asynchat test_urllib2net test_xmlrpc
Here's a patch for the test_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 2, 2007, at 8:18 AM, Adam Hupp wrote:
> I prefer removing the str call on .join entirely. Is there any other
> string method that implicitly str's it's argument? I can't think of
> any. If this works I would expect that concatenation also i
OK, that's what I'll do. I was never really comfortable with it, and
now I know why.
On 11/2/07, Chris Monson <[EMAIL PROTECTED]> wrote:
> +1 on removing implicit str calls from join altogether.
>
>
> On 11/2/07, Adam Hupp <[EMAIL PROTECTED]> wrote:
> > On 11/1/07, Guido van Rossum <[EMAIL PROTECT
+1 on removing implicit str calls from join altogether.
On 11/2/07, Adam Hupp <[EMAIL PROTECTED]> wrote:
> On 11/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > The alternative is to uniformly apply str(), which for bytes returns a
> string of the form
> > "b'...'" or "buffer(b'...')" (de
On Thu, Nov 01, 2007 at 07:37:29PM -0700, Jeffrey Yasskin wrote:
> I'd na??vely vote for having "".join([non-strings]) raise a TypeError
> unconditionally like it did in 2.5.
+1 for always TypeError.
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
On 11/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The alternative is to uniformly apply str(), which for bytes returns a string
> of the form
> "b'...'" or "buffer(b'...')" (depending on whether the bytes are
> immutable or not). Given that we killed the exception for "" == b""
> earlier,
> +1 on removing implicit str calls from join altogether.
+1 from me, too.
Bill
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/arch
Too late. It's already gone. ;-)
On 11/2/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > +1 on removing implicit str calls from join altogether.
>
> +1 from me, too.
>
> Bill
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Pytho
Guido van Rossum wrote:
> OK, after I'm done with the merge from hell (I decided to merge from
> the trunk to py3k).
r58763 is causing a stack dump when I run the unit test suite (Ubuntu
7.10, UCS4 build, no debug).
$ ./python Lib/test/regrtest.py test_ftplib
test_ftplib
Segmentation fault (core
Gregory P. Smith wrote:
> Brainstorming here... how about an optional callable argument when
> unpickling to let the developers write their own "magic guess" function?
> This callable should take a single parameter and its return value would be
> used as the unpickled string.
The general idea is g
In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
The work is largely done, but I'm stuck with about 20 failing tests,
and very little time this weekend to work on these. Here's the list:
test_array
test_asynchat
test_asyncore
test_bsddb3
test_ctypes
test_email
test_e
and there was much rejoicing!
On 11/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Too late. It's already gone. ;-)
>
> On 11/2/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > +1 on removing implicit str calls from join altogether.
> >
> > +1 from me, too.
> >
> > Bill
> >
>
>
> --
> --Gu
On 11/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> In the py3k-pep3137 branch I've been working on the implementation of PEP
> 3137.
> The work is largely done, but I'm stuck with about 20 failing tests,
> and very little time this weekend to work on these. Here's the list:
>
I decided to
14 matches
Mail list logo
